Active Directory Domain Services Operations Guide

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....................................................................25
New in This Guide......................................................................................................................... 25
Administering Active Directory Domain Services..........................................................................25
Introduction to Administering Active Directory Domain Services...................................................26
When to use this guide.............................................................................................................. 26
How to use this guide................................................................................................................ 27
Administering Domain and Forest Trusts......................................................................................27
Introduction to Administering Domain and Forest Trusts...............................................................28
Best Practices for Administering Domain and Forest Trusts.........................................................28
Managing Domain and Forest Trusts............................................................................................ 29
Creating Domain and Forest Trusts.............................................................................................. 29
New Trust Wizard terminology................................................................................................... 30
Known Issues for Creating Domain and Forest Trusts..................................................................31
Creating External Trusts............................................................................................................... 32
Create a One-Way, Incoming, External Trust for One Side of the Trust........................................34
Create a One-Way, Incoming, External Trust for Both Sides of the Trust......................................35
Create a One-Way, Outgoing, External Trust for One Side of the Trust........................................37
Create a One-Way, Outgoing, External Trust for Both Sides of the Trust......................................38
Create a Two-Way, External Trust for One Side of the Trust.........................................................40
Create a Two-Way, External Trust for Both Sides of the Trust......................................................41
Creating Shortcut Trusts............................................................................................................... 43
Create a One-Way, Incoming, Shortcut Trust for One Side of the Trust........................................44
Create a One-Way, Incoming, Shortcut Trust for Both Sides of the Trust.....................................45
Create a One-Way, Outgoing, Shortcut Trust for One Side of the Trust........................................47
Create a One-Way, Outgoing, Shortcut Trust for Both Sides of the Trust.....................................48
Create a Two-Way, Shortcut Trust for One Side of the Trust........................................................50

Create a Two-Way, Shortcut Trust for Both Sides of the Trust......................................................51
Creating Forest Trusts.................................................................................................................. 52
Create a One-Way, Incoming, Forest Trust for One Side of the Trust...........................................54
Create a One-Way, Incoming, Forest Trust for Both Sides of the Trust.........................................55
Create a One-Way, Outgoing, Forest Trust for One Side of the Trust...........................................57
Create a One-Way, Outgoing, Forest Trust for Both Sides of the Trust.........................................59
Create a Two-Way, Forest Trust for One Side of the Trust............................................................60
Create a Two-Way, Forest Trust for Both Sides of the Trust.........................................................62
Creating Realm Trusts.................................................................................................................. 63
Create a One-Way, Incoming, Realm Trust...................................................................................64
Create a One-Way, Outgoing, Realm Trust...................................................................................65
Create a Two-Way, Realm Trust................................................................................................... 66
Configuring Domain and Forest Trusts......................................................................................... 68
Validating and Removing Trusts.................................................................................................... 68
Validate a Trust............................................................................................................................. 68
Validating a trust........................................................................................................................ 69
Remove a Manually Created Trust............................................................................................... 70
Removing a manually created trust...........................................................................................70
Modifying Name Suffix Routing Settings.......................................................................................71
Modify Routing for a Forest Name Suffix......................................................................................72
Modify Routing for a Subordinate Name Suffix.............................................................................73
Exclude Name Suffixes from Routing to a Forest.........................................................................74
Securing Domain and Forest Trusts.............................................................................................75
Configuring SID Filter Quarantining on External Trusts................................................................75
Disable SID filter Quarantining...................................................................................................... 76
See Also.................................................................................................................................... 78
Reapply SID Filter Quarantining................................................................................................... 78
Configuring Selective Authentication Settings...............................................................................79

Enable Selective Authentication over an External Trust................................................................80
Enabling selective authentication over an external trust............................................................80
Enable Selective Authentication over a Forest Trust.....................................................................81
Enabling selective authentication over a forest trust..................................................................82
Enable Domain-Wide Authentication over an External Trust.........................................................83
Enable Forest-Wide Authentication over a Forest Trust................................................................84
Grant the Allowed to Authenticate Permission on Computers in the Trusting Domain or Forest...85
Appendix: New Trust Wizard Pages.............................................................................................. 86
Direction of Trust....................................................................................................................... 86
Wizard optionTwo-way....................................................................................................... 86
Wizard optionOne-way: incoming.......................................................................................87
Wizard optionOne-way: outgoing........................................................................................ 88
Sides of trust............................................................................................................................. 88
Wizard optionThis domain only........................................................................................... 89
Wizard optionBoth this domain and the specified domain..................................................89
Administering the Windows Time Service.....................................................................................89
Introduction to Administering the Windows Time Service..............................................................89
Windows time source selection................................................................................................. 90
External NTP time servers......................................................................................................... 90
W32tm and net time.................................................................................................................. 91
Managing the Windows Time Service...........................................................................................92
Configuring a Time Source for the Forest.....................................................................................92
Configure the Time Source for the Forest.....................................................................................94
Change the Windows Time Service Configuration on the PDC Emulator in the Forest Root
Domain...................................................................................................................................... 98
Disable the Windows Time Service............................................................................................... 99
Enable Windows Time Service Debug Logging..........................................................................100
Configuring Windows-Based Clients to Synchronize Time.........................................................100
Configure a Manual Time Source for a Selected Client Computer..............................................101
Configure a Client Computer for Automatic Domain Time Synchronization................................103
Restoring the Windows Time Service to Default Settings...........................................................104
Restore the Windows Time Service on the Local Computer to the Default Settings...................104
Administering DFS-Replicated SYSVOL.....................................................................................105
Introduction to Administering DFS-Replicated SYSVOL.............................................................105
SYSVOL terminology and capitalization..................................................................................106
Using DFS Replication for replicating SYSVOL in Windows Server 2008...............................107
Requirements for using DFS Replication.................................................................................107
Key considerations for administering SYSVOL.......................................................................108
Relocating SYSVOL folders..................................................................................................... 109
Managing DFS-Replicated SYSVOL...........................................................................................111
Changing the Quota That Is Allocated to the SYSVOL Staging Area..........................................111
Change the Quota That Is Allocated to the SYSVOL Staging Folder..........................................112
Relocating the SYSVOL Staging Area......................................................................................... 112
Identify Replication Partners....................................................................................................... 114
Check the Status of the SYSVOL and Netlogon Shares.............................................................114
Verify Active Directory Replication............................................................................................... 115
Gather the SYSVOL Path Information......................................................................................... 116
To gather the SYSVOL path information..................................................................................117
Stop the DFS Replication Service and Netlogon Service............................................................119
Create the SYSVOL Staging Areas Folder Structure..................................................................120
Change the SYSVOL Root Path or Staging Areas Path, or Both................................................121
See Also.................................................................................................................................. 122
Start the DFS Replication Service and Netlogon Service...........................................................122
Force Replication Between Domain Controllers.........................................................................123
See Also.................................................................................................................................. 124
Relocating SYSVOL Manually.................................................................................................... 124
Verify Active Directory Replication.............................................................................................. 127
Gather the SYSVOL Path Information........................................................................................128

Copy SYSVOL to a New Location............................................................................................... 132
Create the SYSVOL Root Junction Point....................................................................................134
Change the SYSVOL Root Path or Staging Areas Path, or Both................................................135
See Also.................................................................................................................................. 136
Change the SYSVOL Netlogon Parameters...............................................................................136
Reapply Default SYSVOL Security Settings...............................................................................137
See Also.................................................................................................................................. 141
Updating the SYSVOL Path........................................................................................................ 141
Change the SYSVOL Netlogon Parameters...............................................................................146
Create the SYSVOL Root Junction Point....................................................................................146
Restoring and Rebuilding SYSVOL............................................................................................149
Restart the Domain Controller in Directory Services Restore Mode Locally...............................155
Restarting the domain controller in DSRM locally....................................................................157
See Also.................................................................................................................................. 158
Restart the Domain Controller in Directory Services Restore Mode Remotely...........................158
See Also.................................................................................................................................. 162
Import the SYSVOL Folder Structure..........................................................................................163
See Also.................................................................................................................................. 166

Administering the Global Catalog...............................................................................................166
Introduction to Administering the Global Catalog........................................................................166
Global catalog hardware requirements....................................................................................167
Global catalog placement........................................................................................................ 167
Initial global catalog replication................................................................................................ 167
Global catalog readiness......................................................................................................... 167
Global catalog removal............................................................................................................ 168
Managing the Global Catalog..................................................................................................... 168
Configuring a Global Catalog Server.......................................................................................... 169
Determine Whether a Domain Controller Is a Global Catalog Server.........................................169
Designate a Domain Controller to Be a Global Catalog Server..................................................170
Monitor Global Catalog Replication Progress.............................................................................170
Verify Successful Replication to a Domain Controller.................................................................171
Determining Global Catalog Readiness......................................................................................174
Verify Global Catalog Readiness................................................................................................175
Verifying global catalog readiness........................................................................................... 175
Verify Global Catalog DNS Registrations....................................................................................176
Removing the Global Catalog..................................................................................................... 177
Clear the Global Catalog Setting................................................................................................177
Monitor Global Catalog Removal in Event Viewer......................................................................178
Administering Operations Master Roles......................................................................................178
Introduction to Administering Operations Master Roles..............................................................179
Guidelines for role placement.................................................................................................. 179
Guidelines for role transfer...................................................................................................... 183
Managing Operations Master Roles...........................................................................................184
Designating a Standby Operations Master.................................................................................184
Standby operations master computer requirements................................................................185
Replication requirements......................................................................................................... 185
Create a Connection Object on the Operations Master and Standby.........................................186

Transferring an Operations Master Role.....................................................................................190
Transferring to a standby operations master...........................................................................191
Transferring an operations master role when no standby is ready..........................................191
Install the Schema Snap-in......................................................................................................... 192
Transfer the Schema Master....................................................................................................... 193
Transfer the Domain Naming Master..........................................................................................194
Transfer the Domain-Level Operations Master Roles.................................................................195
View the Current Operations Master Role Holders.....................................................................196
Seizing an operations master role..............................................................................................197
Seize the Operations Master Role..............................................................................................201
Reducing the Workload on the PDC Emulator Master................................................................203
Changing the weight for DNS service (SRV) resource records in the registry.........................203
Changing the priority for DNS service (SRV) resource records in the registry.........................204
Change the Weight for DNS Service (SRV) Resource Records in the Registry..........................205
Change the Priority for DNS Service (SRV) Resource Records in the Registry.........................205
Administering Active Directory Backup and Recovery................................................................206
Introduction to Administering Active Directory Backup and Recovery
[lhsad_ADDS_Ops_5]_ADDS_Ops_5.....................................................................................207
Backing up AD DS................................................................................................................... 207
Recovering AD DS................................................................................................................... 207
Additional considerations......................................................................................................... 209
Managing Active Directory Backup and Recovery......................................................................209
Backing Up Active Directory Domain Services............................................................................209
Windows Server backup tools................................................................................................. 209
Windows Server backup types................................................................................................ 210
Contents of Windows Server backup types..........................................................................210
Criteria for using backup types............................................................................................. 211
Backup guidelines................................................................................................................... 212
Scheduling regular backups.................................................................................................... 214
Immediate (unscheduled) backup............................................................................................ 214
Backup frequency.................................................................................................................... 214

Backup frequency criteria..................................................................................................... 215
Backup latency interval........................................................................................................ 215
Known Issues for Backing Up Active Directory Domain Services...............................................217
Perform a Backup of Critical Volumes of a Domain Controller by Using the GUI (Windows Server
Backup)................................................................................................................................... 218
Additional considerations.................................................................................................. 219
Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin)
................................................................................................................................................ 220
Perform a Full Server Backup of a Domain Controller by Using the GUI (Windows Server Backup)
................................................................................................................................................ 221
Perform a Full Server Backup of a Domain Controller by Using the Command Line (Wbadmin)226
Recovering Active Directory Domain Services............................................................................227
Causes of disruptions.............................................................................................................. 227
Keys to protecting against disruptions.....................................................................................228
Preventing unwanted deletions...............................................................................................228
Recovery solutions.................................................................................................................. 229
Solutions for configuration errorsnonauthoritative restore................................................229
Solutions for data lossauthoritative restore.......................................................................230
Recovery options with no available backup..........................................................................231
Solutions for hardware failure or file corruption....................................................................232
Recovery tasks........................................................................................................................ 233
Performing Nonauthoritative Restore of Active Directory Domain Services................................233
Nonauthoritative Restore Requirements..................................................................................234
SYSVOL restore...................................................................................................................... 234
Additional references............................................................................................................... 235
See Also.................................................................................................................................. 238
See Also.................................................................................................................................. 241
Restore AD DS from Backup (Nonauthoritative Restore)............................................................242
Verify AD DS restore................................................................................................................... 243
Performing Authoritative Restore of Active Directory Objects.....................................................245

Determining objects to restore................................................................................................. 246
Selecting objects to restore..................................................................................................... 246
Selecting application directory partitions to restore.................................................................247
Restoring group memberships after authoritative restore........................................................247
LVR and restoration of group memberships.........................................................................247
Authoritative restore of pre-LVR group memberships and groups in different domains........248
Files for recovering group memberships following authoritative restore...............................249
Using a global catalog server for authoritative restore.............................................................250
Recovering deletions without restoring from backup...............................................................250
Retention (merge) of new group memberships or other attributes after authoritative restore..251
Authoritative restore procedures.............................................................................................. 252
Procedures for restoring after deletions have replicated......................................................252
Procedures for restoring before deletions have replicated...................................................253
Procedures for recovering group memberships (and any other back-link attributes) in other
domains............................................................................................................................ 254
Known Issues for Authoritative Restore......................................................................................255
Order of replication and dropped group memberships............................................................256
Members added back to groups from which they were deleted...............................................257
Incorrect assignment of Exchange mailboxes.........................................................................257
Best Practices for Authoritative Restore......................................................................................257
See Also.................................................................................................................................. 261
See Also.................................................................................................................................. 265
Mark an Object or Objects as Authoritative.................................................................................267
Turn Off Inbound Replication...................................................................................................... 269
Synchronize Replication with All Partners...................................................................................270
See Also.................................................................................................................................. 271
Run an LDIF File to Recover Back-Links....................................................................................271
Turn on Inbound Replication....................................................................................................... 272

Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects.................273
Performing Authoritative Restore of an Application Directory Partition.......................................274
See Also.................................................................................................................................. 278
See Also.................................................................................................................................. 281
Mark an application directory partition as authoritative...............................................................283
See Also.................................................................................................................................. 284
Performing a Full Server Recovery of a Domain Controller........................................................285
Requirements for performing a full server recovery of a domain controller.............................285
Performing a full server recovery of a domain controller by using the GUI..............................285
Performing a full server recovery of a domain controller by using the command line..............287
Additional considerations......................................................................................................... 288
Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup. 289
See Also.................................................................................................................................. 293
See Also.................................................................................................................................. 296
Verify AD DS restore................................................................................................................... 298
Restoring a Domain Controller Through Reinstallation...............................................................299
Clean Up Server Metadata......................................................................................................... 301
See Also.................................................................................................................................. 303
Delete a Server Object from a Site.............................................................................................304
See Also.................................................................................................................................. 304
Verify DNS Registration and TCP/IP Connectivity......................................................................305

Verify the Availability of the Operations Masters.........................................................................305
Install an Additional Domain Controller by Using the Windows Interface....................................307
See Also.................................................................................................................................. 309
Verifying Active Directory Installation..........................................................................................309
Administering Intersite Replication..............................................................................................310
Introduction to Administering Intersite Replication.......................................................................311
Optimizing replication between sites........................................................................................ 311
Effects of site link bridging.................................................................................................... 312
Effects of disabling site link bridging....................................................................................312
Optimizing domain controller location......................................................................................313
Finding the next closest site.................................................................................................313
Forcing domain controller rediscovery.................................................................................313
Improving the logon experience in branch sites......................................................................314
See Also.................................................................................................................................. 314
Managing Intersite Replication.................................................................................................... 314
Adding a New Site...................................................................................................................... 315
Create a Site Object and Add it to an Existing Site Link..............................................................316
See Also.................................................................................................................................. 316
Create a Subnet Object or Objects and Associate them with a Site...........................................316
Associate an Existing Subnet Object with a Site.........................................................................317
Create a Site Link Object and Add the Appropriate Sites............................................................318
Remove a Site from a Site Link.................................................................................................. 318
Linking Sites for Replication........................................................................................................ 319
Creating site links.................................................................................................................... 319
Selecting bridgehead servers.................................................................................................. 320
Create a Site Link Object and Add the Appropriate Sites............................................................321
Determine the ISTG Role Owner for a Site.................................................................................321
Generate the Replication Topology on the ISTG.........................................................................322
Designate a Server as a Preferred Bridgehead Server...............................................................323
Changing Site Link Properties.................................................................................................... 323
Configure the Site Link Schedule to Identify Times During Which Intersite Replication Can Occur
................................................................................................................................................ 324
Configure the Site Link Interval to Identify How Often Replication Polling Can Occur During the
Schedule Window.................................................................................................................... 325
Configure the Site Link Cost to Establish a Priority for Replication Routing................................326
Enabling Clients to Locate the Next Closest Domain Controller.................................................328
Enable Clients to Locate a Domain Controller in the Next Closest Site......................................329
Moving a Domain Controller to a Different Site...........................................................................330
TCP/IP settings........................................................................................................................ 331
DNS settings........................................................................................................................... 331
Preferred bridgehead server status......................................................................................... 331
Change the Static IP Address of a Domain Controller................................................................333
Update the IP Address for a DNS Delegation.............................................................................334
Update the IP Address for a DNS Forwarder..............................................................................335
Verify That an IP Address Maps to a Subnet and Determine the Site Association......................336
See Also.................................................................................................................................. 337
Determine Whether a Server is a Preferred Bridgehead Server.................................................337
See Also.................................................................................................................................. 337
View the List of All Preferred Bridgehead Servers......................................................................337
See Also.................................................................................................................................. 338
Configure a Server to Not Be a Preferred Bridgehead Server....................................................338
See Also.................................................................................................................................. 339
Move a Server Object to a New Site...........................................................................................339
See Also.................................................................................................................................. 340
Enabling Universal Group Membership Caching in a Site..........................................................340
Enable Universal Group Membership Caching in a Site.............................................................341
Forcing Replication..................................................................................................................... 341
Forcing replication of all directory updates over a connection.................................................342
Forcing replication of configuration updates............................................................................342
See Also.................................................................................................................................. 344

Update a Server with Configuration Changes.............................................................................344
See Also.................................................................................................................................. 346
Removing a Site......................................................................................................................... 349
Delete a Manual Connection Object........................................................................................... 351
Determine Whether a Server Object Has Child Objects.............................................................352
See Also.................................................................................................................................. 353
Delete a Site Link object............................................................................................................. 353
Associate an Existing Subnet Object with a Site.........................................................................354
Delete a Site object..................................................................................................................... 355
See Also.................................................................................................................................. 355
Administering the Active Directory Database..............................................................................357
Introduction to Administering the Active Directory Database [lhsad]_ADDS_Ops_7...................357
Database management conditions.......................................................................................... 357
Disk space monitoring recommendations................................................................................357
Database defragmentation...................................................................................................... 358
Restartable AD DS.................................................................................................................. 358
See Also.................................................................................................................................. 359
Managing the Active Directory Database....................................................................................359
Relocating the Active Directory Database Files..........................................................................359
Disk space requirements for relocating Active Directory database files...................................360
Determine the Database Size and Location Online....................................................................362
See Also.................................................................................................................................. 363
Determine the Database Size and Location Offline....................................................................363
See Also.................................................................................................................................. 364
Compare the Size of the Directory Database Files to the Volume Size......................................364
................................................................................................................................................ 365
Move the Directory Database and Log Files to a Local Drive.....................................................366
See Also.................................................................................................................................. 369
Copy the Directory Database and Log Files to a Remote Share................................................369
See Also.................................................................................................................................. 372
Returning Unused Disk Space from the Active Directory Database to the File System..............372
Change the Garbage Collection Logging Level to 1...................................................................374
See Also.................................................................................................................................. 374
................................................................................................................................................ 375
Compact the Directory DatabaseFfile (Offline Defragmentation)................................................376
See Also.................................................................................................................................. 379
If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup............379
Administering Domain Controllers..............................................................................................381
Introduction to Administering Domain Controllers.......................................................................381
Installing Remote Server Administration Tools.........................................................................381
Installing and removing AD DS................................................................................................ 382
Adding domain controllers.................................................................................................... 382
Removing domain controllers............................................................................................... 382
Renaming domain controllers.................................................................................................. 382
Adding domain controllers to branch sites...............................................................................383
Installing from media............................................................................................................ 383
Shipping installed domain controllers to branch sites...........................................................384
Managing Domain Controllers.................................................................................................... 384
Installing Remote Server Administration Tools for AD DS...........................................................386
Installing Active Directory Domain Services Tools on a member server that is running
Windows Server 2008.......................................................................................................... 387
Installing Active Directory Domain Services Tools on a computer that is running Windows Vista
with SP1............................................................................................................................... 387
Managing Antivirus Software on Active Directory Domain Controllers........................................387
Guidelines for managing antivirus software on Active Directory domain controllers................388
Files to exclude from scanning................................................................................................389
Preparing for Active Directory Installation...................................................................................391

DNS configuration................................................................................................................... 392
Site placement......................................................................................................................... 392
Domain connectivity................................................................................................................ 392
Verify DNS Infrastructure and Registrations...............................................................................394
See Also.................................................................................................................................. 396
Installing a Domain Controller in an Existing Domain.................................................................398
See Also.................................................................................................................................. 399
Installing an Additional Domain Controller by Using the Windows Interface...............................399
See Also.................................................................................................................................. 400
Install an Additional Domain Controller by Using the Windows Interface....................................400
See Also.................................................................................................................................. 402
Installing an Additional Domain Controller by Using IFM............................................................402
See Also.................................................................................................................................. 405
Create Installation Media by Using Ntdsutil................................................................................405
See Also.................................................................................................................................. 406
Install an Additional Domain Controller by Using Installation Media...........................................406
See Also.................................................................................................................................. 407
Installing an Additional Domain Controller by Using Unattend Parameters.................................407
See Also.................................................................................................................................. 408
Create an Answer File for Unattended Domain Controller Installation........................................408
See Also.................................................................................................................................. 410
Install an Additional Domain Controller by Using an Answer File................................................410
See Also.................................................................................................................................. 411
Install an Additional Domain Controller by Using Unattend Parameters from the Command Line
................................................................................................................................................. 411
Verifying Active Directory Installation..........................................................................................412
See Also.................................................................................................................................. 414
Configure DNS Server Forwarders............................................................................................. 414
Verifying DNS Configuration....................................................................................................... 415
Verify DNS Server Configuration for a Domain Controller...........................................................416

See Also.................................................................................................................................. 416
Verify DNS Client Settings.......................................................................................................... 417
See Also.................................................................................................................................. 417
Verify a Domain Computer Account for a New Domain Controller..............................................419
Adding Domain Controllers in Remote Sites...............................................................................420
Best Practices for Adding Domain Controllers in Remote Sites..................................................421
Best practices for using IFM to install AD DS in the remote site..............................................421
Best practices for installing domain controllers before you ship them to a remote site............423
See Also.................................................................................................................................. 425
Known Issues for Adding Domain Controllers in Remote Sites...................................................425
SYSVOL replication................................................................................................................. 426
Using IFM to install a domain controller in a remote site.........................................................426
Advantages of using IFM to install a domain controller in a remote site...............................427
Issues with using IFM to install a domain controller in a remote site....................................427
Installing domain controllers before shipping them to the remote site.....................................428
Advantages of installing domain controllers before shipping them to the remote site..........429
Issues with installing domain controllers before shipping them to the remote site...............429
Maintaining directory consistency when you disconnect a domain controller.......................430
Protection against lingering object replication...................................................................430
Availability of operations masters.....................................................................................431
Up to dateness of active directory replication...................................................................431
SYSVOL consistency........................................................................................................ 431
See Also.................................................................................................................................. 432
Preparing a Server Computer for Shipping and Installation from Media.....................................432
Determining the volume for installation media.........................................................................433
Enabling Remote Desktop....................................................................................................... 433
Including application directory partitions..................................................................................433
See Also.................................................................................................................................. 434
Enable Remote Desktop............................................................................................................. 434
Create a Remote Desktop Connection.......................................................................................436
See Also.................................................................................................................................. 436
Install an Additional Domain Controller by Using Installation Media...........................................437
See Also.................................................................................................................................. 438
Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection...............438

See Also.................................................................................................................................. 439
Determine the Tombstone Lifetime for the Forest.......................................................................440
Enable Strict Replication Consistency........................................................................................440
See Also.................................................................................................................................. 443
Reconnecting a Domain Controller After a Long-Term Disconnection........................................443
Reconnecting an outdated domain controller..........................................................................443
Updating SYSVOL................................................................................................................... 444
See Also.................................................................................................................................. 445
Determine the Tombstone Lifetime for the Forest.......................................................................445
Move a Server Object to a New Site...........................................................................................446
See Also.................................................................................................................................. 447
Determine When Intersite Replication Is Scheduled to Begin.....................................................447
Use Repadmin to Remove Lingering Objects.............................................................................448
Renaming a Domain Controller................................................................................................... 453
Rename a Domain Controller Using System Properties.............................................................454
See Also.................................................................................................................................. 454
Rename a Domain Controller Using Netdom..............................................................................454
See Also.................................................................................................................................. 456
Update the FRS or DFS Replication Member Object..................................................................457
Decommissioning a Domain Controller.......................................................................................458
Removing a domain or a forest...............................................................................................458
Protecting EFS-encrypted files................................................................................................458
See Also.................................................................................................................................. 461
Verify DNS Registration and TCP/IP Connectivity......................................................................461
Transfer the Schema Master....................................................................................................... 463
Transfer the Domain Naming Master..........................................................................................464
Transfer the Domain-Level Operations Master Roles.................................................................465

Back Up a Certificate With Its Private Key..................................................................................468
Removing a Windows Server 2008 Domain Controller from a Domain.......................................469
Removing a Windows Server 2008 domain controller by using the Windows interface...........469
Removing a Windows Server 2008 domain controller by using an answer file........................470
Removing a Windows Server 2008 domain controller by entering unattended installation
parameters at the command line.......................................................................................... 471
Import a Certificate..................................................................................................................... 471
Determine Whether a Server Object Has Child Objects.............................................................473
See Also.................................................................................................................................. 474
Add the Certificates Snap-in to an MMC.....................................................................................474
Adding the Certificates Snap-in to an MMC.............................................................................474
Forcing the Removal of a Domain Controller..............................................................................476
Force Domain Controller Removal..............................................................................................478
See Also.................................................................................................................................. 479
Clean Up Server Metadata......................................................................................................... 480
See Also.................................................................................................................................. 482
Administering Active Directory Domain Rename........................................................................482
In this guide............................................................................................................................. 483
Introduction to Administering Active Directory Domain Rename.................................................483
Domain rename requirements.................................................................................................483
Managing Active Directory Domain Rename..............................................................................484
Preparing for the Domain Rename Operation.............................................................................485
Adjust Forest Functional Level.................................................................................................... 485
Setting forest functional level to Windows Server 2003 or Windows Server 2008...................485
Create Necessary Shortcut Trust Relationships.........................................................................486
Types of trust relationships...................................................................................................... 487
Precreating parent-child trust relationships for a restructured forest.......................................487
Precreating a parent-child trust relationship.........................................................................487
Pre-creating multiple parent-child trust relationships............................................................488
Precreating a tree-root trust relationship with the forest root domain...................................489

Creating shortcut trust relationships.....................................................................................490
Prepare DNS Zones.................................................................................................................... 491
Redirect Special Folders to a Standalone DFSN........................................................................492
Relocate Roaming User Profiles to a Standalone DFSN............................................................492
Configure Member Computers for Host Name Changes............................................................493
Conditions for automatic computer name change...................................................................493
Replication effects of renaming large numbers of computers..................................................494
Using Group Policy to apply the new primary DNS suffix........................................................495
Apply the new primary DNS suffix before renaming domains..............................................495
Apply Group Policy in stages to avoid significant replication................................................495
Configuration required before the application of Group Policy.............................................496
Configuring member computers for host name changes in large deployments.......................497
Determine the primary DNS Suffix configuration..................................................................498
Determine whether Group Policy controls the primary DNS suffix.......................................498
Configure the domain to allow a primary DNS suffix that does not match the domain name
.......................................................................................................................................... 499
Apply Group Policy to set the primary DNS suffix................................................................500
Prepare Certification Authorities................................................................................................. 501
Exchange-Specific Steps: Prepare a Domain that Contains Exchange......................................503
Performing the Domain Rename Operation................................................................................503
Set Up the Control Station.......................................................................................................... 504
Freeze the Forest Configuration.................................................................................................506
Back Up All Domain Controllers.................................................................................................. 506
Generate the Current Forest Description....................................................................................506
Specify the New Forest Description............................................................................................ 509
Renaming application directory partitions................................................................................512
DNS data................................................................................................................................. 513
TAPI data................................................................................................................................. 513
Specifying the source domain controllers................................................................................514
Reviewing the new forest description......................................................................................514
Generate Domain Rename Instructions......................................................................................515
Push Domain Rename Instructions to All Domain Controllers and Verify DNS Readiness.........518
Pushing domain rename instructions to all domain controllers................................................518
Verifying DNS readiness.......................................................................................................... 520
Verify Readiness of Domain Controllers.....................................................................................522

Run Domain Rename Instructions..............................................................................................524
Exchange-Specific Steps: Update the Exchange Configuration and Restart Exchange Servers 527
Unfreeze the Forest Configuration.............................................................................................. 527
Re-establish External Trusts....................................................................................................... 528
Fix Group Policy Objects and Links............................................................................................529
Completing the Domain Rename Operation...............................................................................532
Verify Certificate Security............................................................................................................ 532
Preparing URLs for CRL distribution point and Authority Information Access (AIA) extensions
after a domain rename......................................................................................................... 533
Verifying the use of UPNs........................................................................................................ 533
Enabling certificate enrollment in a renamed domain..............................................................534
Verifying the validity of CRL distribution point and AIA extensions..........................................537
Renewing subordinate and issuing CA certificates..................................................................537
Publish new CRLs................................................................................................................... 537
Updating domain controller certificates....................................................................................538
Changing the user identity for the NDES add-on.....................................................................538
Perform Miscellaneous Tasks..................................................................................................... 538
Back Up Domain Controllers....................................................................................................... 541
Restart Member Computers........................................................................................................ 542
Exchange-Specific Steps: Verify the Exchange Rename and Update Active Directory Connector
................................................................................................................................................ 543
Perform Attribute Cleanup........................................................................................................... 543
Rename Domain Controllers....................................................................................................... 544
Additional Resources for the Domain Rename Operation..........................................................545
Appendix A: Command-Line Syntax for the Rendom Tool..........................................................545
Appendix B: Command-Line Syntax for the Gpfixup Tool...........................................................550
Appendix C: Checklists for the Domain Rename Operation.......................................................553
Satisfying domain rename requirements.................................................................................553
Preparing for the domain rename operation............................................................................556
Performing the domain rename operation...............................................................................557
Completing the domain rename operation...............................................................................558
Appendix D: Worksheets for the Domain Rename Operation.....................................................559

Worksheet 1: Domain Name Change Information...................................................................559
Worksheet 2: Trust Information................................................................................................560
Worksheet 3: DNS Zone Information.......................................................................................560
Worksheet 4: DFSN, Folder Redirection, and Roaming Profiles.............................................561
Worksheet 5: Domain Controller Information...........................................................................561
Worksheet 6: Domain Rename Execution Readiness.............................................................562
Worksheet 7: Certification Authority (CA) Information.............................................................562
Additional Resources.................................................................................................................. 562
Active Directory Domain Services Operations Guide - cover......................................................563
Section Heading...................................................................................................................... 563
Subsection Heading............................................................................................................. 563

Guide
This operations guide provides administering and management information for
Active Directory Domain Services (AD DS) directory service technologies in the
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
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
26
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 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

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

28
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.
29
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.
30
Domain-wide authentication: An authentication setting that permits unrestricted access by

any users in the specified domain to all available shared resources that are located in the
local domain. This is the default authentication setting for external trusts.
Forest-wide authentication: An authentication setting that permits unrestricted access by

any users in the specified forest to all available shared resources that are located in any of
the domains in the local forest. This is the default authentication setting for forest trusts.
Selective authentication: An authentication setting that restricts access over an external

trust or forest trust to only those users in a specified domain or specified forest who have
been explicitly given authentication permissions to computer objects (resource computers)
that reside in the local domain or the local forest. This authentication setting must be enabled
manually.
Trust password: An option in which both domains in a trust relationship share a password,
which is stored in the trusted domain object (TDO) object in Active Directory 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
31
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
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).
32
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.
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.
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
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
33
Create a One-Way, Outgoing, External Trust for One Side of the Trust
Create a One-Way, Outgoing, External Trust for Both Sides of the Trust
Create a Two-Way, External Trust for One Side of the Trust
Create a Two-Way, External Trust for Both Sides of the Trust
Create a One-Way, Incoming, External Trust

for One Side of the Trust
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
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.
34
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.
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
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.
35
LinkId=83477.
To create a one-way, incoming, external trust for both sides of the trust
7. On the Sides of Trust page, click Both this domain and the specified domain, and
then click Next.
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.
36
Create a One-Way, Outgoing, External Trust

You can use this procedure to create one side of a one-way, outgoing, external trust. Although
administrator for the reciprocal domain uses his or her credentials to create the incoming side of
can use the procedure Create a One-Way, Outgoing, External Trust for Both Sides of the Trust to
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
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.
LinkId=83477.
To create a one-way, outgoing, external trust for one side of the trust
6. On the Direction of Trust page, click One-way: outgoing, and then click Next.
8. On the Outgoing Trust Authentication Level page, do one of the following, and then
37
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
Note
forest must follow the procedure Create a One-Way, Incoming, External Trust for One
Create a One-Way, Outgoing, External 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
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
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.
38

LinkId=83477.
To create a one-way, outgoing, external trust for both sides of the trust
name) of the domain, and then click Next.
then click Next.
9. On the Outgoing Trust Authentication Level--Local Domain page, do one of the
39
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.
LinkId=83477.
To create a two-way, external trust for one side of the trust
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.
6. On the Direction of Trust page, click Two-way, and then click Next.
click Next:

40
Note
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.
LinkId=83477.
41
To create a two-way, external trust for both sides of the trust

then click Next.
9. On the Outgoing Trust Authentication Level--Local Domain page, do one of the
10. On the Outgoing Trust Authentication Level--Specified Domain page, do one of the
42
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
Netdom.exe
For more information about how to use the Netdom command-line tool to create a shortcut trust,
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
43
Create a One-Way, Incoming, Shortcut Trust

You can use this procedure to create one side of a one-way, incoming, shortcut trust. Although
administrator for the reciprocal domain uses his or her credentials to create the outgoing side of
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
the Netdom command-line tool to create a shortcut trust, see Netdom Overview
LinkId=83477.
To create a one-way, incoming, shortcut trust for one side of the trust
44
Note
forest must follow the procedure Create a One-Way, Outgoing, Shortcut Trust for One
Create a One-Way, Incoming, Shortcut 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
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.
LinkId=83477.
45
To create a one-way, incoming, shortcut trust for both sides of the trust
then click Next.
Create a One-Way, Outgoing, Shortcut Trust

You can use this procedure to create one side of a one-way, outgoing, shortcut trust. Although
administrator for the reciprocal domain uses his or her credentials to create the incoming side of
can use the procedure Create a One-Way, Outgoing, Shortcut Trust for Both Sides of the Trust to
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
46
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
LinkId=83477.
To create a one-way, outgoing, shortcut trust for one side of the trust
47
Note
forest must follow the procedure Create a One-Way, Incoming, Shortcut Trust for One
Create a One-Way, Outgoing, Shortcut Trust

You can this procedure to create both sides of a one-way, outgoing, shortcut trust. You must
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
LinkId=83477.
To create a one-way, outgoing, shortcut trust for both sides of the trust
48
then click Next.
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
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.
49

LinkId=83477.
To create a two-way, shortcut trust for one side of the trust
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
50
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 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.
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
LinkId=83477.
To create a two-way, shortcut trust for both sides of the trust
then click Next.
51
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
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
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.
namespace are running Windows Server 2003, configure DNS conditional forwarders in each
DNS namespace to route queries for names in the other namespace.
52
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
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.
53
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
use the Netdom command-line tool to create a forest trust, see Netdom Overview
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
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.
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.
54
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
Trust Wizard) to access resources in another Windows Server 2008 forest or
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.
the Netdom command-line tool to create a forest trust, see Netdom Overview
To create a one-way, incoming, forest trust for both sides of the trust
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.
55
then click Next.
9. On the Outgoing Trust Authentication Level--Specified Forest page, do one of the
Click Forest-wide authentication.
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
Trust Wizard) to be accessed by users in another Windows Server 2008 forest or
56
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.
To create a one-way, outgoing, forest trust for one side of the trust
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.
click Next:
57
established until the first time the trust is used by users.
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
Trust Wizard) to be accessed by users in another Windows Server 2008 forest or
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.
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
58
establish an outgoing forest trust, and then click Properties.
then click Next.
9. On the Outgoing Trust Authentication Level--Local Forest page, do one of the
10. On the Trust Selections Completepage, review the results, and then click Next.
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
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
59
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.
To create a two-way, forest trust for one side of the trust
establish a two-way forest trust, and then click Properties.
4. On the Trust Name page, type the Domain Name System (DNS) name of the domain,
and then click Next.
click Next:
60
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
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.
http://go.microsoft.com/fwlink/?LinkId=83477.) If you are a member of the Incoming Forest Trust
61
To create a two-way, forest trust for both sides of the trust

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.
then click Next.
9. On the Outgoing Trust Authentication Level--Local Forest page, do one of the
10. On the Outgoing Trust Authentication Level--Specified Forest page, do one of the
62
Creating Realm Trusts

You can create a realm trust to form a one-way or two-way, nontransitive or transitive trust with
non-Windows Kerberos realms in your organization. You can create the trust when you 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
Task requirements
Netdom.exe
For more information about how to use the Netdom command-line tool to create a realm trust,
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.
Note
Kerberos realm names require uppercase characters.
63
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
LinkId=83477.
To create a one-way, incoming, realm trust
establish a realm trust, and then click Properties.
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.
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.
Create a One-Way, Outgoing, Realm Trust

A one-way, outgoing realm trust allows resources in your Windows Server 2008 domain or
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
64
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
You can create this realm trust by using the New Trust Wizard in the Active Directory Domains
the Netdom command-line tool to create a realm trust, see Netdom Overview
Membership in Account Operators, Domain Admins, or Enterprise Admins in
http://go.microsoft.com/fwlink/?LinkId=83477.
To create a one-way, outgoing, realm trust
2. In the console tree, right-click the domain for which you want to establish a realm trust,
and then click Properties.
realm in uppercase characters, and then click Next.
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.
65
Create a Two-Way, Realm Trust

A two-way, realm trust allows users in your Windows Server 2008 domain or
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
You can create this realm trust by using the New Trust Wizard in the Active Directory Domains
use the Netdom command-line tool to create a realm trust, see Netdom Overview
LinkId=83477.
To create a two-way, realm trust
establish a realm trust, and then click Properties.
realm, and then click Next.
66
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
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
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
67
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).
(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
2. In the console tree, right-click the domain that contains the trust that you want to validate,
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
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
68
Value
Description
<TrustingDomainName>
Specifies the Domain Name System

(DNS) name (or NetBIOS name) of the
trusting domain in the trust that is being
created.
<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 recreate 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
(AD DS), or equivalent, is the minimum required to complete these procedures. Review details
LinkId=83477.
Removing a manually created trust
Using a command prompt

To remove a manually created trust using the Windows interface
2. In the console tree, right-click the domain that contains the trust that you want to remove,
3. Click the Trusts tab.
4. In either Domains trusted by this domain (outgoing trusts) or Domains that trust
this domain (incoming trusts), click the trust to be removed, and then click Remove.
5. Do one of the following, and then click OK:
Click No, remove the trust from the local domain only.
69
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

netdom trust <TrustingDomainName> /d:<TrustedDomainName> /remove
/UserD:<User> /PasswordD:*
Parameter
Description
The Domain Name System (DNS) name

(or NetBIOS name) of the trusting domain
<TrustedDomainName>
The DNS name (or NetBIOS name) of

the domain that will be trusted in the trust
that is being created.
<User>
The account name of the user authorized

to create the trust.
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
70
example, the DNS forest name fabrikam.com is a unique name suffix within the fabrikam.com
forest.
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
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
Netdom.exe
For more information about using the Netdom command-line tool to modify name suffix routing,
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).
71
Notes
When you disable a name suffix, the Domain Name System (DNS) name and all child
names of that name will be disabled.

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

2. In the console tree, right-click the forest root domain for the forest trust that you want to
administer, and then click Properties.
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
72
To modify routing for an existing subordinate name suffix

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

2. In the console tree, right-click the domain that you want to administer, and then click
73
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
74
filter quarantining enforced by default. These external trusts must be configured manually to
enable SID filter quarantining.
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
Task requirements
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).
75
Disable SID filter Quarantining
Reapply SID Filter Quarantining
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
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
LinkId=83477.
To disable SID filter quarantining for the trusting domain
1. Open a Command Prompt.
Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No
/userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>
76
Parameter
Description

<TrustedDomainName>
The DNS name (or NetBIOS name) of the

domain that will be trusted in the trust that
is being created.
<DomainAdministratorAcct>
The user account name with the

appropriate administrator credentials to
modify the trust.
<DomainAdminPwd>
The password of the user account in

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

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
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
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
77
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 SID filter quarantining for the trusting domain
Netdom trust <TrustingDomainName> /domain:<TrustedDomainName>
/quarantine:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>
Term
Definition

<TrustedDomainName>

domain that will be trusted in the trust that
is being created.

modify the trust.
<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).
78
Task requirements
Either of the following tools is required to perform the procedures for this task:
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).
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).
LinkId=83477.
Enabling selective authentication over an external

trust

79
Using a command line

To enable selective authentication over an external trust using the Windows interface
Properties.
Domains that trust this domain (incoming trusts), click the external trust that you
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
/SelectiveAUTH:Yes /userD:<DomainAdministratorAcct>
/passwordD:<DomainAdminPwd>
Parameter
Description

in the trust that is being managed.
<TrustedDomainName>

domain that is trusted in the trust that is
being managed.

modify the trust.
<DomainAdminPwd>

80
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
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 a command line

To enable selective authentication over a forest trust using the Windows interface
2. In the console tree, right-click the domain node for the forest root domain, and then click
Properties.
4. On the Authentication tab, click Selective authentication, and then click OK.
Note
81
forest trust, connect to a domain controller in the forest root domain of the trusted forest,
and then use Active Directory Domains and Trusts to view the authentication settings for
the outgoing side of the same trust.
To enable selective authentication over a forest trust using a command line
/SelectiveAUTH:Yes /userD:<DomainAdministratorAcct>
/passwordD:<DomainAdminPwd>
Parameter
Description

(or NetBIOS name) of the trusting forest
root domain in the trust that is being
managed.
<TrustedDomainName>

forest root domain that is trusted in the
trust that is being managed.

modify the trust.
<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.
82

LinkId=83477.
To enable domain-wide authentication over an external trust
Properties.
Domains that trust this domain (incoming trusts), click the external trust that you
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
You can use this procedure to enable forest-wide authentication over a forest trust.
LinkId=83477.
To enable forest-wide authentication over a forest trust
2. In the console tree, right-click the forest root domain, and then click Properties.
83

4. On the Authentication tab, click Forest-wide authentication, and then click OK.
Note
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
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
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.
84
3. Right-click the computer object that you want users in the trusted domain or forest to
access, and then click Properties.
4. On the Security tab, do one of the following:
In Group or user names, click the user names or group names for which you want
to grant access to this computer, select the Allow check box next to the Allowed to
Authenticate permission, and then click OK.
Click Add. In Enter the object names to select, type the name of the user object or
group object for which you want to grant access to this resource computer, and then
click OK. Select the Allow check box next to the Allowed to Authenticate
permission, and then click OK.
Appendix: New Trust Wizard Pages

Understanding how user input is handled during the trust creation process will help you provide
information when it is most necessary and help you better prepare for your specific procedure.
This section explains the two most complex pages in the New Trust Wizard:
Direction of Trust
Sides of Trust
Direction of Trust
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.
85
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 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.
86
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.
87
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.
88
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:
89
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 timeb.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
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
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
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
90
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:
91
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 and
92
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:

93
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).

94
Set Your Computer Clock Via the Internet: NIST Internet Time Service (ITS)
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
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.
/computer:<target>

(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.
/samples:<n>
Specifies the number of time samples that

will be returned from the target computer
to test basic NTP communication.
/dataonly
Specifies that results show only data, not

graphics.
If this procedure fails, check the System event log for Time-Service errors and follow any
95
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
Configures the computer to synchronize

time.
/manualpeerlist:<peers>
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.
/syncfromflags:manual
Specifies that time will be synchronized

with peers in the manual peer list.
/reliable:yes
Specifies that the computer is a reliable

time source.
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.
96

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.
97
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
To change the Windows Time service configuration on the PDC emulator in the forest
root domain
w32tm /config /syncfromflags:domhier /reliable:no /update
98
Parameter
Description
W32tm /config /update
Configures the client to synchronize time.
/syncfromflags:domhier
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.
/reliable:no
Removes the status of reliable time

source.
net stop w32time
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.
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.
99
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.
accounts and group memberships at http://go.m;icrosoft.com/fwlink/?LinkId=83477.
To enable Windows Time Service debug logging
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:
W32tm
100
Configure a Manual Time Source for a Selected Client Computer
Configure a Client Computer for Automatic Domain Time Synchronization
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
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
To configure a manual time source for a selected client computer
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
101
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.
/computer:<target>

(DNS) name or IP address of the NTP
server that you are comparing the local
computer's time against, such as
time.windows.com.
/samples:<n>
Specifies the number of time samples that

will be returned from the target computer
to test basic NTP communication.
/dataonly
Specifies that results show only data, not

graphics.
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
Configures the computer for time

synchronization.
/manualpeerlist:<peers>
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.
/syncfromflags:manual
Specifies that time is synchronized with

peers in the manual peer list.
102
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
To configure a client computer for automatic domain time synchronization
w32tm /config /syncfromflags:domhier /update
Parameter
Description
Configures the computer for time

synchronization.
/syncfromflags:domhier
Specifies that time is synchronized with

computers in the domain hierarchy.
net stop w32time
net start w32time
103
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
To complete this task, perform the following procedure:
Restore the Windows Time Service on the Local Computer to the Default Settings
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
To restore the Windows Time service on the local computer to the default settings
net stop w32time
w32tm /unregister
w32tm /register
104
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.
105
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 SYSVOL share. When a change to a file occurs, FRS replicates the
106
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
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:
107
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
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
108
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
109
%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
%systemroot\SYSVOL\domain
Policies and scripts
msDFSR-StagingPath
%systemroot\SYSVOL\staging\domain
Staging area folders

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

110
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
DFS Management
Change the Quota That Is Allocated to the SYSVOL Staging Folder
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
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.
111
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.
Active Directory Sites and Services
Event Viewer
Net.exe
Dcdiag.exe
112
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

You can use this procedure to examine the connection objects for a domain controller and identify
its replication partners.
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
113
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
Membership in Domain Admins, or equivalent, is required to complete this procedure. Review
details about using the appropriate accounts and group memberships at
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.
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
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.
114
For information about default SYSVOL permissions, see Reapply Default SYSVOL
Security Settings.

You can use this procedure to verify that Active Directory replication is functioning properly on a
domain controller.
To verify Active Directory replication
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.

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.
115
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
msDFSR-RootPath in
AD DS
msDFSR-StagingPath in
AD DS
SysVol Netlogon
parameter in the registry
Sysvol junction point
Staging areas junction

point
Current value
New value
116
To gather the SYSVOL path information

Perform the following procedures to gather values for SYSVOL paths and record the data in the
preceding table.
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\Parameter
s.
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.
117
To determine the value in the sysvol junction point

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
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
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.
118
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.
To stop the DFS Replication service or Netlogon service, or both, by using the Windows
GUI
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
net stop dfsr
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).
119

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, rightclick 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.
120
To change the SYSVOL root path or the staging areas path, or both
4. In the console tree, expand the domain component, and then expand OU=Domain
Controllers.
System Volume.
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
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
121
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
2. To start the DFS Replication service, at the command prompt, type the following
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
122
To force replication over a connection

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
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
123
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.
Task requirements
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

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
13. Force Replication Between Domain Controllers
124

connection objects.
Note

Netlogon Shares
125

net share

Note
Security Settings.

domain controller.
126

Note
/v
option.
the problem.

domain controller.
Note
127
through 5.
and 5.
and 3.
structure.
Parameter
msDFSR-RootPath in
AD DS
AD DS
SysVol Netlogon

point
Current value
New value

preceding table.
128
Controllers.
System Volume.
not selected.
s.
new location.
dir /a:L
129
location.
dir /a:L

Netlogon Service
Note
restarted.
GUI
130
line
net stop dfsr
net stop netlogon
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
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.
131
Stop the DFS Replication Service and Netlogon Service. Do not make any changes to the
SYSVOL location while these services are running.

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.
3. Change directories to the existing SYSVOL directory that you want to move. By default,
the path to this directory is %systemroot%\SYSVOL.
robocopy <Source Folder> <Destination Folder> /copyall /mir /b /r:0 /xd
"DfsrPrivate" /xf "DfsrPrivate"
Note
The destination folder must be empty.
132
Parameter
Description
<Source Folder>
The path to the SYSVOL directory that you

are copying. The default location is
%systemroot%\SYSVOL.
<Destination Folder>
The path to the new SYSVOL location that

you created in step 1.
/copyall
Copies the following file information: data,

attributes, time stamps, NTFS access
control list (ACL), owner information, and
auditing information.
/mir
Mirrors the directory tree that you are

copying.
/b
Copies files in backup mode. Robocopy

uses backup mode to override file and
folder permission settings (ACLs).
/r:0
Specifies performing 0 (zero) retries on

failed copies.
/xd "DfsrPrivate"
Excludes the DfsrPrivate directory from the

copy.
/xf "DfsrPrivate"
Excludes the DfsrPrivate file from the copy.
to the original, open a Command Prompt as an administrator: On the Start menu, rightclick 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.
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.
133
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.
To create the sysvol root junction point
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
mklink /J <FQDN> <New sysvol root junction path>
Example: mklink
/J contoso.com D:\ContosoRoot\SYSVOL\domain
Parameter
Definition
mklink /J
Creates a junction point for the specified

domain in the specified path location.
<FQDN>
The fully qualified domain name of the

SYSVOL domain
<New sysvol root junction path>
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
dir /a:L
134
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.
To change the SYSVOL root path or the staging areas path, or both
4. In the console tree, expand the domain component, and then expand OU=Domain
Controllers.
System Volume.
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.
135
See Also
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.
To change the SYSVOL Netlogon parameters
2. Navigate to
s.
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.
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.
136
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).
To reapply default SYSVOL security settings
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]
137
Description=default perms for sysvol

[File Security]
;"%SystemRoot%\SYSVOL",0,"D:AR(A;OICI;FA;;;BA)"
"%Sysvol%",2,"D:P(A;CIOI;GRGX;;;AU)(A;CIOI;GRGX;;;SO)(A;CIOI;GA;;;BA)
(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"
"%Sysvol%\domain\policies",2,"D:P(A;CIOI;GRGX;;;AU)(A;CIOI;GRGX;;;SO)
(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)(A;CIOI;GRGWGXSD;;;PA)"
Use this file to apply the security settings to the new SYSVOL folders.
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
Performs directed configurations.
/cfg <path> (to security template)
Specifies the path where you saved

Sysvol.inf in step 11.
/db <path> (to database)
Specifies the path to the database that is

used to perform the security configuration.
/overwrite
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.
138

Netlogon Service
successfully.
GUI
command line
net start dfsr
then press ENTER:
net start netlogon
Notes
ENTER.
139

Controllers
for that site.
OK.
See Also
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
%\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
140
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
Net.exe
ADSI Edit
Regedit.exe
Dir.exe
Mklink.exe
To complete this task, perform the following procedures in order:

3. Change the SYSVOL Netlogon Parameters
4. Create the SYSVOL Root Junction Point
5. Start the DFS Replication Service and Netlogon Service

domain controller.
141
Note
through 5.
and 5.
and 3.
structure.
Parameter
msDFSR-RootPath in
AD DS
AD DS
SysVol Netlogon

point
Current value
New value
142

preceding table.
Controllers.
System Volume.
not selected.
s.
new location.
143

dir /a:L
location.
dir /a:L

Netlogon Service
144
Note
restarted.
GUI
line
net stop dfsr
net stop netlogon
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.
145

To change the SYSVOL Netlogon parameters
2. Navigate to
s.
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.
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
To create the sysvol root junction point
146
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
mklink /J <FQDN> <New sysvol root junction path>
Example: mklink
/J contoso.com D:\ContosoRoot\SYSVOL\domain
Parameter
Definition
mklink /J
Creates a junction point for the specified

domain in the specified path location.
<FQDN>
The fully qualified domain name of the

SYSVOL domain
<New sysvol root junction path>
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
dir /a:L
Verify the presence of the <JUNCTION> folder type and the value that you specified in
step 3.

Netlogon Service
successfully.
147

GUI
command line
net start dfsr
then press ENTER:
net start netlogon
Notes
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
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.
148
Use the procedures in this section only on a domain controller that does not have a functioning
SYSVOL.
Task requirements
Event Viewer
Dcdiag.exe
ADSI Edit
Net.exe
Regedit.exe
Windows Explorer
Mklink.exe

1. Identify Replication Partners
You will import the SYSVOL from a replication partner.
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.
Verify that replication is working on both replication partners.
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.

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
149

connection objects.
Note

Netlogon Shares
150

net share

Note
Security Settings.

domain controller.
151

Note
/v
option.
the problem.

domain controller.
Note
152
through 5.
and 5.
and 3.
structure.
Parameter
msDFSR-RootPath in
AD DS
AD DS
SysVol Netlogon

point
Current value
New value

preceding table.
153
Controllers.
System Volume.
not selected.
s.
new location.
dir /a:L
154
location.
dir /a:L
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 Step-by-Step Guide
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.
155
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
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
156
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.
bcdedit /set safeboot dsrepair
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
shutdown -t 0 -r
Value
Description
/set safeboot dsrepair
Configures the boot process to start in DSRM.
shutdown t 0 -r
Shuts down the server and restarts it.
/deletevalue safeboot
Returns the boot process to the previous

setting.
See Also
157

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.
Note
Administrator account. However, on domain controllers that are running
Windows Server 2008, you can change this behavior by modifying the
command line or to restart the domain controller in DSRM:
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
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,
158
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
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
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.
Configuration.
then click OK.
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.
159

normally:
Configuration.
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
Desktop Connection.
then click Connect.
c.
and then click OK.
2. Open a command prompt. 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.
5. The domain controller name should still be showing in Computer. If it is not, select it in
Other User.
160
normally:
a. In DSRM, open a command prompt, type the following command, and then press
ENTER:
b. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 r
session.
Value
Description
shutdown t 0 -r

setting.
See Also
Enable Remote Desktop
Create a Remote Desktop Connection

Netlogon Service
Note
restarted.
161

GUI
line
net stop dfsr
net stop netlogon
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).
162
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.

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
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.
163
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
robocopy <Source Folder> <Destination Folder> /copyall /mir /b /r:0 /xd
"DfsrPrivate" /xf "DfsrPrivate"
164
Parameter
Description
<Source Folder>
Drive letter and path to the SYSVOL2

directory on the source domain controller.
<Destination Folder>
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.
/copyall
Copies the following file information: data,

attributes, time stamps, NTFS access
control list (ACL), owner information, and
auditing information.
/mir
Mirrors the directory tree that you are

copying.
/b
Copies files in backup mode. Backup mode

allows Robocopy to override file and folder
permission settings (ACLs).
/r:0
Specifies performing 0 (zero) retries on

failed copies.
/xd "DfsrPrivate"
Excludes the DfsrPrivate directory from the

copy.
/xf "DfsrPrivate"
Excludes the DfsrPrivate file from the copy.
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.
165
See Also
Check the Status of the SYSVOL and Netlogon Shares
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.
166
Initial global catalog replication

When you add a global catalog server to a site, the Knowledge Consistency Checker (KCC)
updates the replication topology, after which replication of partial domain directory partitions that
are available within the site begins. Replication of partial domain directory partitions that are
available only from other sites begins at the next scheduled interval.
Adding subsequent global catalog servers within the same site requires only intrasite replication
and does not affect network performance. Replication of the global catalog potentially affects
network performance only when 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)
167
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 highpriority services are not interrupted.
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
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
Repadmin.exe
Dcdiag.exe
To complete this task, perform the following procedures.
168
Note
Some procedures are performed only when you are configuring the first global catalog
server in a site.
1. Determine Whether a Domain Controller Is a Global Catalog Server
2. Designate a Domain Controller to Be a Global Catalog Server
3. Monitor Global Catalog Replication Progress
4. Verify Successful Replication to a Domain Controller
Determine Whether a Domain Controller Is a

Global Catalog Server
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).
To determine whether a domain controller is a global catalog server
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
Designate a Domain Controller to Be a

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

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.
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
LinkId=83477.
To monitor global catalog replication progress
dcdiag /s:<servername> /v | find "%"
170
Parameter
Description
s:<servername>
Specifies the name of the global catalog

server that you want to monitor.
/v | find "%"
Finds the percentage of replication, and

provides extended information.
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
To verify successful replication to a domain controller
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
171
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.
<servername>
The name of the destination domain

controller.
/u:
Specifies the domain name and user name,

separated by a backslash, for a user who
has permissions to perform operations in
AD DS.
<domainname>
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.)
<username>
The name of an administrative account in

that domain.
/pw:*
Specifies the domain password for the user

named in <username>. * provides a
Password: prompt when you press
ENTER.
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
172
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
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.
To hide the column, right-click the column, and then click Hide.
Or
To delete the column, right-click the selected column, and then click Delete.
7. Select row 1 beneath the column heading row. 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.
173
Replication was never successful.
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
Ldp.exe
Nltest.exe
DNS snap-in

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
LinkId=83477.
Verifying global catalog readiness

174
Using a command prompt

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
nltest /server:<servername> /dsgetdc:<domainname>
Parameter
Description
<servername>
Specifies the name of the domain

controller that you have designated as a
global catalog server.
<domainname>
Specifies the name of the domain to which

the server belongs.
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
175

LinkId=83477.
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

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.
176
To clear the global catalog setting

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
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.
177
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.
Careful placement of your operations masters becomes more important as you add more
domains and sites as you build your forest.
178
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
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
179
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-ofdate 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 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:
180
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.
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.
181
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
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
182
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.

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
183
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
Repadmin.exe
Determine Whether a Domain Controller Is a Global Catalog Server
Create a Connection Object on the Operations Master and Standby

184
Verify Successful Replication to a Domain Controller

object.
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
185
Administrative credentials
To create a connection object on the operations master and standby
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.

Controller
186

Note
domain.
187
Value
Description
repadmin /showrepl

<servername>

controller.
/u:

AD DS.
<domainname>

<username>

that domain.
/pw:*

ENTER.
then press ENTER.
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
188
readability.
3. Open Excel.
Or
Custom Filter.
controllers.
189
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
forest-level operations master roles to the first domain controller. After the domain is created and
functioning, you might transfer various operations master roles to different domain controllers to
optimize performance and simplify administration.
The 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
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
190
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 Schema snap-in
Active Directory Users and Computers
Ntdsutil.exe
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
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).
To install the Active Directory Schema snap-in
appears, provide Domain Admins credentials, and then click Continue.
regsvr32 schmmgmt.dll
3. Click Start, click Run, type mmc, and then click OK.
191
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
snap-in 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.

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
192
(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
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.

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.
transfer the domain naming operations master role.
Note
command, you can also type ? at the Ntdsutil.exe command prompt.
193
To transfer the domain naming master

1. Open Active Directory Domains and Trusts: On the Start menu, point to Administrative
Tools, and then click Active Directory Domains and Trusts. If the User Account
Control dialog box appears, provide Enterprise Admins credentials, if required, and then
click Continue.
2. In the console tree, right-click Active Directory Domains and Trusts, and then click
Change Active Directory Domain Controller.
3. Ensure that the correct domain name is entered in Look in this domain.
The available domain controllers from this domain are listed.
4. In the Name column, click the domain controller to which you want to transfer the domain
naming master role, and then click OK.
5. At the top of the console tree, right-click Active Directory Domains and Trusts, and
then click Operations Master.
6. The name of the current domain naming master appears in the first text box. The domain
controller to which you want to transfer the domain naming master role should appear in
the second text box. If this is not the case, repeat steps 1 through 4.
7. Click Change. To confirm the role transfer, click Yes. Click OK again to close the
message box indicating that the transfer took place. Click Close to close the Operations
Master dialog box.
Transfer the Domain-Level Operations

Master Roles
You can use this procedure to transfer the following three domain-level operations master (also
known as flexible single master operations or FSMO) roles:
Primary domain controller (PDC) emulator operations master
Relative ID (RID) operations master
Infrastructure operations master
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) snapin, 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.
194
transfer the operations master role.
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.
4. In the Name column, click the name of the domain controller to which you want to
transfer the role, and then click OK.
then click Operations Masters.
The name of the current operations master role holder appears in the Operations
master box. The name of the domain controller to which you want to transfer the role
appears in the lower box.
6. Click the tab for the operations master role that you want to transfer: RID, PDC, or
Infrastructure. Verify the computer names that appear, and then click Change. Click Yes
to transfer the role, and then click OK.
7. Repeat steps 5 and 6 for each role that you want to transfer.
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.
195

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

is the name of the domain controller that belongs to the domain that
contains the operations masters.
<servername>
5. After you receive confirmation of the connection, type

this menu.
6. At the fsmo
maintenance:
prompt, type select
7. At the select operations target: prompt, type

press ENTER.
quit,
and then press ENTER to exit
operation target,
and then press ENTER.
list roles for connected server,
and then
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
prompt, type quit, and then press ENTER to close the window.
ntdsutil:

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.
196
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 replication to the domain controller that will be seizing the role.
Seize the Operations Master Role
View the Current Operations Master Role Holders

Controller
197

Note
domain.
198
Value
Description
repadmin /showrepl

<servername>

controller.
/u:

AD DS.
<domainname>

<username>

that domain.
/pw:*

ENTER.
then press ENTER.
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
199
readability.
3. Open Excel.
Or
Custom Filter.
controllers.
200
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.
To seize an operations master role
2. At the command prompt, type ntdsutil, and then press ENTER.
4. At the fsmo
maintenance:
5. At the server
connections: prompt, type connect to server<servername> (where

is the name of the domain controller that will assume the operations master
role), and then press ENTER.
<servername>

7. Depending on the role that you want to seize, at the
appropriate command, and then press ENTER.
quit,
fsmo maintenance:
prompt, type the
Role
Credentials
Command
Domain naming master
Enterprise Admins
Seize domain naming

master
Schema master
Enterprise Admins
Seize schema master
Infrastructure master
Domain Admins
Seize infrastructure master
Primary domain controller

(PDC) emulator
Domain Admins
Seize pdc
RID master
Domain Admins
Seize rid master
The system asks for confirmation. It then attempts to transfer the role. When the transfer
201
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.

Holders
click OK.
3. At the fsmo
maintenance:
4. At the server

<servername>

this menu.
6. At the fsmo
maintenance:
prompt, type select
quit,
operation target,

202

press ENTER.
and then
role.
ntdsutil:
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
203
on other domain controllers. For example, to configure the system so that the domain controller
that hosts the PDC 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
Regedit.exe

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
204
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.
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.
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.
205
Caution
Registry Editor bypasses standard safeguards, which allows settings that can damage
up critical volumes first. For information about backing up critical volumes, see
Administering Active Directory Backup and Recovery.
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.
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
206

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 criticalvolumes backups and full server backups. You can use the Windows Server Backup commandline 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:
207
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,CN-Windows 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.
Backing Up Active Directory Domain Services
Recovering Active Directory Domain Services

208
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
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 commandline 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.
209
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

210
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
Full server backup
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 (bare-metal)
recovery with Windows
Recovery Environment
(Windows RE)
No
Yes
Yes

from unbootable
conditions
No
Yes
Yes

specific files and folders
No
Yes
Yes
Can be created by using

Windows Server Backup
snap-in (GUI)
No
Yes
Yes
Can be created by using

Wbadmin.exe command
line tool
Yes
Yes
Yes
Has incremental backup

support
No*
Yes
Can be stored on a DVD

or on a network share if
the backup is performed
manually (is not a
scheduled backup)
No
Yes
Yes**
211
Feature
System state backup
Critical-volumes
Full server backup
backup
Can use any of the

Yes***
volumes that are included
in the backup as the
target volume
No
No
Can be scheduled by
using the Windows
Server Backup snap-in
Yes
Yes
No
* 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-domain-controller
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
212
captured as part of system state and critical-volume backups on domain controllers that are
also DNS servers.
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.
213
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.
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
214
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 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
215
this setting to reflect that frequency, and monitoring Event ID 2089, you ensure the backup
frequency that is established in your organization.
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)
Backup media, as follows:
Internal or external hard disk drive
Shared network folder
Writable DVD
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)
216
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\AllowS
SBToAnyVolume
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.
217
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
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.
218
8. On the Specify destination type page, click Local drives or Remote shared folder,
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.
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.
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.
wbadmin start systemstatebackup -backuptarget:<targetDrive>: -quiet
219
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.
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
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
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).
220
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.
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.
221
7. On the Specify destination type page, click Local drives or Remote shared folder,
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.
222
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:
223
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.
The target volume for an unscheduled backup can be a local drive, but it cannot be any of the
224
Perform a Full Server Backup of a Domain

(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.
To perform an unscheduled backup of all volumes by using the command line
wbadmin start backup -include:<sourceDrive_1>:,<sourceDrive_2>:,...
<sourceDrive_n>: -backuptarget:<targetDrive>: -quiet
Where:
<sourceDrive_x>
<targetDrive>
identifies the volume or volumes to be backed up, separated by

commas and no spaces.
identifies the local volume or the letter of the network shared drive or
physical disk drive to receive the backup.
the restore process.
Be aware of the following issues when you perform unscheduled backups:
The target volume for an unscheduled backup can be a local drive, but it cannot be any of the
225
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)
226
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
227
Windows Vista. When you enable 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
full-server recovery for more serious problems, as described in Solutions for hardware failure or
file corruption later in this topic.
228
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
229
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
230
you 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
because Active Directory replication is not required. For more information about installing
from media, see Installing an Additional Domain Controller by Using IFM.
231
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.
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
232
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
critical-volumes 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
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)
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.
233
Task requirements
Remote Desktop Connection (optional)
Wbadmin.exe
Bcdedit.exe

1. Restart the domain controller in DSRM by using one of the following methods:
Or
2. Restore AD DS from Backup (Nonauthoritative Restore)
3. Verify AD DS restore
Additional references

controller.
Note
234
normally.
Note
LinkId=83477.
Important

235

Configuration.
then click OK.
DSRM.
normally:
Configuration.
OK.
shutdown -t 0 -r
shutdown -t 0 -r
Value
Description
shutdown t 0 -r

setting.
236
See Also

Note
normally.
237
LinkId=83477.
Important
Desktop Connection.
then click Connect.
c.
and then click OK.
Configuration.
then click OK.
dropped.
238
Other User.
normally:
Configuration.
session.
Desktop Connection.
then click Connect.
c.
and then click OK.
then press ENTER:
shutdown -t 0 -r
239
Other User.
normally:
ENTER:
shutdown -t 0 r
session.
Value
Description
shutdown t 0 -r

setting.
See Also
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).
240
Note
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.
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.
wbadmin get versions -backuptarget:<targetDrive>:
-machine:<BackupComputerName>
Where:
<targetDrive>:
<BackupComputerName>
is the location of the backup that you want to restore.
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.
wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM>
241
-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.

same location or you have renamed the computer since the backup was taken.
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.
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.
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
242
unique identifier (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
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.
243
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
244
Active Directory data 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 Stepby-Step Guide for Using the Active Directory Database Mounting Tool in Windows Server 2008
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
245
application directory partition as authoritative, and do not perform the procedures for restoring
group memberships.
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.
246
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 backlinks. 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
pre-LVR 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 preWindows 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
247
text 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 controller that is
248
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.
249
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
Repadmin.exe
Bcdedit.exe (optional)
Ntdsutil.exe
To complete this task, perform procedures according to the conditions in your environment:
Procedures for restoring after deletions have replicated

250
Procedures for restoring before deletions have replicated
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
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.
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.
251
8. If the .ldf file shows back-links for objects in other domains, perform the procedures in
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.
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
domains.
252
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
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.
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.
Known Issues for Authoritative Restore

253
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
254
replication of 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.

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

Stop making changes to security groups in the forest if all of the following statements are
true:
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.
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.

After the authoritative restore procedure is complete, perform the following steps:
256
a. Verify group memberships in the domain of the recovery domain controller and on a
global catalog server in every other domain.
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.

controller.
Note
257
normally.
Note
LinkId=83477.
Important

Configuration.
then click OK.
DSRM.
normally:
258
Configuration.
OK.
shutdown -t 0 -r
shutdown -t 0 -r
Value
Description
shutdown t 0 -r

setting.
See Also

259
Note
normally.
LinkId=83477.
Important
260

Desktop Connection.
then click Connect.
c.
and then click OK.
Configuration.
then click OK.
dropped.
Other User.
normally:
Configuration.
261
session.
Desktop Connection.
then click Connect.
c.
and then click OK.
then press ENTER:
shutdown -t 0 -r
Other User.
normally:
ENTER:
shutdown -t 0 r
262
session.
Value
Description
shutdown t 0 -r

setting.
See Also

Note
263
Note
then press ENTER.
Where:
<targetDrive>:


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

264
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.
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
265
memberships of restored security principals. These steps are described in Create an LDIF File for
Recovering Back-Links for Authoritatively Restored Objects
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,
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
266
following LDIF files with link restore operations have been created
in the current working directory:
ar_20080209-091249_links_Corp.Contoso.com.ldf
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.
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.
To turn off inbound replication
appears, provide Domain Admins credentials, if requested, and then click Continue.
267
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 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
shows the effect of the command, which is that the
DISABLE_INBOUND_REPL option is now in effect.
Current DSA Options
the command. New
DSA Options
Turn on Inbound Replication

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
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
268
Value
Description
repadmin /syncall
Synchronizes a specified domain

controller with all replication partners.
<DomainControllerName>

of the domain controller on which you
want to synchronize replication with all
partners.
/e
Enterprise; includes partners in all sites.
/d
Identifies servers by their distinguished

names in messages.
/A
All; synchronizes all directory partitions

that are held on the home server.
/P
Pushes changes outward from the home

server.
/q
Runs in quiet mode; suppresses callback

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

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.
269
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.
To run an .ldf file to recover back-links after authoritative restore
Change directories, if necessary, to the directory of the .ldf file and its respective log files.
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.
Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects
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.
270
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.
To turn on inbound replication
appears, provide Domain Admins credentials, if requested, and then click Continue.
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
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 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.
271
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.
ENTER:
restore:
restore,
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.
restore:
and ntdsutil: prompts, type quit.
Restore AD DS from Backup (Nonauthoritative Restore)
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.
272
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
Ntdsutil.exe

1. Restart the domain controller in Directory Services Restore Mode (DSRM), as follows:
Or
2. Restore AD DS from Backup (Nonauthoritative Restore). Do not restart the domain controller.
3. Mark an application directory partition as authoritative

Note
273

normally.
LinkId=83477.
Important
Desktop Connection.
then click Connect.
c.
274
and then click OK.

Configuration.
then click OK.
dropped.
Other User.
normally:
Configuration.
session.
Desktop Connection.
then click Connect.
c.
and then click OK.
275
then press ENTER:
shutdown -t 0 -r
Other User.
normally:
ENTER:
shutdown -t 0 r
session.
Value
Description
shutdown t 0 -r

setting.
276
See Also

controller.
Note
normally.
277
Note
LinkId=83477.
Important

Configuration.
then click OK.
DSRM.
normally:
Configuration.
278

OK.
shutdown -t 0 -r
shutdown -t 0 -r
Value
Description
shutdown t 0 -r

setting.
See Also

279
Note
Note
then press ENTER.
Where:
<targetDrive>:


280
-quiet
Where:
<MM/DD/YYYY-HH:MM>
<targetDrive>:

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
application directory partition that you want to replicate authoritatively to other domain controllers
that host the application directory partition.
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.
281
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
To mark an application directory partition as authoritative
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.
restore:
restore,
prompt, type List
NC CRs,
Ntdsutil displays a list of directory partition distinguished names and their associated
cross-reference 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,
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
282
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.
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.
283
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
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.
284
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,
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
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>:
Where:
<targetDrive>:

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>
-restoreAllVolumes
285
Where:
<MM/DD/YYYY-HH:MM>
<targetDrive>:
is the drive that contains the backup.

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.
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.
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).
286
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.
Wbadmin.exe

1. After you configure the disks appropriately, install Windows Server 2008.
287
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.
Or
4. Verify AD DS restore

controller.
Note
288
normally.
Note
LinkId=83477.
Important

Configuration.
289
then click OK.

DSRM.
normally:
Configuration.
OK.
shutdown -t 0 -r
shutdown -t 0 -r
Value
Description
shutdown t 0 -r

setting.
See Also
290

Note
normally.
291
LinkId=83477.
Important
Desktop Connection.
then click Connect.
c.
and then click OK.
Configuration.
then click OK.
dropped.
Other User.
292

normally:
Configuration.
session.
Desktop Connection.
then click Connect.
c.
and then click OK.
then press ENTER:
shutdown -t 0 -r
Other User.
293
normally:
ENTER:
shutdown -t 0 r
session.
Value
Description
shutdown t 0 -r

setting.
See Also

Note
294
Note
then press ENTER.
Where:
<targetDrive>:


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

295

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.
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 (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
296
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
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.
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.
297
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
Ntdsutil.exe
Dcdiag.exe
Dcpromo.exe

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.
6. After you install AD DS, see Verifying Active Directory Installation and perform procedures for
verification of the installation.
298

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
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
To clean up server metadata by using Active Directory Users and Computers
Administrative Tools, and then click Active Directory Users and Computers.
2. If you have identified replication partners in preparation for this procedure, and if you are
not connected to a replication partner of the removed domain controller whose metadata
you are cleaning up, right-click Active Directory Users and Computers
<DomainControllerName>, and then click Change Domain Controller. Click the name
of the domain controller from which you want to remove the metadata, and then click OK.
3. Expand the domain of the domain controller that you forcibly removed, and then click
Domain Controllers.
4. In the details pane, right-click the computer object of the domain controller whose
metadata you want to clean up, and then click Delete.
5. In the Active Directory Domain Services dialog box, click Yes to confirm the computer
299
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
appears, provide Enterprise Admins credentials, if required, and then click Continue.
ntdsutil
3. At the ntdsutil: prompt, type the following command, and then press ENTER:
metadata cleanup
4. At the metadata
cleanup:
remove selected server <ServerName>
Or
remove selected server <ServerName1> on <ServerName2>
300
Value
Description
ntdsutil: metadata cleanup
Initiates removal of objects that refer to a

decommissioned domain controller.
remove selected server
Removes objects for a specified, decommissioned

domain controller from a specified server.
<ServerName> or
<ServerName1>
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.
on <ServerName2>
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.
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
301

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.
To delete a server object from a site
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
302
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.
To verify DNS registration and TCP/IP connectivity
appears, provide Domain Admins credentials, and then click OK.
dcdiag /test:dns
Note
For a more detailed response from this command, add
command.
/v
to the end of the
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:
303
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.
To verify the availability of the operations masters
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.
304
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).
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.
305
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
306
performed offline.
19. On the Summary page, review your selections. Click Back to change any selections, if
necessary.
To save the settings that you have selected to an answer file that you can use to
automate subsequent Active Directory operations, click Export settings. Type the name
for your answer file, and then click Save.
When you are sure that your selections are accurate, click Next to install AD DS.
Note
If you are installing an additional domain controller in a child domain and you are
using child domain credentials, the Windows Security dialog box appears
because access is denied in the parent domain to update the DNS delegation in
the parent zone. In this case, click the other user icon and provide administrator
credentials for the parent domain, and then click OK.
20. On the Completing the Active Directory Domain Services Installation Wizard page,
click Finish.
21. You can select Reboot on completion to have the server restart automatically, or you
can restart the server to complete the installation of AD DS when you are prompted to do
so.
See Also
Preparing for Active Directory Installation
Verifying Active Directory Installation

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:
DNS Manager
307
Event Viewer
Dcdiag.exe
Ntdsutil.exe

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.
8. Verify a Domain Computer Account for a New Domain Controller
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:
308
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
309
cost is disabled. In addition, Distributed File System (DFS) cannot compute the cost matrix for its
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
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
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.
310
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.
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
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.
311
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 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

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

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.
313
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
To create a site object and add it to an existing site link
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.
To create a subnet object or objects and associate them with a site
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.
314
4. In Select a site object for this prefix, click the site to be associated with the subnet, and
then click OK.
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
To associate an existing subnet object with a site
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
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.
315
To create a site link object
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.
To remove a site from a site link
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,
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.
316
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
planning your site topology, see Designing the Site Topology for Windows Server 2008 AD DS
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:
317
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.
Task requirements

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.
To create a site link object
2. Expand Sites, and then expand Inter-Site Transports.
3. Right-click IP, and then click New Site Link.
318
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.

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
To determine the ISTG role owner for a site
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.
319
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.

To generate the replication topology on the ISTG
1. Determine the server that holds the ISTG role for the site.
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
To designate a preferred bridgehead server
320
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
5. In Transports available for inter-site data transfer, click IP.
6. Click Add, and then click OK.
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

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
321
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 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.
To configure the site link schedule
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.
322
Note
Intersite connection objects also have a schedule; they inherit their schedule and interval
from the site link object.
To configure the site link interval
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.
To configure the site link cost
Properties.
323
4. In Cost, specify the number for the comparative cost of using the site link, and then click
OK.


ISTG
follows:
Note
324

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.
325
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
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 sitelink cost.
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.
326
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.
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
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
327
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.
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
328
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.
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
Network Connections
DNS snap-in

1. Change the Static IP Address of a Domain Controller
329
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 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.
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

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

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

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, right-click
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.
To update the IP address for a DNS forwarder
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.
332
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.
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.
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.
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.
333
7. Expand the Sites container, and then click the Subnets container.
8. In the Name column in the details pane, find the subnet object that matches the subnet
address for the server or domain controller.
9. In the Site column, note the site to which the IP subnet address is associated.
If the site that appears in the Site column is not the appropriate site, contact a site
administrator and find out whether the IP address is incorrect or whether you should
move the server object to the site that is indicated by the subnet-to-site association.
See Also
Move a Server Object to a New Site
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.
To determine whether a server is a preferred bridgehead server
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
334
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.
To view the list of preferred bridgehead servers
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
335
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.
To configure the server to not be a preferred bridgehead server
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

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.
To move a server object to a new site
2. In the console tree, expand Sites and the site in which the server object resides.
336
3. Expand Servers to display the domain controllers that are currently configured for that
site.
4. Right-click the server object that you want to move, and then click Move.
5. In Site Name, click the destination site, and then click OK.
6. Expand the site object to which you moved the server, and then expand the Servers
container.
7. Verify that an object for the server that you moved exists.
8. Expand the server object, and verify that an NTDS Settings object exists.
Within an hour, the Net Logon service on the domain controller registers the new site information
in Domain Name System (DNS). Wait an hour, and then open Event Viewer and connect to the
domain controller whose server object you moved. Review the System log for NETLOGON errors
regarding registration of service (SRV) resource records in DNS that have occurred within the last
hour. The absence of errors indicates that the Net Logon service has updated DNS with sitespecific service (SRV) resource records. NETLOGON Event ID 5774 indicates that the dynamic
registration of DNS resource records has failed. If this error occurs, contact a supervisor and
pursue DNS troubleshooting.
See Also
Verify That an IP Address Maps to a Subnet and Determine the Site Association
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
337
controller uses cached universal group memberships and does not have to contact a global
catalog server.
Task requirements
Enable Universal Group Membership Caching in a Site
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.
To enable Universal Group Membership Caching in a site
2. In the console tree, expand Sites, and then click the site in which you want to enable
Universal Group Membership Caching.
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.
338
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
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
339
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
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
Repadmin.exe

1. Force Replication Between Domain Controllers
2. Update a Server with Configuration Changes

Controllers
340

for that site.
OK.
See Also
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.
To use the Windows interface to update a server with configuration changes
2. In the console tree, expand Sites, and then expand the site of the domain controller that
you want to receive configuration updates.
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.
341
6. In the Replicate Now message box, click OK.

To use Repadmin to update a server with configuration changes
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.
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.
repadmin /sync <ConfigurationDistinguishedName> <DestinationServerName>
<SourceDomainControllerGUID>
Value
Description
/sync
Synchronizes replication of the specified

directory partition between the specified domain
controllers
<ConfigurationDistinguishedName>
The configuration directory partition

distinguished name:
CN=Configuration,DC=ForestRootDomainName
<DestinationServerName>
The name of the domain controller that is to

receive the configuration updates, for example,
DC3B.
<SourceDomainControllerGUID>
The Directory System Agent (DSA) GUID of the

domain controller that is forcing replication.

controller.
342
Value
Description
repadmin /syncall


partners.
/e
/d

names in messages.
/A

/P

server.
/q

messages.
corrected.
See Also

Controller
343
Note
domain.
344
Value
Description
repadmin /showrepl

<servername>

controller.
/u:

AD DS.
<domainname>

<username>

that domain.
/pw:*

ENTER.
then press ENTER.
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
345
readability.
3. Open Excel.
Or
Custom Filter.
controllers.
346
Removing a Site
If domain controllers are no longer needed in a network location, you can remove them from the
site and then delete the site object. Before you delete the site, you must remove each domain
controller from the site either by removing domain controller completely or by moving it to a new
location:
To remove the domain controller completely, remove Active Directory Domain Services
(AD DS) from the server and then delete the server object from the site in AD DS.
To retain the domain controller in a different location, move the domain controller itself to the
new site and then move the server object to the respective site in AD DS.
Before you remove a server object from a site, check the NTDS Settings object of the server to
see if the server has a manual connection object from any server in another site. If a manual
connection object exists, check the source server in the other site for a corresponding manual
connection object from the server that you are removing. The Knowledge Consistency Checker
(KCC) does not remove manual connection objects automatically. Therefore, if you leave a
manually created connection object on a server and then remove the source server for the
connection, the inability of the destination server to replicate from its source replication partner
will cause replication errors to be generated. If a manual connection object exists in the NTDS
Settings object of a server in another site, and if the server that you are removing is the source
(replicate from) server for the connection, delete that manual connection object on the
destination server to avoid unnecessary replication errors after you have removed the server
object.
Domain controllers can host other applications that depend on site topology and publish objects
as child objects of the respective server object. For example, when Microsoft Operations
Manager (MOM) or Message Queuing is running on a domain controller, these applications
create child objects beneath the server object. In addition, a server running Message Queuing
that is not a domain controller and that is configured to be a routing server running Message
Queuing creates a server object in the sites container. Removing the application from the server
automatically removes the child object below the respective server object. However, the server
object is not removed automatically.
When all applications have been removed from the server (no child objects appear beneath the
server object), you can remove the server object. After the application is removed from the server,
a replication cycle might be required before child objects are no longer visible below the server
object.
After you delete or move the server objects but before you delete the site object, reconcile the
following objects:
IP addresses:
If the addresses are being reassigned to a different site, associate the subnet object or
objects with that site. Any clients that use the addresses for the decommissioned site will
thereafter be assigned automatically to the other site.
If the IP addresses will no longer be used on the network, delete the corresponding subnet
object or objects.
347
Site link objects:
If the site that you are removing is added to a site link that contains only two sites, delete the
site link object.
If the site that you are removing is added to a site link that contains more than two sites, do
not delete this site link object.
Before you remove a site, consider the implications. If the site that you are removing is added to
more than one site link, it might be an interim site between other sites that are added to this site
link. Deleting the site might disconnect the outer sites from each other. In this case, the site links
must be reconciled according to the instructions of the design team.
Task requirements

1. Delete a manual Connection object
3. Delete a Server Object from a Site
4. Delete a Site Link object
5. Associate an Existing Subnet Object with a Site
6. Delete a Site object
7. To avoid replication errors on bridgehead servers in other sites that received replication from
the site that has been removed, generate the intersite topology in those sites by performing
the following two procedures:
Generate the Replication Topology on the ISTG
Delete a Manual Connection Object

If you are removing a server object that has a manual connection object, you must remove the
corresponding connection object on the destination domain controller. The Knowledge
Consistency Checker (KCC) does not remove manual connection objects automatically. If the
source (replicate from) server in the connection is being removed and you no longer need a
manual connection object on the destination server, delete the connection object from the
destination server.
You can use this procedure to delete a manual connection object.
348
To delete a manual connection object

2. In the console tree, expand Sites, and then expand the site of the server whose manual
connection object you want to delete.
3. Expand Servers, and then expand the server object whose manual connection object
you want to delete.
4. Click the NTDS Settings object of the server object, and then, in the details pane, view
the Name column to find a connection object that has a name other than <automatically
generated>.
5. Usually, a manual connection object is named for the source server. To be sure, rightclick the connection object and then, in Replicate from, note the server name in the
Server box. This is the source server from which this connection transfers replication
updates to the destination server whose NTDS Settings object you have selected.
6. If you no longer want the destination server to explicitly use this server as its replication
source, right-click the manual connection object, and then click Delete.
Determine Whether a Server Object Has

Child Objects
After Active Directory Domain Services (AD DS) is properly installed on a domain controller, the
server object for the domain controller has a child NTDS Settings object. Other applications that
are running on domain controllers can also publish child objects.
When you remove AD DS from a server, the NTDS Settings child object is removed automatically
from the server object in the Servers container in Active Directory Sites and Services. Before you
delete a server object from the Servers container for a site, verify that the server object has no
child objects. The following conditions might result in the presence of a child object:
If an NTDS Settings object is present, it is possible that replication of the deletion has not
reached the domain controller whose objects you are viewing. Check the presence of the
object on another domain controller, or force replication from another domain controller in the
domain. (See Force Replication Between Domain Controllers.)
If a child object other than NTDS Settings is present, another application has published the
object and is using the server object. In this case, do not delete the server object.
349
To determine whether a server object has child objects

2. In the console tree, expand the Sites container, and then expand the site of the server
object.
3. Expand the Servers container, and then expand the server object to view any child
objects.

click Delete.
Important
350

See Also
Delete a Site Link object

If you are removing a site and you no longer need a site link, you can use this procedure to delete
a site link object.
To delete a site link object
3. In the details pane, right-click the site link object that you want to delete, and then click
Delete.
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
351
To associate an existing subnet object with a site

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
4. In Site, click the site to associate the subnet, and then click OK.
Delete a Site object

You can use this procedure to delete a site object. Delete a site object only after you have
removed all server objects from the site and you have reassociated the subnets with a different
site. The Servers container is deleted when you delete the site.
To delete a site object
2. In the console tree, click the Sites container.
3. In the details pane, right-click the site that you want to delete, and then click Delete.
5. In the Active Directory message box, read the information, and then click Yes to delete
the site and its servers container object.
See Also
Delete a Site Link object

352


ISTG
follows:
Note

353
Administering the Active Directory Database

This guide provides information about administering the Active Directory database in the
In this guide
Introduction to Administering the Active Directory Database [lhsad]_ADDS_Ops_7
Managing the Active Directory Database
Introduction to Administering the Active

Directory Database [lhsad]_ADDS_Ops_7
Active Directory Domain Services (AD DS) is stored in the Ntds.dit database file. In addition to
this file, the directory service uses log files, which store transactions before they commit them to
the database file. For best performance, store the log files and the database on separate hard
drives.
Before you perform any procedures that affect the directory database, be sure that you have a
current system state or critical-volume backup. For information about backing up AD DS, see
Backing Up Active Directory Domain Services.
Database management conditions

The Active Directory database is a self-maintained system. It requires no daily maintenance,
other than regular backup, during ordinary operation. However, you may have to manage it if the
following conditions occur:
Low disk space: move the files to a different location permanently, or replace the disk on
which the database or log files are stored.
Pending or current hardware failure: upgrade or replace the disk on which the database or log
files are stored.
A need to recover physical disk space: defragment the database after bulk deletion or
removal of the global catalog.
354
Disk space monitoring recommendations

Monitor free disk space on the partition or partitions that store the directory database and logs.
The following are the recommended parameters for free disk space:
Ntds.dit partition: The greater of 20 percent of the Ntds.dit file size or 500 megabytes (MB).
Log file partition: The greater of 20 percent of the combined log files size or 500 MB.
Ntds.dit and logs on the same volume: The greater of 20 percent of the combined Ntds.dit
and log files sizes or 1 gigabyte (GB).
Database defragmentation
During ordinary operation, you will delete objects from AD DS. When you delete an object, free
(unused) disk space is created in the database. On a regular basis, the database consolidates
this free disk space through a process called online defragmentation. This disk space will be
reused when new objects are added (without adding any size to the file itself). This automatic
online defragmentation redistributes and retains free disk space for use by the database, but
does not release the disk space to the file system. Therefore, the database size does not shrink,
even though objects might be deleted.
In cases in which the data decreases significantly, such as when the global catalog is removed
from a domain controller, free disk space is not automatically returned to the file system. Although
this condition does not affect database operation, it does result in large amounts of free disk
space in the database. To decrease the size of the database file by returning free disk space from
the database file to the file system, you can perform an offline defragmentation of the database.
Whereas online defragmentation occurs automatically while AD DS is running, offline
defragmentation requires taking the domain controller offline and using the Ntdsutil.exe
command-line tool to perform the procedure.
Note
NTFS disk compression is not supported for the database and log files.
Restartable AD DS
On domain controllers that are running Windows Server 2008, performing offline defragmentation
and other database management tasks does not require a restart of the domain controller in
Directory Services Restore Mode (DSRM). You can stop the AD DS service while you perform
database management procedures. This feature, called restartable AD DS, eliminates the need to
restart the domain controller when you perform certain database management tasks. Services
that are running on the server that depend on AD DS to function shut down before AD DS shuts
down. The following services stop when you stop AD DS:
DNS Server service
File Replication Service (FRS)
Kerberos Key Distribution Center (KDC)

355
Intersite Messaging
Distributed File System (DFS) Replication
Other services that are running on the server and that do not depend on AD DS to function, such
as Dynamic Host Configuration Protocol (DHCP), remain available to satisfy client requests while
AD DS is stopped. For information about restartable AD DS, see Windows Server 2008
Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649).
See Also

This section includes the following tasks for managing the Active Directory database:
Relocating the Active Directory Database Files
Returning Unused Disk Space from the Active Directory Database to the File System
Relocating the Active Directory Database

Files
Relocating Active Directory database files usually involves moving files to a temporary location
while hardware updates are being performed and then moving the files to a permanent location.
On domain controllers that are running versions of Windows 2000 Server and
Windows Server 2003, moving database files requires restarting the domain controller in
Directory Services Restore Mode (DSRM). Windows Server 2008 introduces restartable Active
Directory Domain Services (AD DS), which you can use to perform database management tasks
without restarting the domain controller in DSRM. Before you move database files, you must stop
AD DS as a service. For information about restartable AD DS, see the Windows Server 2008
The following conditions require moving database files:
Hardware maintenance: If the physical disk on which the database or log files are stored
requires upgrading or maintenance, the database files must be movedeither temporarily or
permanently.
Low disk space: When free disk space is low on the logical drive that stores the database
file (Ntds.dit), the log files, or both, first verify that no other files are causing the problem. If
the database file or log files are the cause of the growth, provide more disk space by taking
one of the following actions:
356
Expand the partition on the disk that currently stores the database file, the log files, or
both. This procedure does not change the path to the files and does not require updating
the registry.
Use Ntdsutil.exe to move the database file, the log files, or both to a larger existing
partition. If you are not using Ntdsutil.exe when you move files to a different partition, you
must update the registry manually.
If the path to the database file or log files will change as a result of moving the files, be sure that
you:
Use Ntdsutil.exe to move the files (rather than copying them) so that the registry is updated
with the new path. Even if you are moving the files only temporarily, use Ntdsutil.exe to move
files locally so that the registry remains current.
Perform a system state or critical-volume backup as soon as the move is complete so that the
restore procedure uses the correct path.
Verify that the correct permissions are applied on the destination folder after the move.
Revise permissions to just the permissions that are required to protect the database files, if
necessary.
The registry entries that Ntdsutil.exe updates when you move the database file are as follows:
In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\
Parameters:
Database backup path
Directory System Agent (DSA) database file
DSA working directory
The registry entry that Ntdsutil.exe updates when you move the log files is as follows:
In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\
Parameters:
Database log files path
Disk space requirements for relocating

Active Directory database files
Temporary location. Free space on the destination drive equivalent to at least the current size of
the database file, the combined log files, or both, depending on which files you are moving.
Permanent location. Free space on the destination NTFS drive equivalent to at least the
following specified size, plus space to accommodate anticipated growth, depending on which file
or files you are moving.
Caution
The drive that is the permanent location of the database file or log files must be formatted
as NTFS.
357
Database file only: The size of the database file, plus 20 percent of the Ntds.dit file or
500 megabytes (MB), whichever is greater.
Log files only: The size of the combined log files, plus 20 percent of the combined logs or
500 MB, whichever is greater.
Database and logs. If the database and log files are stored on the same partition, free space
should be at least 20 percent of the combined Ntds.dit and log files, or 1 gigabyte (GB),
whichever is greater.
Important
The preceding levels are minimum recommended levels. Therefore, adding additional
space according to anticipated growth is recommended.
Task requirements
net use, net stop, net start
dir
xcopy
Ntdsutil.exe
Windows Explorer
Note
If you replace or reconfigure a drive that stores the SYSVOL folder, you must first move
the SYSVOL folder manually. For information about moving SYSVOL manually, see
Relocating SYSVOL Manually.

Note
The domain controller will not be available during the time in which files are being moved
and until the move is verified. Ensure that alternate domain controllers are available
during the file relocation to handle the capacity.
1. Determine the size and location of the Active Directory database by using one of the following
procedures:
Determine the Database Size and Location Online
Determine the Database Size and Location Offline
2. Compare the Size of the Directory Database Files to the Volume Size
3. Perform a System State Backup of a Domain Controller by Using the Command Line
(Wbadmin) (http://go.microsoft.com/fwlink/?LinkId=118357)
System state includes the database file and log files as well as SYSVOL and Net Logon
shared folders, among other things. Always ensure that you have a current system state or
critical-volume backup before you move database files.
358
4. Move or copy the directory database and log files by performing one of the following
procedures:
Move the Directory Database and Log Files to a Local Drive
Copy the Directory Database and Log Files to a Remote Share

The shared folder on a remote drive must have enough free space to hold the database
file (Ntds.dit) and log files. Create separate subdirectories for copying the database file
and the log files.
Determine the Database Size and Location

Online
You can use this procedure to determine the size and location of the Active Directory database
when Active Directory Domain Services (AD DS) is running in normal Windows mode on a
domain controller that is connected to the network (that is, on a domain controller that is online).
When you determine the database size and location online, the size is reported in bytes. If you
must manage the database file, the log files, or both, first determine the location and size of the
files. By default, the database file and associated log files are stored in the %systemroot%\NTDS
directory.
Important
Be sure to use the same method to check file sizes when you compare them. The size is
reported differently, depending on whether the domain controller is online or offline. For
information about determining database size offline, see Determine the Database Size
and Location Offline.
You can also use the Search command on the Start menu to locate the database file (Ntds.dit) or
the edb*.log file for the location of the database and log files, respectively.
If you have set garbage collection logging to report free disk space, Event ID 1646 in the
Directory Service log also reports the size of the database file: Total allocated hard disk space
(megabytes):
As an alternative, you can determine the size of the database file by listing the contents of the
directory that contains the files.
To determine the database size and location online
1. On the domain controller on which you want to manage database files, open a command
prompt as an administrator: On the Start menu, right-click Command Prompt, and then
click Run as administrator. If the User Account Control dialog box appears, provide
359
Domain Admins credentials, if required, and then click Continue.

2. Change directories to the directory that contains the files that you want to manage.
3. At the command prompt, type dir, and then press ENTER to examine the database size.
In the following example command output, the Ntds.dit file and the log files are stored in
the same directory. In the example, the files take up 58,761,256 bytes of disk space. This
output is representative of a directory database to which few objects have been added.
C:\Windows\NTDS>dir
Volume in drive C has no label.
Volume Serial Number is 003D-0E9E
Directory of C:\Windows\NTDS
01/29/2008 11:04 AM
<DIR>
01/29/2008 11:04 AM
<DIR>
..
01/29/2008 10:29 AM
8,192 edb.chk
01/29/2008 10:29 AM
10,485,760 edb.log
01/29/2008 10:29 AM
10,485,760 edb00001.log
01/29/2008 10:29 AM
10,485,760 edbres00001.jrs
01/29/2008 10:29 AM
10,485,760 edbres00002.jrs
01/29/2008 10:29 AM
14,696,488 ntds.dit
01/28/2008 02:54 PM
2,113,536 temp.edb
7 File(s)
2 Dir(s)
58,761,256 bytes
126,027,243,520 bytes free
See Also
Determine the Database Size and Location Offline
Determine the Database Size and Location

Offline
You can use this procedure to determine the size and location of the Active Directory database
when Active Directory Domain Services (AD DS) is offline. When you determine the database
size and location offline, the size is reported in megabytes (MB). On domain controllers that are
running Windows Server 2008, you can take AD DS offline by stopping the service. Otherwise,
the domain controller must be started in Directory Services Restore Mode (DSRM). For
information about stopping the AD DS service on domain controllers that are running
Windows Server 2008, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide
360
Important
Be sure to use the same method to check file sizes when you compare them. The size is
reported differently, depending on whether the domain controller is online or offline. For
information about determining database size online, see Determine the Database Size
and Location Online.
If you have set garbage collection logging to report free disk space, Event ID 1646 in the
Directory Service log also reports the size of the database file: Total allocated hard disk space
(megabytes):
As an alternative, you can determine the size of the database file by listing the contents of the
directory that contains the files.
Membership in Builtin Administrators, or equivalent, is the minimum required to complete this
To determine the database size and location offline
net stop ntds
Type Y to agree to stop additional services, and then press ENTER.

4. At the ntdsutil prompt, type activate
instance ntds,
5. At the ntdsutil prompt, type files, and then press ENTER.

6. At the file maintenance prompt, type info, and then press ENTER. Make a note of the
file sizes that appear.
7. At the file maintenance prompt, type quit, and then press ENTER. Type quit, and then
press ENTER again to quit Ntdsutil.exe.
net start ntds
See Also
Determine the Database Size and Location Online
361
Compare the Size of the Directory Database

Files to the Volume Size
Before you move any Active Directory database files in response to low disk space, verify that no
other files on the volume are responsible for the condition of low disk space.
You might have to relocate the database file, the log files, or both, if disk space on the volume on
which they are stored becomes low. Before you move the database file or log files, examine the
size of the database folder, logs folder, or bothif they are stored in the same location
compared to the size of the volume to verify that these files are the cause of low disk space.
Include the size of the SYSVOL folder if it is on the same partition. You can use this procedure to
compare the size of the directory database files to the size of the volume.
If Active Directory Domain Services (AD DS) is started when you are comparing the size of the
directory database files and volume, membership in Domain Admins is the minimum required to
complete this procedure. If AD DS is stopped, membership in Builtin Administrators is the
minimum required to complete this procedure. If the domain controller is restarted in Directory
Services Restore Mode (DSRM), the DSRM administrator password is the minimum required to
complete this procedure. Review details about using the appropriate accounts and group
memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To compare the size of the directory database files to the volume size
1. On the Start menu, click Computer.
2. In the Folders list, click Computer.
3. In the details pane, locate the volume that has low disk space. Make a note of the value
in the Total Size column for that volume.
4. Navigate to the folder that stores the database file, the log files, or both.
5. Right-click the folder, and then click Properties. Make a note of the value in Size on
disk.
6. If the volume includes SYSVOL, navigate to that folder and repeat step 5.
7. Compare the values of Total Size (volume) and Size on disk (database files plus
SYSVOL if SYSVOL is on the same volume). If the combined size of the relevant
database files and SYSVOL files (if appropriate) is significantly smaller than the volume
size, check the contents of the volume for other files.
8. If other files are present, move those files and then reassess the disk space on the
volume.
362

(Wbadmin)
LinkID=117940).
Move the Directory Database and Log Files

to a Local Drive
You can use this procedure to move Active Directory database and log files to a local drive.
363
When you move the files to a folder on the local domain controller, you can move them
permanently or temporarily. Move the files to a temporary destination if you need to reformat the
original location, or move the files to a permanent location if you have additional disk space. If
you reformat the original drive, use the same procedure to move the files back after the reformat
is complete. Ntdsutil.exe updates the registry when you move files locally. Even if you are moving
the files only temporarily, use Ntdsutil.exe so that the registry is always current.
If you do not have space on the local domain controller to move the files temporarily, you can
copy files to a remote share. For information about copying files to a remote share, see Copy the
Directory Database and Log Files to a Remote Share.
On a domain controller that is running Windows Server 2008, you do not have to restart the
domain controller in Directory Services Restore Mode (DSRM) to move database files. You can
stop the Active Directory Domain Services (AD DS) service and then restart the service after you
move the files to their permanent location. For information about restartable AD DS, see the
Windows Server 2008 Restartable AD DS Step-by-Step Guide on the Microsoft Web site at
To move the directory database and log files to a local drive
net stop ntds

3. At the command prompt, change directories to the current location of the directory
database file (Ntds.dit) or the log files, whichever you are moving.
4. Run the dir command, and make a note of the current size and location of the Ntds.dit
file.
instance ntds,

8. To move the database file, at the
commands:
file maintenance:
prompt, use the following
To move the Ntds.dit file, type the following command, and then press ENTER:
move db to<drive>:\<directory>
To move the log files, type the following command, and then press ENTER:
move logs to<drive>:\<directory>
where <drive>:\<directory> specifies the path to the new location. If the directory does
364
not exist, Ntdsutil.exe creates it.

Note
If the directory path contains any spaces, the entire path must be surrounded by
quotation marks, for example, move db to"g:\new folder".
9. After the move completes, at the file maintenance: prompt, type quit, and then press
ENTER. Type quit again, and then press ENTER to quit Ntdsutil.exe.
10. Change to the destination directory, and then run the dir command to confirm the
presence of the files. If you have moved the database file, check the size of the Ntds.dit
file against the file size that you noted in step 4 to be sure that you are focused on the
correct file.
11. If you are moving the database file or log files permanently, go to step 12.
If you are moving the database file or log files temporarily, you can now perform any
required updates to the original drive. After you update the drive, repeat steps 3 through 9
to move the files back to the original location.
If the path to the database file or log files has not changed, go to step 13.
12. If the path to the database file or log files has changed from the original location, check
permissions on the database folder or logs folder, as follows:
a. In Windows Explorer, right-click the folder to which you have moved the database file
or log files, and then click Properties.
b. Click the Security tab, and then click Advanced. Verify that the permissions are as
follows:
Administrators group has Allow Full Control.
SYSTEM has Allow Full Control.
The Include inheritable permissions from this objects parent check box is
cleared.
No Deny permissions are selected.
c.
If the permissions in step 12b are in effect, go to step 13. If permissions other than
the permissions described in step 12b are in effect, perform steps 12d through 12k.
d. If Include inheritable permissions from this objects parent is selected, click Edit,
click to clear the setting, and then click OK.
When you are prompted, click Copy to copy previously inherited permissions to this
object.
e. If Administrators or SYSTEM, or both, are not in the Name list, click OK, click Edit,
and then click Add.
f.
In From this location, be sure that the name of the domain is selected.
g. In Enter the object names to select, type System, if necessary, and then click OK.
Repeat to add Administrators, if necessary, and then click OK.
h. On the Security tab, click System, and then, in the Allow column, click Full Control.
Repeat for Administrators.
365
i.
In the Group or user names box, click any name that is not SYSTEM or
Administrators, and then click Remove. Repeat until the only remaining accounts
are Administrators and SYSTEM, and then click OK.
Note
Some accounts might appear in the form of security identifiers (SIDs).
Remove any such accounts.
j.
Click OK to close Properties.
instance ntds,
16. At the file
maintenance:
prompt, type integrity, and then press ENTER.
If the integrity check fails, see If the Database Integrity Check Fails, Perform Semantic
Database Analysis with Fixup.
17. If the integrity check succeeds, type quit, and then press ENTER to quit the file
maintenance prompt. Type quit again, and then press ENTER to quit Ntdsutil.exe.
net start ntds
19. Open Event Viewer, and check the Directory Service log for errors.
20. If the following events are logged in the Directory Service log in Event Viewer when you
restart AD DS, stop AD DS, and then resolve the event issues as follows:
Event ID 1046. The Active Directory database engine caused an exception with the
following parameters. In this case, AD DS cannot recover from this error and you
must restore AD DS from backup.
Event ID 1168. Internal error: An Active Directory error has occurred. In this case,
information is missing from the registry and you must restore AD DS from backup.
See Also
If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup
Copy the Directory Database and Log Files to a Remote Share
Copy the Directory Database and Log Files

to a Remote Share
You can use this procedure to copy the Active Directory directory database and log files to a
remote shared folder.
366
If you need to move the database file or the log files while you reconfigure the drive on which they
are currently stored and you do not have enough space to move the files locally, you can use the
xcopy command to copy the files to a remote shared folder temporarily and then use the same
procedure to copy them back to the original drive. Use this method only if the path to the files
does not change.
Important
When you relocate any database files (the database file or the log files) off the local
computer, always copy both the database file and the log files so that all the files that are
necessary to restore the directory service are maintained.
If you have enough space locally on the domain controller and you do not want to copy database
files to a remote share, you can use Ntdsutil to move the files to a local folder. For information
about moving the database files, see Move the Directory Database and Log Files to a Local
Drive.
On a domain controller that is running Windows Server 2008, you do not have to restart the
domain controller in Directory Services Restore Mode (DSRM) to copy database files. You can
stop the Active Directory Domain Services (AD DS) service and then restart the service after you
copy the files to their permanent location. For information about restartable AD DS, see the
Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?
LinkId=88649).
To copy the directory database and log files to a remote share and back to the local
computer
1. Before you stop AD DS, prepare a shared directory on a remote server in the domain.
Create separate subdirectories for the database files and log files. Allow access only to
the Builtin Administrators group.
net stop ntds

4. At the command prompt, change directories to the current location of the database file
(Ntds.dit) or the log files. If the database file and log files are in different locations,
perform step 4 for each directory.
5. Run the dir command, and make a note of the current size and location of the Ntds.dit
file and the log files.
6. Establish a network connection to the shared folder. After you type the following
command and press ENTER, you are prompted for the password for the specified
367
account. Type the password, and then press ENTER.

net use <NetworkDrive>: \\<ServerName>\<SharedFolderName>
/user:<domainName>\<userName> *
Value
Description
net use <NetworkDrive>:
Specifies the drive letter to use for

connecting to the shared folder.
\\<ServerName>\<SharedFolderName>
The universal naming convention (UNC)

name of the shared folder location,
specifying the server that stores the shared
folder and the name of the shared folder,
separated by a backslash.
/user:<domainName>\<userName>

AD DS.
Provides a Type the password for

\\<ServerName>\<SharedFolderName>:
prompt when you press ENTER.
For example, if you shared the \TempCopy directory on the server named SERVER1, the
following command maps network drive G: to the shared location and provides the
domain and user name for user tonip5:
net use G: \\server1\tempcopy /user:contoso\tonip5 *
7. Use the xcopy command to copy the database files to the location that you established in
step 6. Type the following command, and then press ENTER:
xcopy \<PathToDatabaseFiles> <NetworkDrive>:\<DatabaseSubdirectory>
This command copies the contents of the local folder for the database to the named
subfolder in the remote shared folder. For example, the following command copies the
database files from their location on the domain controller to the DB subdirectory on the
mapped drive G:
xcopy \windows\ntds G:\DB
8. Repeat step 7 to copy the log files. For example, the following command copies the log
files to the Logs subdirectory on the mapped drive G:
xcopy \windows\ntds\*.log G:\Logs
9. Change drives to the remote directory and run the dir command in each subdirectory to
compare the file sizes to the file sizes that are listed in step 5. Use this step to ensure
that you copy the correct set of files back to the local computer.
10. At this point, you can safely destroy data on the original local drive.
368
11. After the destination drive is prepared, re-establish a connection to the network drive as
described in step 6, if necessary.
12. Use the method in step 7 to copy the database and log files from the remote shared
folder back to the original location on the domain controller.
instance ntds,
16. At the file
maintenance:
If the integrity check fails, see If the Database Integrity Check Fails, Perform Semantic
Database Analysis with Fixup.
17. If the integrity check succeeds, type quit, and then press ENTER to quit the file
maintenance: prompt. Type quit again, and then press ENTER to quit Ntdsutil.exe.
net start ntds
19. Open Event Viewer, and check the Directory Service log for errors.
20. If the following events are logged in the Directory Service log in Event Viewer when
AD DS restarts, resolve the events as follows:
following parameters. In this case, AD DS cannot recover from this error and you
must restore AD DS from backup.
information is missing from the registry and you must restore AD DS from backup.
See Also
Move the Directory Database and Log Files to a Local Drive
Returning Unused Disk Space from the

Active Directory Database to the File
System
During ordinary operation, the free disk space in the Active Directory database file becomes
fragmented. Each time garbage collection runs (every 12 hours, by default), free disk space is
automatically defragmented online to optimize its use within the database file. The unused disk
space is maintained for the database; it is not returned to the file system.
369
Only offline defragmentation can return unused disk space from the directory database to the file
system. When database contents have decreased considerably through a bulk deletion (for
example, when you remove the global catalog from a domain controller), or if the size of the
database backup is significantly increased as a result of the amount of free disk space, use offline
defragmentation to reduce the size of the Ntds.dit file.
You can determine how much free disk space is recoverable from the Ntds.dit file by setting the
garbage collection logging level in the registry. Changing the garbage collection logging level from
the default value of 0 to a value of 1 results in event ID 1646 being logged in the directory service
log. This event describes the total amount of disk space that the database file uses as well as the
amount of free disk space that is recoverable from the Ntds.dit file through offline
defragmentation.
At garbage collection logging level 0, only critical events and error events are logged in the
Directory Service log. These events include Event IDs 700 and 701, which report when online
defragmentation begins and ends, respectively. At level 1, higher-level events are logged as well.
At level 1, Event ID 1646 is also reported, which indicates the amount of free space that is
available in the database relative to the amount of allocated space.
Caution
Setting the value of entries in the Diagnostics subkey to greater than 3 can degrade
server performance and is not recommended.
On domain controllers that are running Windows Server 2008, offline defragmentation does not
require restarting the domain controller in Directory Services Restore Mode (DSRM), as is
required on domain controllers that are running versions of Windows Server 2000 and
Windows Server 2003. You can use a new feature in Windows Server 2008, restartable Active
Directory Domain Services (AD DS), to stop the AD DS service. When the service is stopped,
services that depend on AD DS shut down automatically. However, any other services that are
running on the domain controller, such as Dynamic Host Configuration Protocol (DHCP), continue
to run and respond to clients. For more information about restartable AD DS, see the
Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?
LinkId=88649).
After offline defragmentation completes, perform a database integrity check. The integrity
command in Ntdsutil.exe detects binary-level database corruption by reading every byte in the
database file. This process ensures that the correct headers exist in the database itself and that
all of the tables are functioning and consistent. Therefore, depending on the size of your Ntds.dit
file and the domain controller hardware, the process might take considerable time. In testing
environments, the speed of 2 gigabytes (GB) per hour is considered to be typical. When you run
the command, an online graph displays the percentage completed.
If the database integrity check fails, you must perform semantic database analysis.
Task requirements
Regedit.exe

370
Ntdsutil.exe

1. Change the Garbage Collection Logging Level to 1
3. Compact the Directory DatabaseFfile (Offline Defragmentation)
As part of the offline defragmentation procedure, check directory database integrity.
4. If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup
Change the Garbage Collection Logging

Level to 1
Garbage collection in Active Directory Domain Services (AD DS) is the process of removing
deleted objects (tombstones) from the directory database. This process results in free disk space
in the directory database. By default, this free space is not reported in Event Viewer. To see the
amount of free disk space that can be made available to the file system by offline
defragmentation, you can change the garbage collection logging level so that the disk space is
reported in the Directory Service event log. After you change the logging level, check the
Directory Service event log for Event ID 1646, which reports the amount of disk space that you
can recover by performing offline defragmentation.
The garbage collection logging level is an NTDS diagnostics setting in the registry. You can use
this procedure to change the garbage collection logging level to 1 so that you can view
Event ID 1646 in Event Viewer.
Caution
The Registry Editor bypasses standard safeguards, allowing settings that can damage
up system state first. For information about backing up system state, see Introduction to
Administering Active Directory Backup and Recovery
[lhsad_ADDS_Ops_5]_ADDS_Ops_5.
To change the garbage collection logging level
2. In Registry Editor, navigate to the Garbage Collection entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
3. Double-click Garbage Collection. In the Value data box, type 1, and then click OK.
371
See Also
Compact the Directory DatabaseFfile (Offline Defragmentation)

(Wbadmin)
LinkID=117940).
372
Compact the Directory DatabaseFfile (Offline

Defragmentation)
You can use this procedure to compact the Active Directory database offline. Offline
defragmentation returns free disk space in the Active Directory database to the file system. As
part of the offline defragmentation procedure, check directory database integrity.
Performing offline defragmentation creates a new, compacted version of the database file in a
different location. This location can be either on the same computer or a network-mapped drive.
However, to avoid potential problems related to network issues, it is best to perform this
procedure locally, if space allows. You can use locally attached external mass storage devices,
such as Universal Serial Bus (USB), IEEE 1394, and Serial Advanced Technology Attachment
(SATA), to provide additional disk space for defragmentation of the database.
After you compact the file to the temporary location, copy the compacted Ntds.dit file back to the
original location. If space allows, maintain a copy of the original database file that you have either
renamed in its current location or copied to an archival location.
Note
To perform this procedure, Active Directory Domain Services (AD DS) must be offline. On
domain controllers that are running Windows Server 2008, you can take AD DS offline by
stopping the service. Otherwise, the domain controller must be started in Directory
Services Restore Mode (DSRM). For information about stopping the AD DS service on
domain controllers that are running Windows Server 2008, see the Windows Server 2008
For information about performing this procedure in DSRM, see Compact the directory
database file (offline defragmentation) (http://go.microsoft.com/fwlink/?LinkId=55393).
procedure. If you are compacting to the database to a remote location, you must have Read and
Write permissions on the destination drive and the shared folder. Review details about using the
Disk space
Current database drive. Free space (on the drive that contains the Active Directory
database file) equivalent of at least 15 percent of the current size of the database (Ntds.dit)
for temporary storage during the index rebuild process.
Destination database drive. Free space equivalent to at least the current size of the
database for storage of the compacted database file.
Note
These disk space requirements mean that if you compress the Active Directory database
on a single drive, you should have free space equivalent to at least 115 percent of the
space that the current Active Directory database uses on that drive.
373
To perform offline defragmentation of the directory database

1. Compact the database file to a local directory or remote shared folder, as follows:
Local directory: Go to step 2.
Remote directory: If you are compacting the database file to a shared folder on a
remote computer, before you stop AD DS, prepare a shared directory on a remote
server in the domain. For example, create the share \\ServerName\NTDS. Allow
access to only the Builtin Administrators group. On the domain controller, map a
network drive to this shared folder.
Important
You should make a copy of the existing Ntds.dit file if at all possible, even if you
have to store that copy on a network drive. If the compaction of the database
does not work properly, you can then easily restore the database by copying
back the copy of the Ntds.dit file that you made. Do not delete this copy of the
Ntds.dit file until you have verified that the domain controller starts properly.

net stop ntds

instance ntds,

7. If you are compacting the database to a local drive, at the file maintenance: prompt,
type compact to <drive>:\ <LocalDirectoryPath> (where <drive>:\
<LocalDirectoryPath> is the path to a location on the local computer), and then press
ENTER.
If you mapped a drive to a shared folder on a remote computer, type the drive letter only,
for example, compact to K:\.
Note
When you compact the database to a local drive, you must provide a path. If the
path contains any spaces, enclose the entire path in quotation marks (for
example, compact to "c:\new folder"). If the directory does not exist,
Ntdsutil.exe creates the directory and then creates the file named Ntds.dit in that
location.
8. If defragmentation completes successfully, type quit, and then press ENTER to quit the
file maintenance: prompt. Type quit again, and then press ENTER to quit Ntdsutil.exe.
Go to step 9.
If defragmentation completes with errors, go to step 12.
374
Caution
Do not overwrite the original Ntds.dit file or delete any log files.
9. If defragmentation succeeds with no errors, follow the Ntdsutil.exe onscreen instructions
to:
a. To delete all the log files in the log directory, type the following command, and then
press ENTER:
del <drive>:\<pathToLogFiles>\*.log
Ntdsutil provides the correct path to the log files in the onscreen instructions.
Note
You do not have to delete the Edb.chk file.
b. You should make a copy of the existing Ntds.dit file if at all possible, even if you have
to store that copy on a secured network drive. If the compaction of the database does
not work properly, you can then easily restore the database by copying it back to the
original location. Do not delete the copy of the Ntds.dit file until you have at least
verified that the domain controller starts properly. If space allows, you can rename
the original Ntds.dit file to preserve it. Avoid overwriting the original Ntds.dit file.
c.
Manually copy the compacted database file to the original location, as follows:
copy <temporaryDrive>:\ntds.dit
<originalDrive>:\<pathToOriginalDatabaseFile> \ntds.dit
Ntdsutil provides the correct paths to the temporary and original locations of the
Ntds.dit file.
11. At the ntdsutil: prompt, type files, and then press ENTER.
12. At the file
maintenance:
If the integrity check fails, the likely cause is that an error occurred during the copy
operation in step 9.c. Repeat steps 9.c through step 12. If the integrity check fails again:
Contact Microsoft Customer Service and Support.

Or
Copy the original version of the Ntds.dit file that you preserved in step 9.b. to the
original database location, and repeat the offline defragmentation procedure.
13. If the integrity check succeeds, proceed as follows:
If the initial compact

through 12.
to
If the initial compact
to
command failed, go back to step 7 and perform steps 7
command succeeded, type quit and press ENTER to quit the

file maintenance: prompt, and then type quit and press ENTER again to quit
Ntdsutil.exe.
14. Restart AD DS. At the command prompt, type the following command, and then press
ENTER:
375
net start ntds
If errors appear when you restart AD DS:

1. Stop AD DS. At the command prompt, type the following command, and then press ENTER:
net stop ntds

2. Check the errors in Event Viewer.
If the following events are logged in the Directory Service log in Event Viewer when you
restart AD DS, respond to the events as follows:
following parameters. In this case, AD DS cannot recover from this error and you must
restore from backup media.
information is missing from the registry and you must restore from backup media.
3. Check database integrity, and then proceed as follows:

If the integrity check fails, try repeating step 9.c through step 12 above, and then repeat the
integrity check. If the integrity check fails again:
Contact Microsoft Customer Service and Support.

Or
Copy the original version of the Ntds.dit file that you preserved in step 9.b. to the original
database location and repeat the offline defragmentation procedure.
If the integrity check succeeds, follow the steps in the procedure If the Database Integrity
Check Fails, Perform Semantic Database Analysis with Fixup.
4. If semantic database analysis with fixup succeeds, quit Ntdsutil.exe, and then restart AD DS.
At the command prompt, type the following command, and then press ENTER:
net start ntds
If semantic database analysis with fixup fails, contact Microsoft Customer Service and Support.
See Also
If the Database Integrity Check Fails, Perform

Semantic Database Analysis with Fixup
When you move or compact the Active Directory database, if the integrity check fails, you must
run a subsequent database test called semantic database analysis. When you run semantic
database analysis with the Go Fixup command instead of the Go command, errors are written
376
into Dsdit.dmp.xx log files. A progress indicator reports the status of the check. You can use this
procedure to perform semantic database analysis with fixup.
Note
To perform this procedure, Active Directory Domain Services (AD DS) must be offline. On
domain controllers that are running Windows Server 2008, you can take AD DS offline by
stopping the service. Otherwise, the domain controller must be started in Directory
Services Restore Mode (DSRM). For information about stopping the AD DS service on
domain controllers that are running Windows Server 2008, see the Windows Server 2008
For information about performing this procedure in DSRM, see If database integrity check
fails, perform semantic database analysis with fixup on the Microsoft Web site
To perform semantic database analysis with fixup
net stop ntds

4. At the ntdsutil: prompt, type activate
instance ntds,
5. At the ntdsutil: prompt, type semantic
database analysis,
6. At the semantic
checker:
prompt, type verbose
7. At the semantic
checker:
prompt, type go
on,
fixup,

If errors are reported during the semantic database analysis Go Fixup phase, perform
directory database recovery: Go to the file maintenance: prompt, type recover, and
then press ENTER.
If semantic database analysis with fixup succeeds, at the semantic

type quit, and then type quit again to close Ntdsutil.exe.
checker
prompt,
net start ntds
377
Administering Domain Controllers

This guide provides information about administering Active Directory domain controllers in the
In this guide
Introduction to Administering Domain Controllers
Managing Domain Controllers
Step-by-Step Guide for Windows Server 2008 Active Directory Domain Services Installation
and Removal (http://go.microsoft.com/fwlink/?LinkId=86727)
Introduction to Administering Domain

Controllers
Although installed domain controllers require little management, your overall operations
environment might require change-related tasks, such as adding or removing domain controllers,
including managing the preparation and shipment of domain controllers to remote sites. During
your day-to-day operations, you might need to do some or all of the following:
Install tools that you can use to administer Active Directory Domain Services (AD DS)
remotely
Install and remove AD DS to create or decommission domain controllers
Rename domain controllers
Add domain controllers to remote (branch) sites
Installing Remote Server Administration Tools

To manage domain controllers, you can configure a member server that is running
Windows Server 2008 or a workstation that is running Windows Vista with Service Pack 1 (SP1)
with the same administration tools for managing AD DS that are available on a domain controller.
Administering domain controllers remotely from a member server or a workstation is more secure
and more efficient than logging on to a domain controller locally. You can use Server Manager to
install the Remote Server Administration Tools feature to include Active Directory Domain
Services Tools.
Installing and removing AD DS

To create a new domain controller, you install AD DS on a computer that is running Windows
Server 2008. Installing domain controllers to create a forest and new domains is a deployment
378
task that you perform when you initially deploy your forest, and it is beyond the scope of this
guide. However, as your forest grows, you might need to add more domain controllers to existing
domains.
Adding domain controllers

You might want to add a new domain controller for the following reasons:
Additional applications that use AD DS (Active Directoryintegrated applications) might

require increased capacity.
Additional domain controllers might be needed to provide upgrades and fault tolerance and to
reduce failures.
You might add a new site where users require a domain controller for logging on to the
domain.
Many improvements to the installation process are available in Windows Server 2008. For
information about new Windows Server 2008 features and options, see What's New in AD DS
Installation and Removal (http://go.microsoft.com/fwlink/?LinkId=103330). For information about
the criteria and best practices for deploying domain controllers, see Planning Domain Controller
Placement (http://go.microsoft.com/fwlink/?LinkId=120383).
Removing domain controllers

When you no longer need a server to be a domain controller, you remove AD DS from the server.
The process of removing AD DS is similar to the process for installing AD DS. You run many of
the same tests before you remove AD DS that you run before you install AD DS. These tests
ensure that the removal process occurs without any problems. If a domain controller has a
hardware failure, AD DS cannot be started, and you plan to never return that domain controller to
service, you must use a procedure that forces the removal of AD DS and then take additional
steps to remove the server object and its metadata from the directory.
Renaming domain controllers

You often have to rename a domain controller for organizational or administrative reasons or
when the computer hardware must be replaced. Renaming a domain controller requires that
Domain Name System (DNS) resource records be updated with the new IP-to-host name
mappings and that service principal names (SPNs) replicate to all domain controllers in the
domain.
Adding domain controllers to branch sites

If enough directory users are employed in a branch office, especially in a site that has slow
connectivity to the hub site, you might have to add a domain controller to the site to provide
directory access for logons and searches.
In Windows Server 2008, you have the option to deploy read-only domain controllers (RODCs).
An RODC is an additional domain controller that hosts read-only directory partitions of the
379
Active Directory database. An RODC is primarily designed to be deployed in a branch office

environment. Branch offices typically have relatively few users, poor physical security, relatively
poor network bandwidth to a hub site, and little local information technology (IT) expertise.
RODCs receive replication updates from the hub site, but they do not accept manual updates to
AD DS and they do not replicate directory updates to other domain controllers. Therefore,
although security precautions should be maintained, the stringent security measures that apply to
protecting a writable domain controller are lessened. In addition, elevated administrative
credentials are not required to install and manage the RODC. The information in this guide is
specific to managing writable domain controllers. For information about managing RODCs, see
Planning and Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=120840).
When you are creating a new branch site, a local domain controller is not available to be the
source for Active Directory replication. If the wide area network (WAN) connection with the closest
hub site is slow or unreliable, replicating AD DS can be time consuming and might fail if the
connection is lost. When you deploy the first domain controller in a branch site, if you want to
avoid replicating AD DS, you have the following options:
Install the domain controller in the hub site, and then ship the installed domain controller to
the site.
Ship the server computer to the branch site, and then install AD DS in the branch site.
When you install the domain controller in the branch site, the server can receive AD DS in
one of two ways:
By Active Directory replication over a WAN link
Directly from locally available installation media
Installing from media

Installation from media (IFM) eliminates the use of replication to create the Active Directory
domain, configuration, and schema directory partition replicas on the new domain controller.
Assuming that the remote site is connected to a hub site by a WAN link and that the remote site
does not contain a domain controller for the domain, you might want to avoid the additional time
and the performance impact of replicating the full contents of AD DS over the WAN link when you
add the new domain controller to the remote site. In this case, you can use IFM to install AD DS.
On a domain controller that is running Windows Server 2003, installation media must be created
by backing up system state and restoring the backup file to a location either on the server you are
installing or on removable media. The IFM process is improved in Windows Server 2008,
eliminating the necessity of using the backup and restore process to create the installation media.
On a domain controller that is running Windows Server 2008, you can use the Ntdsutil commandline tool to create the installation media. Then, you can use the Active Directory Domain Services
Installation Wizard (Dcpromo.exe) to install AD DS from the installation media.
If you want to use Ntdsutil to create the installation media to install a domain controller, both the
source of the media and the target server that is to be promoted to a domain controller must be
running Windows Server 2008. In addition, the operating system of the source of the backup and
the target server must be the same. For example, you cannot install AD DS on a server that is
380
running Windows Server 2003 using installation media that is created on a domain controller that
is running Windows Server 2008. An improvement in the requirements for Windows Server 2008
domain controllers over the requirements for Windows Server 2003 domain controllers is that the
hardware platform (32-bit or 64-bit) of the two computers does not have to match.
Although information in this guide is specific to installing writable domain controllers in branch
office sites, in Windows Server 2008 forests, RODCs are the recommended domain controller
installation for branch office sites. For information about using IFM to install RODCs, see
Planning and Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=120840).
Shipping installed domain controllers to branch sites

Shipping an existing domain controller requires removing it from the replication topology for what
may be an extended period. Preparation is required to ensure a smooth transition when the
domain controller restarts in the branch site. For example, you must be sure that the domain
controller does not hold any operations master (also known as flexible single master operations
or FSMO) roles and that replication is updated immediately before you disconnect the domain
controller.
Managing Domain Controllers

The tasks that are described in this objective apply to the installation and management of
Active Directory Domain Services (AD DS) on writable domain controllers. For information about
installing and managing read-only domain controllers (RODCs), see the Step-by-Step Guide for
Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728) and Planning and
Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).
The tasks that are described in this objective will help you do the following:
Install Remote Server Administration Tools (RSAT) on a member server that is running
Windows Server 2008 or on a client computer that is running Windows Vista with Service
Pack 1 (SP1). RSAT include a selection for Active Directory Domain Services Tools. You can
install these tools on a non-domain-controller computer in the domain and then use this
computer to manage domain controllers remotely.
Manage antivirus software. Antivirus software provides important safeguards. However,

installation on a domain controller requires care to ensure that domain controller performance
is not affected.
Prepare for Active Directory installation. Proper preparation decreases the chances of
problems occurring during and after the installation.
Install an additional domain controller in an existing domain. This task involves preparation
steps of gathering information and configuring the TCP/IP and Domain Name System (DNS)
client settings. You can use the following methods to install Active Directory Domain Services
(AD DS) on a server to create an additional domain controller in an existing domain:
381
Run the Active Directory Domain Services Installation Wizard, and use Active Directory
replication to create the Active Directory replica and either the File Replication Service
(FRS) or Distributed File System (DFS) Replication to create the SYSVOL replicas.
Run the Active Directory Domain Services Installation Wizard, and use installation from
media (IFM) to create the Active Directory replica.
Note
By default, SYSVOL is created on the new domain controller by replication from a
source domain controller. It does not come from the installation media. Obtaining
SYSVOL from installation media requires additional procedures. For information
about the process for configuring the server to obtain SYSVOL from installation
media, see article 311078 in the Microsoft Knowledge Base
Run the Active Directory Domain Services Installation Wizard, and use an answer file to
provide the information that the Active Directory Domain Services Installation Wizard
requires. You can create an answer file by using the Export feature in the Active Directory
Domain Services Installation Wizard during domain controller installation.
Verify installation. Perform tests to verify that AD DS is properly installed and the domain
controller is functioning.
Add domain controllers to remote sites. When you prepare and ship an additional domain
controller to a remote site, you can either install the domain controller before shipping or
install the domain controller in the remote site. This process is different if you are installing an
RODC. For information about installing RODCs in remote sites, see the Step-by-Step Guide
for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728).
When you install a domain controller in a hub site or staging site before shipment, you
must disconnect the domain controller for a period, which requires careful preparation.
When you reconnect the domain controller, Active Directory replication brings the domain
controller up to date.
When you install the domain controller in the remote site, you can use installation media
that is prepared from an existing domain controller to avoid having to replicate AD DS
over a wide area network (WAN) link.
Rename a domain controller. You may have to rename a domain controller for organizational
or administrative reasons.
Remove AD DS from (decommission) a properly functioning domain controller. This task

includes first transferring operations master roles (also known as flexible single-master
operation (FSMO) roles) and the global catalog, if necessary.
Force the removal of a nonfunctioning domain controller from a domain. If a domain controller
is not functioning properly on the network, the Active Directory Domain Services Installation
Wizard cannot contact other domain controllers and DNS servers that are required for
Active Directory removal. In this case, you can invoke a special version of the wizard to
forcefully remove objects from AD DS that represent the server as a domain controller.
This section includes the following tasks for managing domain controllers:
382
Installing Remote Server Administration Tools for AD DS
Managing Antivirus Software on Active Directory Domain Controllers
Installing a Domain Controller in an Existing Domain
Adding Domain Controllers in Remote Sites
Renaming a Domain Controller
Installing Remote Server Administration

Tools for AD DS
When you install Active Directory Domain Services (AD DS) to create a domain controller, the
administrative tools that you use to manage AD DS are installed automatically. If you want to
manage domain controllers remotely from a computer that is not a domain controller, you can
install the administrative tools on a member server that is running Windows Server 2008 or on a
computer that is running Windows Vista with Service Pack 1 (SP1). On member servers that are
running Windows Server 2008, you use the Remote Server Administration Tools (RSAT) feature
in Server Manager to install Active Directory Domain Services Tools. RSAT replaces Windows
Support Tools and Adminpak.msi that are used with Windows Server 2003.
You can also install Active Directory Domain Services Tools on a computer that is running
Windows Vista with Service Pack 1 (SP1) by downloading the tools.
Installing Active Directory Domain Services Tools

on a member server that is running
Windows Server 2008
You can use the following procedure to add the Active Directory Domain Services Tools
component of RSAT to a member server.
To install Active Directory Domain Services Tools on a member server
1. On the Start menu, click Server Manager.
2. Under Features Summary, click Add Features.
3. Double-click Remote Server Administration Tools, double-click Role Administration
383
Tools, double-click Active Directory Domain Services Tools, and then click Next.
4. Click Install.
5. Click the message that indicates you must restart the server, and then click Yes to restart
the server or click No to restart the server later.
6. After the server restarts, on the Installation Results page of the Resume Configuration
Wizard, click Close. The Active Directory Domain Services Administration Tools are
available on the Administrative Tools menu.
Installing Active Directory Domain Services Tools

on a computer that is running Windows Vista
with SP1
For information about adding the Active Directory Domain Services Tools component of RSAT to
a client computer that is running Windows Vista with SP1, and to download the tools, see
Microsoft Remote Server Administration Tools for Windows Vista (KB941314)
(http://go.microsoft.com/fwlink/?LinkId=95703). On the download page, under Quick Details,
click KB941314. Use the information and the links in the article to download the tools and select
the tools that you want to install on the Windows Vista workstation.
Managing Antivirus Software on Active

Directory Domain Controllers
Because domain controllers provide critical services to their clients, it is crucial to minimize the
risk of any disruption of these services that may be caused by malicious code.
You can generally use antivirus software to mitigate the risk of malicious code. However, installing
antivirus software (from any vendor) on a domain controller and configuring it to scan everything
is not a reliable or recommended solution because the antivirus software may interfere with
domain controller performance. Specifically, the scanning procedures that most antivirus
applications use require exclusive locks on files. In many cases, these locks can interfere with the
real-time data replication that domain controllers use to stay synchronized with the rest of the
network.
The antivirus software that you use must be compatible with Windows operating systems in
general and domain controllers in particular. Antivirus software must be installed in a manner that
protects against attacks as much as possible while not interfering with domain controller
performance. For example, antivirus software must be able to scan Distributed File System (DFS)
files that are replicated by File Replication Service (FRS) or DFS Replication in a way that does
not initiate full synchronization of files and folders in SYSVOL or of DFS roots and links. Any
antivirus vendor should provide specific instructions to correctly configure their product to work
with domain controllers that are running versions of Windows Server and that have Active
Directory Domain Services (AD DS) installed.
384
We cannot guarantee the interoperability of any antivirus software with DFS Replication, including
any tests recommended in this guide. The need for extensive testing can be avoided completely
by asking their antivirus software vendor to disclose their tested interoperability with DFS
Replication. Vendors that have tested their software are happy to stand by their products. For a
list of antivirus software vendors, see article 49500 in the Microsoft Knowledge Base
Guidelines for managing antivirus software on

Active Directory domain controllers
Follow the guidelines from your antivirus software vendor. Verify that the antivirus software you
select is confirmed to be compatible with your domain controllers. Test your chosen antivirus
software solution thoroughly in a lab environment to ensure that the software does not
compromise the stability of your system.
Antivirus software has been known to cause blue screens on domain controllers. Before you
install antivirus software or any update to that software on domain controllers in a domain, test lab
domain controllers for the following issues:
Stability issues
Memory leaks
High CPU usage
Interruptions or failure of inbound and outbound replication
The following recommendations are general and should not be construed as more important than
the specific recommendations of your antivirus software vendor. These guidelines must be
followed for correct Active Directory file replication operation:
Antivirus software must be installed on all domain controllers in the enterprise. Ideally, such
software should also be installed on all other server and client computers that have to interact
with the domain controllers. Catching the virus at the earliest pointat the firewall or at the
client computer on which the virus is first introducedis the best way to prevent the virus
from ever reaching the infrastructure systems on which all client computers depend.
Use a version of antivirus software that is confirmed to work with AD DS and that uses the
correct application programming interfaces (APIs) for accessing files on the server. Some
versions of antivirus software inappropriately modify file metadata as it is scanned, causing
the FRS replication engine to perceive a file as having changed and to schedule it for
replication. Some newer versions of antivirus software prevent this problem. For more
information about antivirus software versions and FRS, see article 815263 in the Microsoft
Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=120540) and see the vendor-specific
sites for compliant versions.
Verify antivirus compatibility with DFS Replication, as described in Testing Antivirus
Application Interoperability with DFS Replication (http://go.microsoft.com/fwlink/?
LinkId=122787).
385
Note
If you are using ForeFront Client Security, see article 956123 in the Microsoft
Knowledge Base for a hotfix (http://go.microsoft.com/fwlink/?LinkId=131409).
Prevent the use of domain controller systems as general workstations. Users should not use
a domain controller to surf the Web or to perform any other activities that can allow the
introduction of malicious code. Allow browsing of known safe sites only for the purpose of
supporting server operation and maintenance.
When possible, do not use a domain controller as a file sharing server. Virus scanning
software must be run against all files in the shared folders, and it can place a large resource
load on the processor and memory resources of the server. For the same reason, the
SYSVOL and Netlogon shares that are automatically created on domain controllers should
not be used to distribute software or for to store data.
Files to exclude from scanning

Exclude the following files and folders from your antivirus scanning operations. These files are not
at risk of infection, and including them can cause serious performance problems or loss of
functionality as a result of file locking and excessive replication between domain controllers.
Furthermore, scanning these files may cause AD DS, FRS, and DFS Replication to work
improperly, possibly causing data loss. Where a specific set of files is identified by name, exclude
only those files rather than the entire folder. In some cases, you must exclude the entire folder.
Do not exclude any files that you think are not at risk based only on the file name extension. (For
example, do not exclude all files with a .dit extension.) Microsoft has no control over other files
that might use the same file name extension as the files shown here. Antivirus software must not
modify any data files in the logs, database, or directory service working directories that are
specified below.
Active Directory and related files to exclude
Main NTDS database files. The location of these files is specified in:
HKLM\System\Services\NTDS\Parameters\DSA Database File
The default location is %systemroot%\ntds.
File to exclude:
Ntds.dit
Active Directory transaction log files. The log directory on any given server is specified in:
HKLM\System\Services\NTDS\Parameters\Database Log Files Path
Files to exclude:
EDB*.log (Notice the wildcard symbol; there can be several log files.)
Edbres00001.jrs
Edbres00001.jrs
386
The NTDS Working folder that is specified in:

HKLM\System\Services\NTDS\Parameters\DSA Working Directory
Files to exclude:
TEMP.edb
EDB.chk
SYSVOL files to exclude

The list in the following table shows the default locations of files and folders to be excluded or
scanned for the SYSVOL directory and subdirectories when you use FRS to replicate SYSVOL.
Folder or File
Scan or
Exclude
%systemroot%\SYSVOL
Exclude
%systemroot%\SYSVOL\domain
Scan
%systemroot%\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory Exclude
%systemroot%\SYSVOL\domain\policies
Scan
%systemroot%\SYSVOL\domain\scripts
Scan
%systemroot%\SYSVOL\staging
Exclude
%systemroot%\SYSVOL\staging areas
Exclude
%systemroot%\SYSVOL\sysvol
Exclude
FRS and related files to exclude
The FRS working directory that is specified in:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Worki
ng Directory
Files to exclude:
<FRS working directory>\jet\sys\edb.chk
<FRS working directory>\jet\ntfrs.jdb
<FRS Working Directory>\jet\log\*.log
The FRS database log files that are specified in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\DB Log
File Directory
Files to exclude:
<FRS working directory>\jet\log\*.log (if the registry entry is not set)
<Database log file directory>\log\*.log (if the registry entry is set)
FRS Replica_root files that are specified in:

387
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\Replica
Sets\GUID\Replica Set Root
The staging directory in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\Replica
Sets\GUID\Replica Set Stage
The FRS Preinstall directory at:

<Replica_root>\DO_NOT_REMOVE_NtFrs_PreInstall_Directory.
The Preinstall directory is always open when FRS is running.
DFS Replication and related files to exclude
System Volume Information\DFSR folders and their contents (includes DFSR.DB). This
system-protected directory contains working files for the DFS Replication service. It should
not be scanned because these files are always in use by the service.
<Replicated folder path>\dfsrprivate folders and their contents

Properly preparing for the installation of Active Directory Domain Services (AD DS) decreases the
chances of problems occurring during the installation process and helps you complete the
installation quickly.
There are a number of requirements for installing AD DS on a new domain controller in an
existing domain. Preparation includes configuring DNS and gathering information that you need
for the installation. This section describes general requirements with respect to Domain Name
System (DNS) configuration, placement of the domain controller in a site, and connectivity for the
Active Directory Domain Services Installation Wizard.
After you have gathered all the information that you need to run the Active Directory Domain
Services Installation Wizard and you have performed the tests to verify that all the necessary
domain controllers are available, you are ready to install AD DS on your server and create an
additional domain controller in your domain.
DNS configuration
The DNS Client service is always present on a server running Windows Server 2008. A DNS
server must be present in an Active Directory forest, and the DNS server must store DNS data for
the server computer that you are installing. You should configure both the DNS client and the
DNS server to ensure that name resolution and related dependencies will function as expected
during the installation of AD DS.
For ease of administration, install the DNS Server service when you install AD DS. When you use
the Active Directory Domain Services Installation Wizard to install the DNS Server service, DNS
zones, zone delegations, root hints or forwarders, and DNS client settings are configured
automatically.
388
Ensure that any required configuration, forwarders, or zones are present and accessible before
installation. For more information about DNS configuration in preparation for domain controller
installation, see Integrating AD DS into an Existing DNS Infrastructure
Site placement
During Active Directory installation, the Active Directory Domain Services Installation Wizard
attempts to place the new domain controller in the appropriate site. You can select a source
replication partner, the site for the new domain controller, or both when you use the wizard to
install AD DS. The appropriate site is determined by the domain controllers IP address and
subnet mask. The wizard uses the IP information to calculate the subnet address of the domain
controller. The wizard then checks to see if a subnet object exists in the directory for that subnet
address. If the subnet object exists, the wizard uses it to place the new server object in the
appropriate site. If the subnet object does not exist, if you do not specify a site, the wizard places
the new server object in the same site as the domain controller that is being used as a source to
replicate the directory database to the new domain controller. Make sure that the subnet object
has been created and that it is associated with the target site before you run the wizard. For
information about creating a subnet and associating it with a site, see Create a Subnet Object or
Objects and Associate them with a Site.
Domain connectivity
During the installation process, the Active Directory Domain Services Installation Wizard must
communicate with other domain controllers to join the new domain controller to the domain. The
wizard must communicate with a member of the domain to receive the initial copy of the directory
database for the new domain controller. The wizard communicates with the domain controller that
holds the domain naming operations master (also known as flexible single master operations or
FSMO) role for domain installations only, so that the new domain controller can be added to the
domain. The wizard must also contact the relative ID (RID) operations master so that the new
domain controller can receive its RID pool, and the wizard must communicate with another
domain controller in the domain to populate the SYSVOL shared folder on the new domain
controller. All of this communication depends on proper DNS installation and configuration. By
using Dcdiag.exe, you can test all of these connections before you start the Active Directory
Domain Services Installation Wizard.
Task requirements
During the installation process, the wizard must communicate with other domain controllers to
add this new domain controller to the domain and get the appropriate information into the
Active Directory database. To maintain security, you must provide credentials that allow
administrative access to the directory.
Before you begin your installation, the following conditions must exist in your environment:
Your Active Directory forest root domain must already exist.
389
If you are installing a new domain controller in a child domain, there should be at least two
properly functioning domain controllers in the forest root domain.
DNS must be functioning properly. In this guide, it is assumed that you are using
Active Directoryintegrated DNS zones. You must have configured at least one domain
controller as a DNS server.
Creating or removing a domain or forest is beyond the scope of this guide.

The following information and tools are necessary to complete this task:
The Active Directory Domain Services Installation Wizard asks for the following specific
configuration information before it begins installing AD DS:
A domain administrators user name and password
A location to store the directory database and log files
A location to store SYSVOL
The password to use for Directory Services Restore Mode (DSRM)
The fully qualified DNS name of the domain to which the new domain controller will be
added
Dcdiag.exe
Network Connections

1. Verify DNS Infrastructure and Registrations
Caution
If any verification test fails, do not continue until you determine what went wrong and you
fix the problems. If one or more of these tests fail, the installation of AD DS is also likely
to fail.
Verify DNS Infrastructure and Registrations

You can use this procedure to verify that the existing Domain Name System (DNS) infrastructure
is sufficient for installing Active Directory Domain Services (AD DS) on the installation computer in
the specified domain. This test reports whether any modifications to the existing DNS
infrastructure are required so that the server can dynamically register DNS records that are
required for the location of the domain controller by other devices on the network. Although the
Active Directory Domain Services Installation Wizard presents a warning message during
Active Directory installation if it encounters DNS registration errors, failure of this test does not
prevent you from running the wizard. However, failed DNS registrations will prevent the domain
controller from functioning properly on the network. Therefore, resolve any problems that this test
reports before you install AD DS.
390
Because all Dcdiag tests include a connectivity test, this procedure also tests TCP/IP connectivity.
To complete this procedure, you must have Dcdiag.exe installed on the server. During the initial
part of the installation of AD DS, you use Server Manager to add the Active Directory Domain
Services server role. This part of the installation procedure installs the Dcdiag.exe command line
tool. The second part of the installation process, running Dcpromo.exe, actually installs AD DS.
Perform the Dcdiag test procedure after you add the Active Directory Domain Services server role
but before you run Dcpromo.exe.
Note
If you do not want to install the Active Directory Domain Services server role at this time,
you can install the Active Directory Domain Services Administration Tools, which include
Dcdiag.exe, by using Add Features in Server Manager. For information about using Add
Features to install the Active Directory Domain Services Administration Tools, see
Installing Remote Server Administration Tools for AD DS.
To verify the DNS infrastructure and registrations
1. If you do not want to install AD DS at this time but you want to perform DNS verification
tests, install the Active Directory Domain Services Administrative Tools, as described in
Installing Remote Server Administration Tools for AD DS, and then go to step 9.
2. If you want to install Dcdiag.exe during the installation of AD DS and run the DNS test
before you run Dcpromo.exe, click Start, and then click Server Manager.
click Next.
Next.
8. On the Installation Results page, do not click Close this wizard and launch the Active
Directory Domain Services Installation Wizard (dcpromo.exe). First, perform steps 9
and 10. When you have completed the Dcpromo test successfully, return to the
Installation Results page and continue with the installation of the Active Directory
Domain Services server role.
9. Open a Command Prompt window as an administrator: On the Start menu, right-click
Command Prompt, and then click Run as administrator. If the User Account Control
dialog box appears, provide Domain Admins credentials, if required, and then click
Continue.
391
dcdiag /test:dcpromo /DnsDomain:<DNSDomainName> /ReplicaDC
where <DNSDomainName> is the DNS name of the domain, in the form

<DomainName.ForestName>, in which you want to add a domain controller.
11. If the server does not pass the Dcpromo test, fix the reported problems before you
continue with the installation of AD DS.

controller.
392

See Also

Masters
393


properly.
Installing a Domain Controller in an Existing

Domain
This section describes methods for installing Active Directory Domain Services (AD DS) onto a
Windows Server 2008 server that will become a domain controller in an existing Active Directory
domain. The procedures in this section provide instructions for installing AD DS by using
replication to create the new domain controller or by using installation media. By using the
installation from media (IFM) method, you can avoid replicating AD DS over the network.
Note
This section describes methods for installing writable domain controllers. For information
about installing read-only domain controllers (RODCs), see the Step-by-Step Guide for
Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728) and
Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=120840).
The following methods use replication to create the new domain controller:
Active Directory Domain Services Installation Wizard (Dcpromo.exe), by specifying a source

domain controller or allowing the replication system to select a replication partner.
394
Unattended installation, by instructing Dcpromo to use parameters in an answer file to install

AD DS. The answer file either specifies a source domain controller or allows the replication
system to select a replication partner.
Command-line installation, by using unattend parameters that either specify a source domain
controller or allow the replication system to select a replication partner.
The following methods use installation media as the source for Active Directory installation, which
avoids replication of AD DS:
Active Directory Domain Services Installation Wizard (Dcpromo.exe), by using advanced

options and specifying the location of installation media (the IFM method).
Unattended installation, by instructing Dcpromo to use parameters in an answer file to install

AD DS. The answer file specifies the location of installation media.
Command-line installation, by using unattend parameters to specify the location of installation

media.
Before you perform the installation procedures, prepare the server for installation according to the
instructions in Preparing for Active Directory Installation. To ensure successful installation of a
new domain controller, verify that all critical services that AD DS depends on are configured
according to Requirements for Installing AD DS (http://go.microsoft.com/fwlink/?LinkId=120603).
If you are installing the first Windows Server 2008 domain controller in an existing
Windows Server 2000 or Windows Server 2003 domain, see the domain and forest preparation
information in Installing an Additional Windows Server 2008 Domain Controller
For information about best practices for planning, testing, and deploying AD DS, see the AD DS
Design Guide (http://go.microsoft.com/fwlink/?LinkID=116282) and see the AD DS Deployment
Guide (http://go.microsoft.com/fwlink/?LinkId=116283).
This section includes the following tasks for installing a domain controller in an existing domain:
Installing an Additional Domain Controller by Using the Windows Interface
Installing an Additional Domain Controller by Using IFM
Installing an Additional Domain Controller by Using Unattend Parameters
See Also
Installing an Additional Domain Controller by

The Windows interface provides two wizards that guide you through the process of installing
Active Directory Domain Services (AD DS). The first wizard is the Add Roles Wizard, which you
can access in Server Manager. The second wizard is the Active Directory Domain Services
Installation Wizard, which you can access in the following ways:
395
When you complete the Add Roles Wizard in Server Manager, click the link to start the
Click Start, click Run, type dcpromo.exe, and then click OK.
If you use the advanced options in the Active Directory Domain Services Installation Wizard, you
can control how AD DS is installed on the server, either by installation from media (IFM) or by
replication:
IFM: You can provide a location for installation media that you have created by using
Ntdsutil.exe or that you have created by restoring a critical-volume backup of a similar
domain controller in the same domain to an alternate location. If you create the installation
media by using Ntdsutil, you have the option to create secure installation media for a readonly domain controller (RODC). In this case, the Ntdsutil process removes cached secrets
(such as passwords) from the installation media. For information about using IFM to install an
RODC, see Planning and Deploying Read-Only Domain Controllers
(http://go.microsoft.com/fwlink/?LinkId=120840). You can also create installation media by
restoring an Active Directory backup to an alternate location. For information about creating
installation media by restoring a critical-volume backup to an alternate location, see Restoring
a Critical-Volume Backup to an Alternate Location (http://go.microsoft.com/fwlink/?
LinkId=120612).
Replication: You can specify a domain controller in the domain from which to replicate AD DS.
To complete this task, perform one of the following procedures:
Install an Additional Domain Controller by Using the Windows Interface
See Also

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).
To install an additional domain controller by using the Windows interface
1. Click Start, and then click Server Manager.
396
click Next.
Next.
7. On the Installation Results page, click Close this wizard and launch the Active
Directory Domain Services Installation Wizard (dcpromo.exe).
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.
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
397
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 offline.
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.
398
click Finish.
can restart the server to complete the installation of AD DS when you are prompted to do
so.
See Also

Using IFM
When you install Active Directory Domain Services (AD DS) by using the install from media (IFM)
method, you can reduce the replication traffic that is initiated during the installation of an
additional domain controller in an Active Directory domain. Reducing the replication traffic
reduces the time that is necessary to install the additional domain controller.
Windows Server 2008 includes an improved version of the Ntdsutil tool that you can use to create
installation media for an additional domain controller. You can use Ntdsutil.exe to create
installation media for additional domain controllers that you are creating in a domain. The IFM
method uses the data in the installation media to install AD DS, which eliminates the need to
replicate every object from a partner domain controller. However, objects that were modified,
added, or deleted since the installation media was created must be replicated. If the installation
media was created recently, the amount of replication that is required is considerably less than
the amount of replication that is required for a regular AD DS installation.
You can also create installation media by restoring a critical-volume backup of a similar domain
controller in the same domain to an alternate location. For information about creating installation
media by restoring a critical-volume backup to an alternate location, see Restoring a CriticalVolume Backup to an Alternate Location (http://go.microsoft.com/fwlink/?LinkID=120612).
Note
You cannot restore a system state backup to an alternate location. A system state backup
can only be restored on the local domain controller, and therefore this type of backup is
not appropriate for creating installation media. To use this method of creating installation
media, you must restore a critical-volume backup.
The procedures in this task are particularly useful for installing domain controllers in remote sites.
By using these procedures, you can avoid having to either replicate the entire Active Directory
replica over a wide area network (WAN) link or disconnect an existing domain controller while it is
being shipped to the remote site. For more information about installing additional domain
controllers in remote sites, see Adding Domain Controllers in Remote Sites.
399
IFM has the following requirements:
You cannot use IFM to create the first domain controller in a domain. A
Windows Server 2008based domain controller must be running in the domain before you
can perform IFM installations.
The media that you use to create additional domain controllers must be taken from a domain
controller in the same domain as the domain of the new domain controller.
If the domain controller that you are creating is to be a global catalog server, the media for the
installation must be created on an existing global catalog server in the domain.
To install a domain controller that is a Domain Name System (DNS) server, you must create
the installation media on a domain controller that is a DNS server in the domain.
To create installation media for a full (writable) domain controller, you must run the ntdsutil
ifm command on a writable domain controller that is running Windows Server 2008.
Note
You cannot run the ntdsutil ifm command on a domain controller that runs
Windows Server 2003. However, you can create a system state backup of a
Windows Server 2003 domain controller, restore the backup to an alternate location,
and then use the dcpromo /adv command to create a Windows Server 2003 domain
controller. For information about performing IFM installations on domain controllers
that are running Windows Server 2003, see Installing a Domain Controller in an
Existing Domain Using Restored Backup Media (http://go.microsoft.com/fwlink/?
LinkId=120623).
To create installation media for a read-only domain controller (RODC), you can run the
ntdsutil ifm command on either a writable domain controller or an RODC that runs
Windows Server 2008. For RODC installation media, Ntdsutil removes any cached secrets,
such as passwords. For more information about installing and managing RODCs, see the
Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=92728).
You can use a 32-bit domain controller to generate installation media for a 64-bit domain
controller, and the reverse is also true. The ability to mix processor types for IFM installations
is new in Windows Server 2008.
Ntdsutil.exe can create the two types of installation media, as described in the following table.
Type of installation media
Parameter
Description
Full (writable) domain

controller
Create Full PathToMediaFolder
Creates installation media for a

writable domain controller or an
Active Directory Lightweight
Directory Services (AD LDS)
instance in the folder that is
identified in the path. If you are
creating media in a shared
folder on another computer,
400
Type of installation media
Parameter
Description
map a network drive to the

folder before you perform the
procedure.
Read-only domain controller
Create RODC
PathToMediaFolder
Creates installation media for

an RODC in the folder that is
identified in the path
Task requirements
Ntdsutil.exe
Dcpromo.exe

1. Create Installation Media by Using Ntdsutil
2. Install an Additional Domain Controller by Using Installation Media
See Also
Create Installation Media by Using Ntdsutil

You can use the following procedure to create installation media for installing Active Directory
Domain Services (AD DS) to create a new domain controller in an existing domain. Create the
media on a domain controller in the domain where you are installing one or more new domain
controllers.
This procedure uses Ntdsutil to create installation media. You can also create installation media
by restoring a critical-volume backup to an alternate location. This method is not recommended
because it takes significantly longer than the Ntdsutil method and it requires more space for the
installation media, which contains more data than is required for installing AD DS. For more
information, see Restoring a Critical-Volume Backup to an Alternate Location
The ability to log on to a domain controller locally and to back up a domain controller is the
minimum required to complete this procedure. Members of Builtin Administrators, Enterprise
Admins, Domain Admins, Backup Operators, and Server Operators have these rights by default.
401
On a read-only domain controller (RODC), a delegated user can create the installation media.
However, that user can create only RODC installation media (not installation media for a writable
domain controller) on an RODC.
To create installation media for IFM
1. Open a command prompt as an administrator: Click Start, right-click Command Prompt,
and then click Run as administrator.
2. Type the following command, and then press ENTER:
ntdsutil
3. At the ntdsutil prompt, type the following command, and then press ENTER:
activate instance ntds
4. At the ntdsutil prompt, type the following command, and then press ENTER:
ifm
5. At the ifm prompt, type the command for the type of installation media that you want to
create, and then press ENTER. For example, to create installation media for a read-write
domain controller, type the following command:
Create full <Drive>:\<InstallationMediaFolder>
Where <Drive>:\<InstallationMediaFolder> is the path to the folder where you want the
installation media to be created. You can save the installation media to a network shared
folder or to removable media.
When you create additional domain controllers in the domain, you can refer to the shared folder
or removable media where you store the installation media as follows:
In the Active Directory Domain Services Installation Wizard: on the Install from Media page
In an unattended installation answer file: in the /ReplicationSourcePath parameter
See Also
Create an Answer File for Unattended Domain Controller Installation

Using Installation Media
You can use this procedure to install Active Directory Domain Services (AD DS) from media. You
can use the install from media (IFM) method to create an additional domain controller in an
existing domain.
When you create an additional domain controller in the domain, you can specify sourcing the
installation from the shared folder or removable media where you created the installation media
by using one of the following methods:
402
Windows interface: Provide the location on the Install from Media page in the
Unattended installation: Use the /ReplicationSourcePath parameter in the answer file for an
unattended installation.
Command line: Use the /ReplicationSourcePath unattend parameter at the command line.
Membership in the Domain Admins group in the domain into which you are installing the
additional domain controller, or the equivalent, is the minimum required to complete this
To install AD DS from IFM media by using the Windows interface
1. Use the procedure Install an Additional Domain Controller by Using the Windows
Interface. In step 8, select Use advanced mode installation.
2. In step 15, select the install from media option and provide the location of the installation
media.
3. Complete the remaining pages of the Active Directory Domain Services Installation
Wizard.
4. After the installation operation completes successfully and the computer is restarted,
remove the folder that contains the IFM media from the local disk.
To install AD DS from IFM media by using an answer file
1. Create an answer file by using one of the following methods:
During the procedure Install an Additional Domain Controller by Using the Windows
Interface, select the Export settings option to save the installation settings to a file.
This file is an answer file that you can use to install an additional domain controller in
the same domain.
Use the procedure Create an Answer File for Unattended Domain Controller
Installation to create an answer file. Include the /ReplicationSourcePath parameter
to specify the location of the IFM media.
2. Use the procedure Install an Additional Domain Controller by Using an Answer File to
install AD DS.
To install AD DS from IFM media by using unattend parameters from the command line
1. Use the procedure Install an Additional Domain Controller by Using Unattend Parameters
from the Command Line to install AD DS.
2. During the procedure, use the /ReplicationSourcePath parameter to specify the location
of the IFM media.
403
See Also

Using Unattend Parameters
You can use unattend parameters to specify configuration settings for installing Active Directory
Domain Services (AD DS) to create an additional domain controller in an existing domain.
Specifically, you can use the dcpromo /unattend command to install AD DS.
You can use unattend parameters in the following ways:
In an answer file: You can manually create an answer file that contains unattend parameters
to specify the settings for a domain controller, including such values as its name, domain,
site, and whether it is a writable domain controller or read-only domain controller (RODC).
You can also create an answer file automatically by exporting installation settings to a file
during an Active Directory Domain Services Installation Wizard installation.
Note
For information about installing RODCs, see Step-by-Step Guide for Read-only
Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728) and Planning and
Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=120840).
From the command line: You can type the parameters and values manually at the command
line.
Running an unattended installation simplifies the process of installing and configuring

Active Directory Domain Services (AD DS) on multiple computers. When you use Dcpromo to
reference the answer file, the installation proceeds from start to completion without user
intervention. This method is most useful when you want to install AD DS with identical options on
many computers.
Task requirements
The following tools are required to complete this task:
Text editor application
Dcpromo.exe

1. Create an Answer File for Unattended Domain Controller Installation
2. Install an Additional Domain Controller by Using an Answer File
3. Install an Additional Domain Controller by Using Unattend Parameters from the Command
Line
404
See Also
Installing an Additional Domain Controller by Using the Windows Interface
Create an Answer File for Unattended

Domain Controller Installation
You can use this procedure to create a text file that you can use as the answer file for an
unattended installation of an additional domain controller. Use the answer file to install
Active Directory Domain Services (AD DS) on either a full installation of Windows Server 2008 or
a Server Core installation of Windows Server 2008. The answer file contains sensitive
information, and it should be kept in a secure location.
Notes
The answer file that you use to install an additional domain controller in an existing
domain must have the /ReplicaOrNewDomain and /ReplicaDomainDNSName
parameters specified.
The answer file that you use to install a domain controller from media must have the
/ReplicationSourcePath parameter specified.
Any account that has Read and Write privileges for the text editor application is the minimum
To create an answer file for installing a new domain controller
1. Open Notepad or any text editor.
2. On the first line, type [DCINSTALL], and then press ENTER.
3. Create the following entries, one entry on each line. These options are the minimum
options that are required for an additional domain controller installation with Domain
Name System (DNS) and the global catalog installed and configured automatically.
For a complete list of unattended installation options, including default values, allowed
values, and descriptions, see Promotion Operation (http://go.microsoft.com/fwlink/?
LinkID=120626).
UserName=SAM account name that has Domain Admins credentials in the target
domain. This account must be used by the administrator who runs the Dcpromo
command.
UserDomain=Domain name for the user account in UserName
Password=Password for the account in UserName. If you leave this blank, Dcpromo
prompts the installer for a password during installation. Dcpromo deletes this value after
installation.
405
ReplicaDomainDNSName=The fully qualified domain name (FQDN) of the domain of

the new domain controller.
ReplicaOrNewDomain=Replica for an additional domain controller in an existing domain
or NewDomain for the first domain controller in a new domain.
DatabasePath=Location of the Ntds.dit filea folder on a local volume, surrounded by
double quotation marks. (The default is %systemroot%\ntds.) If you omit this entry,
Dcpromo uses the default location.
LogPath=Location of the database log filesa folder on a local volume, surrounded by
double quotation marks. (The default is %systemroot%\ntds.) If you omit this entry,
SYSVOLPath=Location of the SYSVOL treea folder on a local volume, surrounded by
double quotation marks. (The default is %systemroot%\SYSVOL.) If you omit this entry,
InstallDNS=Yes to make the domain controller a DNS server or no to create a domain
controller without DNS installed.
ConfirmGC=Yes to make the domain controller a global catalog server or No to create a
domain controller without the global catalog read-only directory partitions.
SafeModeAdminPassword=Password for the administrator account that must be used
to start the domain controller in Directory Services Restore Mode (DSRM). If you leave
this blank, Dcpromo prompts the installer for the password during installation. Dcpromo
deletes this value after installation. Passwords are removed from the answer file when
you run Dcpromo.
RebootOnCompletion=Yes if you want the domain controller to restart automatically
following a successful installation, no if you want to restart the domain controller
manually. If you do not want the domain controller to restart automatically and you do not
want to be prompted, use the value NoAndNoPromptEither.
4. If you want to include application directory partitions in the answer file, add the following
parameter:
ApplicationPartitionsToReplicate=
Provide a value for ApplicationPartitionsToReplicate as follows:
If you want to include all application directory partitions, use the value *.
If you want to include specific application directory partitions, type the distinguished
name of each directory partition. Separate each distinguished name with a space,
and enclose the entire list in quotation marks, as shown in the following example:
ApplicationPartitionsToReplicate="dc=app1,dc=contoso,dc=com
dc=app2,dc=contoso,dc=com"
5. Save the answer file to the location on the installation server from which it is to be called
by Dcpromo, or save the file to a network shared folder or removable media for
distribution.
406
See Also
Install an Additional Domain Controller by Using an Answer File
Install an Additional Domain Controller by Using Unattend Parameters from the Command Line

Using an Answer File
You can use this procedure to install an additional domain controller in an existing domain. To
perform this procedure, you must have created an answer file. You can create an answer file
automatically when you install a domain controller using the Active Directory Domain Services
Installation Wizard by selecting the option to export the installation information to a file. For
information about creating an answer file manually, see Create an Answer File for Unattended
Domain Controller Installation.
Note
You can also use an answer file to create a new domain.
After you create the answer file, use the following procedure to perform the unattended
installation. You can use this procedure to install Active Directory Domain Services (AD DS) on
either a full installation of Windows Server 2008 or a Server Core installation of Windows
Server 2008.
To install a new domain controller by using an answer file
Open a Command Prompt as an administrator: On the Start menu, right-click Command

dcpromo /unattend:"<path to the answer file>"
See Also
Create an Answer File for Unattended Domain Controller Installation
407

Using Unattend Parameters from the
Command Line
You can use the following procedure to install a new domain controller from the command line. In
this method of installation, you type unattended installation parameters at the command line
rather than creating an answer file. For a complete list of unattended installation options,
including default values, allowed values, and descriptions, type dcpromo /?:Promotion at a
command prompt, or see Promotion Operation (http://go.microsoft.com/fwlink/?LinkID=120626).
To install an additional domain controller by entering unattended installation
parameters at the command line
At a command prompt, type the following command. When you have typed all the options
that are required to create the additional domain controller, press ENTER.
dcpromo /unattend /<unattendOption>:<value> /<unattendOption>:<value> ...
Where:
<unattendOption>
<value>
is an option in the Promotion Operation table. Separate each

<option:value> pair with a space.
is the configuration instruction for the option.
The following example creates an additional domain controller with the global catalog,
and it installs and configures the DNS Server service:
dcpromo /unattend /InstallDns:yes /confirmGC:yes /replicaOrNewDomain:replica
/databasePath:"e:\ntds" /logPath:"e:\ntdslogs" /sysvolpath:"g:\sysvol"
/safeModeAdminPassword:FH#3573.cK /rebootOnCompletion:yes

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
408
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:
DNS Manager
Event Viewer
Dcdiag.exe
Ntdsutil.exe

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.
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.
8. Verify a Domain Computer Account for a New Domain Controller

controller.
409

See Also
Configure DNS Server Forwarders

You can use this procedure to configure Domain Name System (DNS) server forwarders.
When you add a new domain controller that is a DNS server, if your network uses forwarding for
recursive name resolution, configure DNS server forwarders based on the forwarding method that
is established on your network. When forwarders are configured, a DNS server that receives a
DNS query for a name for which it is not authoritative forwards the request to the DNS forwarder
instead of using root hints. If your network uses forwarding, use the DNS snap-in to add the
appropriate forwarders on the new domain controller. If you want the DNS Server service on the
new domain controller to forward queries to different servers depending on the DNS suffix that is
410
specified in the query, configure conditional forwarding appropriately. For information about using
forwarding and conditional forwarding for DNS name resolution, see Using Forwarding
Note
Root hints is the recommended method of recursive name resolution for Active Directory
integrated DNS in Windows Server 2008 forests. For more information about configuring
DNS for Windows Server 2008 forests, see the AD DS Deployment Guide
To configure DNS server forwarders
1. If your network uses root hints as the DNS forwarding method, you do not have to
perform any additional options. Root hints are configured automatically during installation.
Do not continue to step 2.
2. If you have to configure forwarders, open the DNS snap-in, and continue to step 3.
3. In the console tree, right-click ComputerName (where ComputerName is the computer
name of the domain controller), and then click Properties.
4. In the ComputerName properties sheet (where ComputerName is the name of the
domain controller), on the Forwarders tab, click Edit.
5. Click the text entry area where indicated, type an IP address or DNS name for a DNS
server that will receive forwarded DNS queries, and then click OK.
6. When the IP address resolves to the servers fully qualified domain name (FQDN) on the
Forwarders tab, click OK.
Verifying DNS Configuration

Part of verifying Active Directory installation is verifying that Domain Name System (DNS) is
installed and configured appropriately. Regarding DNS configuration for Active Directory forests,
we recommend that you install the DNS Server service on all domain controllers. When you use
the Active Directory Domain Services Installation Wizard to install DNS during installation of
Active Directory Domain Services (AD DS), the wizard creates the DNS zone delegation
automatically. The Net Logon service registers the required host and service resource records for
the new domain controller when it restarts after installation.
The DNS Client service on a domain controller determines the DNS servers that the domain
controller uses to locate other domain controllers. Verify that the primary and alternate DNS
server settings are appropriate for the network segment.
Task requirements
411
DNS snap-in
Network Connections

1. Verify DNS Server Configuration for a Domain Controller
2. Verify DNS Client Settings
Verify DNS Server Configuration for a

Domain Controller
You can use this procedure to verify DNS Server service configuration on a new additional
domain controller that has Domain Name System (DNS) installed. Verify that resource records
are registered so that clients can locate the DNS server. Verify also that the forest and domain
DNS zone application directory partitions have replicated so that the DNS server receives zone
updates.
To verify DNS server configuration for a domain controller
DNS. If the User Account Control dialog box appears, provide Domain Admins
credentials, if required, and then click Continue.
2. Double-click Forward Lookup Zones, and verify that the zone
_msdcs.ForestRootDomain and the zone for the domain of the new domain controller are
present.
3. Click the domain node, and then, in the details pane, verify that host (A) resource
records, IPv6 host (AAAA) resource records (if TCP/IPv6 addresses are in use), and
name server (NS) resource records are present for the new domain controller.
4. To verify that the ForestDnsZones and DomainDnsZones application directory partitions
replicated successfully, open a Command Prompt as an administrator: On the Start
menu, right-click Command Prompt, and then click Run as administrator. If the User
repadmin /showrepl
6. Verify that the DC=DomainDnsZones,DC=DomainName,

,DC=ForestRootDomainName,DC=com and
DC=ForestDnsZones,DC=ForestRootDomainName,DC=com application directory
412
partitions replicated successfully.
See Also
Verify DNS Client Settings
Verify DNS Client Settings

After you install an additional domain controller, verify the DNS Client service settings on the new
domain controller. If you use the Active Directory Domain Services Installation Wizard to install a
domain controller, the wizard configures the DNS Client service settings, as follows:
The preferred Domain Name System (DNS) server is added to the DNS servers list of the
DNS client settings.
The alternate DNS server is unchanged, but 127.0.0.1 is added.

Note
If IP version 6 (IPv6) is enabled, IPv6 addresses are used instead of IP version 4 (IPv4)
addresses.

To verify the DNS client settings
2. Right-click the connection that represents the connection that the domain controller uses
to attach to the network, and then click Properties.
3. In Connection Properties, double-click Internet Protocol Version 4 (TCP/IPv4) or
Internet Protocol Version 6 (TCP/IPv6).
4. In Internet Protocol (TCP/IP) Properties, verify that Use the following DNS server
addresses is selected.
5. Verify that the Preferred DNS server IP address is the IP address of the new domain
controller (so that it is referencing itself). Verify that the Alternate DNS server address is
that of another DNS server in the same domain.
6. Click OK twice.
See Also
Verify DNS Server Configuration for a Domain Controller
413

Netlogon Shares
net share

Note
Security Settings.
414

domain controller.
Note
/v
option.
the problem.
Verify a Domain Computer Account for a New

Domain Controller
You can use this procedure to verify that a domain computer account is registered properly and
that the Service Principal Names (SPNs) are advertised. This account is required for the domain
controller to function as a domain controller in the domain.
To verify a domain computer account for a new domain controller
dcdiag /test:MachineAccount
3. It the test is successful, you should see the following message:

415
<ComputerName> passed test MachineAccount.
To receive more detailed information, including the SPNs that are found for the domain
controller, use the /v option.

You can create an additional domain controller in a domain by installing Active Directory Domain
Services (AD DS) on a server computer. When you are placing the additional domain controller in
a remote site, you can install AD DS on the server either before or after you ship it to the remote
site, as follows:
Ship the computer as a workgroup computer, and install AD DS on it in the remote site. If you
do not have administrative support in the remote site, enable Remote Desktop on the
computer before you ship the computer so that you can perform the installation remotely. In
the remote site, you can either:
Install AD DS from installation media that has been shipped to the site on removable
media.
Install AD DS over the network.
Install AD DS on the server in a hub or staging site, and then ship the installed domain
controller to the remote site.
Both methods have advantages and disadvantages, and both methods require care to ensure the
secure transfer of Active Directory data, whether it is installed or in the form of removable media.
For information about the advantages and disadvantages of shipping a server to a remote site
before or after installing AD DS, see Known Issues for Adding Domain Controllers in Remote
Sites.
For recommended practices for adding domain controllers to remote sites for the method that you
are using, see Best Practices for Adding Domain Controllers in Remote Sites.
By reviewing issues and guidelines, you can decide the best method of adding domain controllers
in remote sites for your environment. By following the instructions in this guide, you can safely
and securely install domain controllers in remote sites, either locally or remotely.
Note
On servers that are running Windows Server 2008, you can install a read-only domain
controller (RODC), which is ideal for providing AD DS in remote sites without incurring the
security risks of a writable domain controller. For information about installing and
managing RODCs in remote sites, see Planning and Deploying Read-Only Domain
Controllers (http://go.microsoft.com/fwlink/?LinkID=120709).
This section includes the following tasks, known issues, and best practices for adding domain
controllers in remote sites:
Known Issues for Adding Domain Controllers in Remote Sites

416
Best Practices for Adding Domain Controllers in Remote Sites
Preparing a Server Computer for Shipping and Installation from Media
Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection
Reconnecting a Domain Controller After a Long-Term Disconnection
Best Practices for Adding Domain

Controllers in Remote Sites
By reviewing the information in Known Issues for Adding Domain Controllers in Remote Sites,
you can determine the best method to use for installing Active Directory Domain Services
(AD DS) to create domain controllers in your remote sites. The following best practices help
ensure trouble-free installation of domain controllers in remote sites.
Important
Do not attempt to perform actions based only on the recommendations that are described
in this topic. Step-by-step guidance is provided in the task-based topics in this guide for
all recommendations in this topic.
Best practices for using IFM to install AD DS in

the remote site
Installation from media (IFM) is a method of installing AD DS without replication from a source
domain controller. By using IFM, you provide a local source for the domain, configuration, and
schema directory partitionsand, as an option, global catalog, partial, read-only directory
partitions and Domain Name System (DNS) application directory partitions. The local source is
the installation media files that reside on the server that you are installing. Updates to object
attributes that occur since the installation media was created will replicate over the network from
an existing domain controller in the domain or forest. Although SYSVOL is part of the installation
media, under normal conditions the source for SYSVOL is not the installation media. Instead,
SYSVOL is created by replication from an existing domain controller. Configuring the installation
media to be the source for SYSVOL requires additional procedures. For information about using
installation media as the source for SYSVOL during IFM installation of AD DS, see Planning and
Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).
To use IFM for installation of one or more additional domain controllers in a domain, you can do
one of the following:
Specify a volume on the installation computer as the location for the media when you run the
ntdsutil ifm command. For information about the effects of the location on the installation
process, see Preparing a Server Computer for Shipping and Installation from Media.
Create the media locally, and then copy ("burn") the installation media onto removable media,
such as a portable disk drive, CD, or DVD, which can be shipped with the installation
computer when it leaves the staging site, or it can be shipped separately.
417
Create the media locally, and then transfer the installation media to the local hard drive of the
workgroup computer before it leaves the staging site.
For information about the advantages and disadvantages of these methods, see Preparing a
Server Computer for Shipping and Installation from Media.
The following best practices optimize data security and consistency when you add domain
controllers in remote sites:
Upgrade to Windows Server 2008. Windows Server 2008 includes an enhanced version of
Ntdsutil.exe that you can use to create installation media, rather than using a restored system
state backup as is required in Windows Server 2003. Ntdsutil.exe in Windows Server 2008
includes a new ifm command that creates installation media for additional domain controllers.
The installation media that is created by this command contains only is the items that are
required for installing AD DS: the Ntds.dit database file and the registry. You can create media
for a full (writable) installation of AD DS or for a read-only domain controller (RODC)
installation. For the RODC installation, the ntdsutil ifm command creates secure installation
media by removing secrets, such as passwords, from the Active Directory data. You create
the media by using Volume Shadow Copy Service (VSS), taking a fraction of the time that is
required to create a backup. For information about upgrading the forest to
Windows Server 2008, see the AD DS Deployment Guide (http://go.microsoft.com/fwlink/?
LinkId=116283).
Note
On a domain controller that is running Windows Server 2008, you cannot restore a
system state backup to an alternate location. Instead, use the ntdsutil ifm command
to create installation media.
Create media on the type of domain controller that you want to add. You must create
installation media on the type of domain controller that you want to add. If you want to add a
global catalog server in the remote site, run the ntdsutil ifm command on a global catalog
server in the domain. If you want to add a DNS server, run the ntdsutil ifm command on a
domain controller that is a DNS server in the domain.
Take the same security precautions when you ship removable installation mediaor a
server computer that contains installation mediaas you would when you ship an
installed domain controller. For information about securing domain controllers, see the Best
Practice Guide for Securing Windows Server Active Directory Installations
Minimize the time between media creation and installation. Minimizing this delay reduces
the number of updates that will be required to replicate after installation.
Install the operating system before you ship the server to the remote site. Installing the
operating system requires expertise that might not be available at branch sites. Ideally,
installation routines are available in the staging site to automate the operating system
installation process and ensure uniformity for all domain controllers (partition sizes, drive
letter assignments, and so on). As part of the operating system installation, apply a
standardized set of hotfixes plus any available service packs to ensure service consistency
throughout the forest.
418
Ship the server as a member of a workgroup rather than a member server in a domain.
If the server is joined to a domain and then stolen during shipment, information about domain
names, DNS suffixes, and the number of domains in the forest can aid attackers in their
attempts to compromise or steal directory data.
Ship computers with properly configured IP, subnet mask, default gateway, and DNS
server addresses. Remember to reconfigure the server with TCP/IP settings that are
appropriate to the target site, not the staging site.
Enable Remote Desktop on the server computer before shipping. This best practice
assumes that you want to install and manage AD DS remotely rather than employing an
administrator with Domain Admins credentials in each remote site.
Best practices for installing domain controllers

before you ship them to a remote site
When you install AD DS in the hub or staging site, disconnect the installed domain controller, and
then ship the computer to the remote site, you are disconnecting a viable domain controller from
the replication topology. The most significant risk from disconnection is that the domain controller
will remain offline long enough to exceed the tombstone lifetime and thereby become capable of
retaining objects that have been permanently deleted from the directory on all other domain
controllers in the domain. Such objects, called lingering objects, cause directory inconsistency,
and, under certain conditions, they can be reintroduced into the directory. For information about
the causes and effects of lingering objects and how to avoid them, see Known Issues for Adding
Domain Controllers in Remote Sites.
The following best practices help ensure a smooth and secure disconnection and restart. For
step-by-step procedures to perform all of these best practices, see Preparing an Existing Domain
Controller for Shipping and Long-Term Disconnection and Reconnecting a Domain Controller
After a Long-Term Disconnection.
Configure the tombstone lifetime appropriately. Ensure that the tombstone lifetime is not
lowered below the default value. The default tombstone lifetime in a forest that is created on a
domain controller running Windows 2000 Server or Windows Server 2003 is 60 days. The
default tombstone lifetime in a forest that is created on a server running
Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2
(SP2), Windows Server 2003 R2, or Windows Server 2008 is 180 days. If you must
disconnect a domain controller for a period of several weeks or months, before you
disconnect the domain controller, do the following:
Estimate the anticipated length of disconnection.
Determine the value of the tombstone lifetime for the forest. This value is stored in
the tombstoneLifetime attribute of CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain.
Determine the maximum length of time that the domain controller can be
disconnected safely. From the tombstone lifetime number of days, subtract a generous
estimate of the number of days that are required for end-to-end replication latency. The
419
resulting amount of time is the maximum period for which the domain controller can be
disconnected safely, without danger of expired deletions (tombstones) remaining on the
domain controller.
Determine whether to extend the tombstone lifetime for the forest. If you estimate
the maximum time of disconnection to be longer than the tombstone lifetime, you must
determine whether to extend the tombstone lifetime or perform the procedure to remove
lingering objects from the domain controller after it is reconnected. If you extend the
tombstone lifetime, you must also make sure that all domain controllers have adequate
disk space to store additional tombstones. In addition, make sure that replication of the
tombstone lifetime change has reached all potential source domain controllers before you
run Dcpromo to install an additional domain controller.
Ensure that strict replication consistency is enabled on all domain controllers. Strict
replication consistency is a registry setting thatwhen it is enabledstops inbound
replication of a directory partition from a source domain controller that is suspected of having
a lingering object. Strict replication consistency should be enabled for the forest to prevent
the reintroduction of a lingering object into the directory. You can use the repadmin /regkey
command to enable this setting on a specific domain controller or on all domain controllers in
the forest, as described in Enable Strict Replication Consistency.
Monitor the Knowledge Consistency Checker (KCC) topology and replication to ensure
that unintended long disconnections are detected. By monitoring replication, you can
detect disconnections that occur as a result of network failures, service failures, or
configuration errors. Use the Active Directory Management Pack or other monitoring
application to implement a monitoring solution for your Active Directory deployment. Event
IDs to monitor include 1311, 1388, 1925, 1988, 2042, 2087, and 2088.
Ship computers with properly configured IP, subnet mask, default gateway, and DNS
server addresses. Remember to reconfigure the server with TCP/IP settings that are
appropriate to the target site, not the staging site.
Prepare the registry for automatic nonauthoritative restore of SYSVOL when the
domain controller restarts. This recommendation applies only when you use FRS to
replicate SYSVOL. For FRS replication of SYSVOL, the nonauthoritative restore prevents the
domain controller from having to reconcile and process deletions and modifications that took
place from the time of the last SYSVOL update to the time that the domain controller is
restarted in the new site, which improves synchronization time. For information about
preparing for nonauthoritative restore of SYSVOL, see Prepare a domain controller for
nonauthoritative SYSVOL restart (http://go.microsoft.com/fwlink/?LinkId=122831). This
additional configuration is not required for Distributed File System (DFS) Replication of
SYSVOL because DFS Replication processes updates differently.
Ensure that the domain controller replicates successfully with all replication partners.
Immediately before you disconnect the domain controller, force replication with its partners.
Check that replication has succeeded before you disconnect the domain controller.
Label the domain controller. When you disconnect the domain controller, attach a label to
the computer that identifies the date and time of disconnection, the destination, and the IP
settings.
420
When you reconnect the domain controller, update SYSVOL as quickly as possible.
The domain controller does not serve as a domain controller until SYSVOL has been updated
through replication. If the site has one or more other domain controllers in the same domain,
start the domain controller anytime. If the site contains no other domain controller in the same
domain, time the restart of the domain controller to coincide with the beginning of intersite
replication.
To avoid time skew issues, ensure that the system clock is synchronized with the
domain source on startup. When you start the domain controller in the remote site, use the
following command to ensure that the domain controller uses the domain hierarchy to
synchronize time:
w32tm /resync/ computer:<PDCEmulatorHostName>
See Also
Known Issues for Adding Domain Controllers

in Remote Sites
Review the following known issues before adding domain controllers in remote sites. You can use
the information in this section to determine the method for adding domain controllers in remote
sites that is best for your environment. Each method has advantages and disadvantages that are
described in this section.
Important
Do not attempt to perform actions based only on the recommendations in this topic. Stepby-step guidance is provided in the task-based topics in this section for all actions that
are recommended in this topic. Follow the links in this topic to the related task-based
topics.
You can use the following methods to add domain controllers in remote sites:
Ship the member computer to the remote site, and then use the install from media (IFM)
method to install Active Directory Domain Services (AD DS) on that computer. IFM uses
previously prepared installation media as the source for the installation of AD DS in the
remote site, avoiding replication from a source domain controller.
Install AD DS in the hub site by using the normal Dcpromo method or the IFM method, and
then ship the installed domain controller to the remote site.
SYSVOL replication issues potentially affect both methods.

421
SYSVOL replication
SYSVOL is a shared folder that stores files that must be available and synchronized among all
domain controllers in a domain. SYSVOL contains Net Logon scripts, Group Policy settings, and
either File Replication Service (FRS) or Distributed File System (DFS) Replication staging
directories and files, depending on the replication method in use for replicating DFS folders.
Replication of the SYSVOL folder is required for AD DS to function properly.
The primary focus for both methods of installing additional domain controllers in remote sites is to
avoid the replication of AD DS over a wide area network (WAN) between the remote site and the
hub site. Each method accomplishes this goal. However, depending on the size of your SYSVOL,
you might also be concerned about replication of SYSVOL files over the network. When you use
the IFM method to install a domain controller, SYSVOL is replicated from a domain controller in
the domain unless you perform preliminary procedures. For information about using installation
media as the source for SYSVOL during IFM installation of AD DS when you use DFS Replication
to replicate SYSVOL, see Planning and Deploying Read-Only Domain Controllers
(http://go.microsoft.com/fwlink/?LinkId=120840). If you use FRS to replicate SYSVOL, see
article 311078 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=70809).
Using IFM to install a domain controller in a

remote site
On domain controllers that are running Windows Server 2008, the Ntdsutil command-line tool is
improved to include a new command for creating installation media. The method for using IFM to
install domain controllers includes the following general steps:
1. Use the Ntdsutil ifm command to create installation media from an up-to-date domain
controller in the domain. If you want the additional domain controller to be a global catalog
server, create the media on a global catalog server. If you want the additional domain
controller to be a Domain Name System (DNS) server, create the media on a DNS server.
2. When you create additional domain controllers in the domain, you can refer to the shared
folder or removable media where you store the installation media as follows: on the Install
from Media page in the Active Directory Domain Services Installation Wizard or by using the
/ReplicationSourcePath parameter during an unattended installation.
As an alternative, you can create installation media by using Wbadmin.exe to restore a criticalvolumes backup to an alternate location. However, the Ntdsutil method is more efficient because
you eliminate the restore process, which adds time and effort to the installation process.
Note
In Windows Server 2008, you cannot restore a system state backup to a network shared
folder.
422
Advantages of using IFM to install a domain controller in a

remote site
The following advantages are associated with using IFM to install a domain controller in a remote
site:
You can install many domain controllers from a single source of installation media.
You do not have to disconnect a functioning domain controller from the replication topology.
Therefore, you can avoid the disadvantages that are associated with a domain controller that
does not replicate. For information about the problems that are associated with domain
controller disconnection, see Issues with Installing Domain Controllers Before Shipping Them
to the Remote Site.
You avoid replicating AD DS over a WAN link, particularly a link that requires a dial-up
connection.
If you enable Remote Desktop on the server before you ship it, you do not have to employ an
administrator with Domain Admins credentials in the remote site. You can also use Remote
Server Administration Tools (RSAT) to manage AD DS remotely. You can install the tools on a
member server that is running Windows Server 2008 or on a workstation that is running
Windows Vista with Service Pack 1 (SP1). For information about installing these tools, see
Installing Remote Server Administration Tools for AD DS.
Note
If you do not need a writable domain controller in a remote site, you can install a
read-only domain controller (RODC) in the remote site. RODCs do not require
administrative credentials for management. For information about using RODCs in
remote sites, see Planning and Deploying Read-Only Domain Controllers
Issues with using IFM to install a domain controller in a remote

site
The following issues are associated with using IFM to install a writable domain controller in a
remote site:
Domain Admins credentials and remote installation. If you install a writable domain
controller, an administrator must have Domain Admins credentials to install AD DS. Assuming
that you do not employ a service administrator with this level of administrative credentials in
each branch site, a domain administrator in the hub site must be able to connect remotely to
the server to perform the installation. Therefore, you must enable Remote Desktop on the
server before you ship it to the remote site.
Bridgehead server load balancing. If installation media are sent to many sites and if
enough domain controllers are promoted at the same time, you might experience
performance issues with the bridgehead servers that are the source for Active Directory and
SYSVOL replication.
423
Note
These issues are of concern only in situations in which hundreds of domain
controllers might be promoted at the same time and FRS is the SYSVOL replication
system. If you are deploying hundreds of writable domain controllers in branch sites,
see the Windows Server 2003 Active Directory Branch Office Guide
(http://go.microsoft.com/fwlink/?LinkId=42506). If you are installing RODCs in branch
sites, see Planning and Deploying Read-Only Domain Controllers
SYSVOL replication. Whether you use DFS Replication or FRS to replicate SYSVOL,
replication of the full SYSVOL occurs if you do not perform preliminary preseeding
procedures, as described in article 311078 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=70809) for SYSVOL that is replicated by FRS, and
in Planning and Deploying Read-Only Domain Controllers
(http://go.microsoft.com/fwlink/?LinkId=120840) for SYSVOL that is replicated by
DFS Replication. When you install AD DS without this additional preparation, the
SYSVOL data in the installation media is deleted and SYSVOL is generated by
replication.
Because FRS on the source computer uses CPU, memory, and disk resources, the FRS
recommendation is to perform a staged update on no more than 10 branch office domain
controllers at a time for a single source hub domain controller. If a single domain
controller functions as the source for SYSVOL replication to more than 10 destination
domain controllers, performance on the source domain controller can decrease
significantly. To balance source domain controllers, you can use an answer file with
Dcpromo to specify the source domain controller.
Note
When you use DFS Replication to replicate SYSVOL, these conditions are not an
issue.
For information about performing a staged installation of RODCs, see Planning and
Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=120840).
Installing domain controllers before shipping

them to the remote site
When you install a domain controller and then disconnect it from the network for a period of time,
you interrupt the normal activities of other domain controllers on the network. This interruption
creates error conditions that result from various failed operations, such as attempts to replicate
with the disconnected domain controller. As long as you are aware of the issues that
disconnections cause, you can take steps to ensure smooth disconnection and reconnection.
424
Advantages of installing domain controllers before shipping

them to the remote site
The following advantages are associated with installing domain controllers before you ship them
to the remote site:
Standardization. The process for installing domain controllers can be automated and
standardized in the hub or staging site, with the one additional step of packing and shipping
the domain controller. If you follow the instructions in this guide for safe disconnection and
reconnection, restarting the domain controller in the remote site is all that is required.
Branch site personnel. The requirement for personnel with Domain Admins credentials is
limited to the hub site.
Issues with installing domain controllers before shipping them

to the remote site
The following issues are associated with installing domain controllers and then disconnecting
them from the network while they are shipped to the remote site:
Disconnection error conditions. After disconnection, online domain controllers in the

domain continue to attempt replication with the disconnected domain controller, causing
AD DS and SYSVOL replication errors to be generated for as long as the domain controller is
disconnected.
Additional preparation. Additional preparation is required to ensure smooth reconnection:
Preparing for the nonauthoritative restart of SYSVOL. To avoid full replication of

SYSVOL, you can take steps to ensure that only SYSVOL updates are replicated when
the domain controller starts in the branch site.
Ensuring an adequate tombstone lifetime to avoid the possibility of objects remaining on

the domain controller that have been permanently deleted from the directory on all other
domain controllers. The tombstone lifetime is a forest-wide setting that determines how
long an object deletion persists in the directory.
Protection of existing accounts and metadata. You must ensure that computer accounts
and metadata for the domain controller are not deleted or improperly modified while the
domain controller is disconnected.
Risk of lingering objects. A lingering object is an object that remains on a disconnected

domain controller after the object has been permanently deleted from AD DS on all
connected domain controllers. Deletion updates are replicated as tombstone objects. These
objects have a limited lifetime in AD DS, which is defined by the tombstone lifetime. After a
tombstone is permanently removed from Active Directory, replication of the deletion that it
represented is no longer possible. Therefore, if you restart a domain controller on which such
an object remains, replication does not recognize that object as a deleted object, and the
object remains in AD DS on only the reconnected domain controller and nowhere else. If you
plan to disconnect a domain controller for longer than the period of time that a domain
controller keeps track of object deletions (the tombstone lifetime), you must take additional
steps to ensure directory consistency.
425
Caution
The default value for the tombstone lifetime is 180 days. In this case, the risk is
remote if the tombstone lifetime is not changed. However, because the tombstone
lifetime value can be changed administratively and because the risk has such
significant consequences, you should always check the tombstone lifetime setting.
For more information about lingering objects and their causes and effects, see Fixing
Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
Maintaining directory consistency when you disconnect a

domain controller
Maintaining consistency of Active Directory data involves several related issues. Review the
following known issues before you disconnect an installed domain controller:
Protection against lingering object replication
Availability of operations master roles in the domain and forest
Up to dateness of Active Directory replication at the time of disconnection
SYSVOL consistency at reconnection
For procedures to ensure that all of these issues are resolved, see the following topics:
Protection against lingering object replication

Domain controllers that have not performed inbound replication in the number of days equal to
the previous tombstone lifetime are vulnerable to retaining lingering objects. If a domain controller
that has one or more lingering objects is reconnected to the replication topology and a lingering
object is subsequently updated on that domain controller, the object might be recreated in AD DS,
depending on how the strict replication consistency registry setting is configured.
A lingering object is made known to the replication system only if it is updated on the domain
controller that stores it. In this case, the source domain controller attempts replication of an
update to an object that the destination does not store. The strict replication consistency
registry entry (type REG_DWORD) in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters)
determines whether replication is allowed to proceed if the domain controller receives a request
for an update to an object that it does not have.
The value in the strict replication consistency registry entry determines whether replication
proceeds or is stopped, as follows:
1 (enabled): Inbound replication of the specified directory partition from the source is stopped
on the destination domain controller. Replication of the directory partition is stopped on both
the source and destination domain controllers.
426
0 (disabled): The destination requests the full object from the source domain controller, and
the destination domain controller reanimates a full copy of an object that it has previously
deleted and permanently removed through garbage collection.
The default value of the strict replication consistency registry entry is 1 on domain controllers
that are running Windows Server 2003, Windows Server 2003 R2, and Windows Server 2008. If
you are in doubt as to whether strict replication consistency is in effect, you can use the
Repadmin command-line tool to set replication consistency to Strict for all domain controllers in
the forest. If you have domain controllers that are running Windows Server 2000, update these
domain controllers to Windows Server 2008.
Availability of operations masters

If you disconnect a domain controller from the network, you must ensure that it is not holding any
operations master roles for the domain or forest. Check the domain controller for any operations
master roles and, if you find any, transfer the roles before you disconnect the domain controller.
Up to dateness of active directory replication

Ensure that a domain controller is updated before you disconnect it. Immediately before you
disconnect the domain controller, force replication with all replication partners and verify that each
directory partition replicates to the domain controller that you are disconnecting. If replication of
any directory partition does not succeed, resolve the replication problem before you disconnect
the domain controller. By ensuring that replication is up to date, you can maximize the possible
safe disconnection period, which cannot exceed the tombstone lifetime for the forest.
SYSVOL consistency
When you use DFS Replication for SYSVOL replication, when you restart the domain controller in
the new site DFS Replication updates SYSVOL by processing the latest changes from the source
domain controller. To ensure that SYSVOL is updated as quickly as possible, time the restart of
the domain controller with the intersite replication schedule.
When you use FRS for SYSVOL replication, in addition to timing restart according to the
replication schedule preparation might be necessary to avoid an extended period of latency when
SYSVOL is updated. When you restart a domain controller without this preparation, FRS
reconciles and processes all deletions and modifications that took place from the time of the last
SYSVOL update to the time that the domain controller is restarted in the new site. If you have a
large SYSVOL, you can avoid this extra processing and replication time by preparing the domain
controller for nonauthoritative SYSVOL restore before you ship the domain controller. For
information about preparing the domain controller for nonauthoritative SYSVOL restore, see
Prepare a domain controller for nonauthoritative SYSVOL restart (http://go.microsoft.com/fwlink/?
LinkID=122831).
See Also
427

Preparing a Server Computer for Shipping

and Installation from Media
The specific guidelines for installing Active Directory Domain Services (AD DS) from installation
media are provided in the topic Installing an Additional Domain Controller by Using IFM. Be sure
to read that topic before you perform the procedures that are specified in this section.
To prepare for an IFM installation, perform the following tasks:
Determine the type of domain controller that you want to install. Identify a domain controller
that is suitable for creating the media according to whether you are creating an additional
domain controller that is a global catalog server, a Domain Name System (DNS) server, both,
or neither. You must create the installation media on the same type of domain controller that
you want to create.
Determine whether to create the installation media in a shared folder on the computer that will
be installed or use removable media to ship the installation media separately from the
computer. If you will create the media in a shared folder on the installation server, do the
following:
Determine the volume on which to create the media. See the criteria in Determine the
volume for installation media in this topic.
Create a shared folder on the server and map a network drive to the folder on the domain
controller that you are using to create the media.
Install the operating system on the server computer. This task is best performed in the hub
site where administrative personnel are available.
Enable Remote Desktop on the server before you ship it.
If you want to include application directory partitions on the domain controller, prepare an
answer file that contains the location of the installation media and the application directory
partitions.
Determine the volume on which to store the installation media on the installation server. This
location affects SYSVOL replication after the installation of AD DS.
Determining the volume for installation media

The volume on which you store the installation media has implications for SYSVOL files. If you
plan to perform additional, preliminary procedures to ensure that the installation media is the
source for SYSVOL on the installation server, the installation media must be stored on the same
volume that you specify during Active Directory installation to host the SYSVOL tree. If you do not
store the installation media on the volume where SYSVOL is to be hosted, SYSVOL is replicated
428
to the new domain controller, regardless of whether you perform the additional, preliminary
procedures.
Use the following references for information about ensuring that SYSVOL is not replicated during
IFM:
For information about how to ensure that the installation media is used as the source for
SYSVOL when you are using FRS to replicate SYSVOL, see "Seeding the SYSVOL tree from
restored files during IFM promotion" in article 311078 in the Microsoft Knowledge Base
For information about how to ensure that the installation media is used as the source for
SYSVOL when you are using Distributed File System (DFS) Replication to replicate SYSVOL,
see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=120840).
To assess the effect of SYSVOL replication, as opposed to additional configuration that is

required to ensure that the installation media is used as the source for SYSVOL, test both
processes in a lab environment that mirrors your production environment in terms of wide area
network (WAN) speed and replication latency.
Note
We recommend that you deploy at least two domain controllers in each domain for the
purposes of redundancy and failover.
Enabling Remote Desktop

You can use Remote Desktop to connect to the domain controller and manage it remotely.
Remote Desktop is disabled by default in Windows Server 2008. To install AD DS, you must have
Domain Admins credentials in the domain into which you are adding the domain controller. This
level of service administration may not be available in the remote site. In any case, you will
probably want to be able to install and manage the domain controller from the hub site.
Including application directory partitions

If you want application directory partitions to be included in the installation, you must use an
answer file to perform the IFM installation and include the /ApplicationPartitionsToReplicate
parameter in the answer file. When you perform an unattended installation, Dcpromo uses the
answer file for installation instructions, including the location of installation media and application
directory partitions.
Task requirements
The following tools are required to complete this task:
Ntdsutil.exe
System Control Panel
Dcpromo.exe

429
1. Create Installation Media by Using Ntdsutil. Before you perform this procedure, see Installing
an Additional Domain Controller by Using IFM.
Perform this procedure on a domain controller that is the type of domain controller that you
want to create (for example, a global catalog server or a DNS server). Specify removable
media or a shared folder on the installation server as the location for the installation media.
2. Enable Remote Desktop on the installation server.
3. Ship the installation server and any prepared removable media and answer file to the remote
site. Ship these items separately and securely.
When the server is running in the remote site, install the domain controller as follows:
1. Create a Remote Desktop Connection to the remote server.
2. Install an Additional Domain Controller by Using Installation Media. When the domain
controller restarts after installation, the Remote Desktop Connection is dropped. After the
installed domain controller restarts, you must reconnect by using Remote Desktop
Connection.
See Also

You can use this procedure to enable Remote Desktop on the server that you are installing as a
domain controller so that service administrators can manage the domain controller remotely.
Remote Desktop is disabled by default in Windows Server 2008.
You can enable Remote Desktop on the Windows Server 2008 server directly, or you can enable
it remotely from another server or workstation computer.
Membership in local Administrators, or equivalent, is the minimum required to complete these
procedures if Active Directory Domain Services (AD DS) is not installed. Membership in Domain
Admins, or equivalent, is the minimum required to complete this procedure if AD DS is installed.
To enable Remote Desktop locally by using Server Manager
1. Open Server Manager. To open Server Manager, click Start, point to Administrative
Tools, and then click Server Manager.
2. In Computer Information, click Configure Remote Desktop.
3. In the System Properties dialog box, under Remote Desktop, click one of the following
options:
Allow connections from computers running any version of Remote Desktop

(less secure). Use this option if you do not know the version of Remote Desktop
430
Connection that will be used to connect to this server.
Allow connections only from computers running Remote Desktop with Network
Level Authentication (more secure). Use this option if you know that the users who
will connect to this server are running Windows Vista or Windows Server 2008.
4. Review the information in the Remote Desktop dialog box, and then click OK twice.
To enable Remote Desktop remotely by using the registry
1. On any computer that is running a version of Windows Server 2003,
Windows Server 2003 R2, Windows Server 2008, Windows XP Professional, or
Windows Vista, open Regedit as an administrator. To open Regedit as an administrator,
click Start, and then, in Start Search, type regedit. At the top of the Start menu, rightclick regedit, and then click Run as administrator. In the User Account Control dialog
box, provide Domain Admins credentials, and then click OK.
2. On the File menu, click Connect Network Registry.
3. In the Select Computer dialog box, under Enter the object name to select, type the
computer name, and then click Check Names.
4. After the computer name resolves, click OK.
5. In the computer node that appears in the Registry Editor, navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server.
6. In the console tree, click Terminal Server, and then, in the details pane, double-click
fDenyTSConnections.
7. In the Edit DWORD Value box, in Value data, type 0, and then click OK.
This value enables connections at the level that allows connections from computers
running any version of Remote Desktop.
8. To implement the change, restart the server remotely, as follows:
Open a Command Prompt as an administrator: On the Start menu, right-click

Command Prompt, and then click Run as administrator. In the User Account
Control dialog box, provide Domain Admins credentials, and then click OK.
shutdown /m \\<DomainControllerName> /r
Value
Description
/m \\<DomainControllerName>
The name of the computer to be shut

down or restarted.
/r
Shuts down and then restarts the

computer.
431

If Remote Desktop is enabled on a server, you can use this procedure to create a new Remote
Desktop Connection to connect to the server and manage it remotely. Remote Desktop is
disabled by default in Windows Server 2003, Windows Server 2003 R2, and Windows
Server 2008 operating systems.
Membership in Remote Desktop Users, or equivalent, is the minimum required to complete this
procedure. If the remote computer is a domain controller, you must have the Allow Logon
Locally right applied in the Default Domain Controllers Policy. Members of Account Operators,
and Server Operators have the user right to log on locally to a domain controller by default.
To create a new Remote Desktop Connection
1. On the Start menu, point to Programs or All Programs, click Accessories, and then
click Remote Desktop Connection.
2. In Computer, type a computer name or IP address, and then click Connect.
3. In the Windows Security dialog box, type your password, and then click OK. If you are
not logged on with an account that is a member of the Remote Desktop Users, or
equivalent, click Use another account, and then provide credentials for the appropriate
account.
See Also

Using Installation Media
You can use this procedure to install Active Directory Domain Services (AD DS) from media. You
can use the install from media (IFM) method to create an additional domain controller in an
existing domain.
When you create an additional domain controller in the domain, you can specify sourcing the
installation from the shared folder or removable media where you created the installation media
by using one of the following methods:
Windows interface: Provide the location on the Install from Media page in the
Unattended installation: Use the /ReplicationSourcePath parameter in the answer file for an
unattended installation.
432
Command line: Use the /ReplicationSourcePath unattend parameter at the command line.
Membership in the Domain Admins group in the domain into which you are installing the
additional domain controller, or the equivalent, is the minimum required to complete this
To install AD DS from IFM media by using the Windows interface
1. Use the procedure Install an Additional Domain Controller by Using the Windows
Interface. In step 8, select Use advanced mode installation.
2. In step 15, select the install from media option and provide the location of the installation
media.
3. Complete the remaining pages of the Active Directory Domain Services Installation
Wizard.
4. After the installation operation completes successfully and the computer is restarted,
remove the folder that contains the IFM media from the local disk.
To install AD DS from IFM media by using an answer file
1. Create an answer file by using one of the following methods:
During the procedure Install an Additional Domain Controller by Using the Windows
Interface, select the Export settings option to save the installation settings to a file.
This file is an answer file that you can use to install an additional domain controller in
the same domain.
Use the procedure Create an Answer File for Unattended Domain Controller
Installation to create an answer file. Include the /ReplicationSourcePath parameter
to specify the location of the IFM media.
2. Use the procedure Install an Additional Domain Controller by Using an Answer File to
install AD DS.
To install AD DS from IFM media by using unattend parameters from the command line
1. Use the procedure Install an Additional Domain Controller by Using Unattend Parameters
from the Command Line to install AD DS.
2. During the procedure, use the /ReplicationSourcePath parameter to specify the location
of the IFM media.
See Also
433
Preparing an Existing Domain Controller for

Shipping and Long-Term Disconnection
When you ship a domain controller to a remote site, you must disconnect it from the network and,
consequently, from the replication topology. If a domain controller must be separated from the
replication topology for a period of time that might be longer than a tombstone lifetime, you must
take preliminary steps to ensure a smooth reconnection. Otherwise, it is possible that a long-term
disconnection can result in a deleted object being reintroduced into the directory. Such deleted
objects, when they are retained on a domain controller that has been disconnected for a period
that is longer than a tombstone lifetime, are called "lingering objects." Lingering objects that are
security principals, such as users or groups, can cause problems with Active Directory searches
and e-mail delivery. Lingering objects can also jeopardize security if a user is allowed access to a
resource by virtue of membership in a group that has been deleted. For more information about
lingering objects, see "Maintaining Directory Consistency When Disconnecting a Domain
Controller" in Known Issues for Adding Domain Controllers in Remote Sites.
By taking preliminary precautions, you can ensure that long-term disconnections do not result in
directory inconsistency from lingering objects.
Task requirements
ADSI Edit
Ntdsutil.exe
Active Directory Schema
Repadmin.exe

1. Determine the anticipated length of the disconnection.
2. Determine the Tombstone Lifetime for the Forest.
3. Determine the maximum safe-disconnection period by subtracting a generous estimate of the
end-to-end replication latency from the tombstone lifetime. Either find the latency estimate in
the design documentation for your deployment or request the information from a member of
your design or deployment team.
If the anticipated time of disconnection exceeds the maximum safedisconnection period,

make a decision about whether to extend the tombstone lifetime. To change the
tombstone lifetime, see Determine the Tombstone Lifetime for the Forest and change the
value in the tombstoneLifetime attribute.
If the estimated time of disconnection does not exceed the maximum safe disconnection
time, proceed with preparations for disconnection.
4. View the Current Operations Master Role Holders to determine whether the domain controller
is an operations master role holder.
434
5. Transfer the Domain-Level Operations Master Roles, if appropriate.

6. Transfer the Schema Master, if appropriate.
7. Transfer the Domain Naming Master, if appropriate.
8. If you use File Replication Service (FRS) to replicate SYSVOL, you can decrease the time
required to update SYSVOL when the domain controller is restarted by performing a
preliminary registry update on the server. For instructions, see Prepare a domain controller
for nonauthoritative SYSVOL restart (http://go.microsoft.com/fwlink/?LinkID=122831). This
procedure is not necessary if you use Distributed File System (DFS) Replication.
9. Enable Strict Replication Consistency, if necessary. If strict replication consistency is not
enabled on the domain controller that you are disconnecting, use this command-line
procedure to enable strict replication consistency on specific domain controllers or on all
domain controllers in the forest.
10. Synchronize Replication with All Partners. Update the domain controller with the latest
changes just before you disconnect it.
11. Verify Successful Replication to a Domain Controller for the domain controller that you are
disconnecting.
12. Label the domain controller with the date and time of disconnection and the maximum safedisconnection period.
See Also
Determine the Tombstone Lifetime for the

Forest
The tombstone lifetime in an Active Directory forest determines how long a deleted object (called
a tombstone) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is
determined by the value of the tombstoneLifetime attribute on the Directory Service object in the
configuration directory partition.
You can use this procedure to determine the tombstone lifetime for the forest.
435
To determine the tombstone lifetime for the forest

2. In ADSI Edit, right-click ADSI Edit, and then click Connect to.
3. For Connection Point, click Select a well known Naming Context, and then click
Configuration.
4. If you want to connect to a different domain controller, for Computer, click Select or type
a domain or server: (Server | Domain [:port]). Provide the server name or the domain
name and Lightweight Directory Access Protocol (LDAP) port (389), and then click OK.
5. Double-click Configuration, CN=Configuration,DC=ForestRootDomainName,
CN=Services, and CN=Windows NT.
6. Right-click CN=Directory Service, and then click Properties.
7. In the Attribute column, click tombstoneLifetime.
8. Note the value in the Value column. If the value is <not set>, the default value is in effect
as follows:
On a domain controller in a forest that was created on a domain controller running

Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service
Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008, the default value
is 180 days.

Windows 2000 Server or Windows Server 2003, the default value is 60 days.
Enable Strict Replication Consistency

You can use this procedure to ensure that strict replication consistency is enabled in the forest.
This setting prohibits replication of outdated Active Directory objects. If you disconnect a domain
controller from the replication topology for an extended period and then reconnect it, this setting
ensures that no outdated objects are reintroduced into Active Directory Domain Services
(AD DS).
To determine whether strict replication consistency is enabled, use the regedit command to view
the registry on a domain controller. The setting for replication consistency is stored in the registry
in the Strict Replication Consistency entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
Values for this entry are as follows:
Value: 1 (0 to disable)
Default: 1 (enabled) in a new Windows Server 2003 or Windows Server 2008 forest;
otherwise 0.
Data type: REG_DWORD
436
If the value is 0, use the following procedure to change the value to 1 on a specific domain
controller or on all domain controllers.
Membership in the Domain Admins group in the domain, or equivalent, is the minimum required
to complete this procedure on a single domain controller. Membership in the Enterprise
Admins group in the forest, or equivalent, is the minimum required to complete this procedure on
all domain controllers. Review details about using the appropriate accounts and group
To enable strict replication consistency
1. Open a command prompt, type the following command, and then press ENTER:
repadmin /regkey <DC_LIST> {+|-}<key>
Value
Description
repadmin /regkey
Enables and disables the values for the

following two registry entries under
HKEY_LOCAL_MACHINE\SYSTEM\Current
Control Set\Services\NTDS\Parameters:
Strict replication consistency
Allow replication with divergent and

corrupt partner
<DC_LIST>
The name of a single domain controller. Or, use

* to apply the change to all domain controllers
in the forest. For the domain controller name,
you can use the Domain Name System (DNS)
name, the distinguished name of the domain
controller computer object, or the distinguished
name of the domain controller server object.
{+|-}<key>
+ to enable and - to disable, and key is strict.

For example, +strict enables strict replication
consistency; -strict disables it.
2. Repeat step 1 for every domain controller on which you want to enable strict replication
consistency.
Note
For more naming options and information about the syntax of the
the command prompt, type repadmin /listhelp.
<DC_LIST>
parameter, at
437

controller.
Value
Description
repadmin /syncall


partners.
/e
/d

names in messages.
/A

/P

server.
/q

messages.
corrected.
See Also
438
Reconnecting a Domain Controller After a

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

If you plan appropriately for disconnecting and reconnecting domain controllers, no domain
controller will be disconnected from the replication topology for longer than a tombstone lifetime.
However, if unexpected events result in a domain controller becoming outdated, you can perform
a procedure to safely remove lingering objects. If the disconnected domain controller is running
Windows Server 2003 or Windows Server 2008 and an authoritative domain controller running
Windows Server 2003 or Windows Server 2008 is available in this site or a neighboring site,
reconnect the domain controller and immediately follow the instructions in Use Repadmin to
Remove Lingering Objects.
The following conditions require using a different method of remove lingering objects:
The disconnected domain controller is running Windows Server 2003 or

Windows Server 2008, but no other authoritative domain controller running
Windows Server 2003 or Windows Server 2008 is available in the domain: Reconnect the
domain controller, and follow the instructions in article 314282 in the Microsoft Knowledge
Base (http://go.microsoft.com/fwlink/?LinkId=119208).
The disconnected domain controller is running Windows 2000 Server, and no other domain
controller is available in the domain: If you want to recover the domain, reconnect the domain
controller, and follow the instructions in article 314282 in the Microsoft Knowledge Base
The disconnected domain controller is running Windows 2000 Server, and another domain
controller is available in the domain: Do not reconnect the domain controller. Instead, force
Active Directory removal on the disconnected domain controller, perform metadata cleanup,
and then reinstall Active Directory. To complete these tasks, follow the instructions in Forcing
the Removal of a Domain Controller and Installing a Domain Controller in an Existing
Domain.
Updating SYSVOL
To update SYSVOL as soon as possible after you reconnect a domain controller, plan the time
that you restart the domain controller to optimize the replication schedule, as follows:
439
If the closest replication partner for the domain is in a different site, view site link properties to
determine the replication schedule, and then restart the domain controller as soon as
possible after replication is scheduled to start.
If a replication partner for the domain is available within the site, verify replication success on
that partner before you restart the domain controller.
Important
If you use File Replication Service (FRS) to replicate SYSVOL, the recommended
practice to reduce the time required to update SYSVOL is to modify the registry before
you disconnect the domain controller so that SYSVOL is updated with only the latest file
changes when you restart the domain controller. For information about preparing for
SYSVOL replication when using FRS, see Preparing an Existing Domain Controller for
Shipping and Long-Term Disconnection (http://go.microsoft.com/fwlink/?LinkId=122834).
Task requirements
ADSI Edit
Repadmin.exe

1. Determine the Tombstone Lifetime for the Forest.
2. Determine whether the maximum safe disconnection time has been exceeded. The maximum
safe disconnection time should have been established at the time of disconnection, as
follows:
Subtract a generous estimate of the amount of time for end-to-end replication latency from
the tombstone lifetime. Either find the latency estimate in the design documentation for your
deployment or request the information from a member of your design or deployment team.
3. If the maximum safe disconnection time has not been exceeded, proceed with the
reconnection process as follows:

If the server object for the domain controller is still in the site where the domain controller
was installed, move the server object to the site in which you are reconnecting the
domain controller.
If the site in which you are reconnecting the domain controller has one or more other
domain controllers that are authoritative for the domain, start the domain controller
anytime.
If the site in which you are reconnecting the domain controller has no other domain
controllers that are authoritative for the domain, proceed as follows:
Determine When Intersite Replication Is Scheduled to Begin by viewing the replication
properties on the site link that connects this site to the next closest site that includes a
domain controller that is authoritative for this domain.
As soon as possible after the next replication cycle begins, start the domain controller.
440
If the maximum safe disconnection time has been exceeded, proceed in the appropriate
manner according to the operating system, as described in "Reconnecting an Outdated
Domain Controller" earlier in this topic.
After replication is complete, verify replication of the domain, configuration, and schema
directory partitions. If the domain controller is a global catalog server, verify replication of all
domain directory partitions. If the domain controller is a Domain Name System (DNS) server,
verify replication of the domain and forest DNS application directory partitions.
See Also
Determine the Tombstone Lifetime for the

Forest
The tombstone lifetime in an Active Directory forest determines how long a deleted object (called
a tombstone) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is
determined by the value of the tombstoneLifetime attribute on the Directory Service object in the
configuration directory partition.
You can use this procedure to determine the tombstone lifetime for the forest.
To determine the tombstone lifetime for the forest
2. In ADSI Edit, right-click ADSI Edit, and then click Connect to.
3. For Connection Point, click Select a well known Naming Context, and then click
Configuration.
4. If you want to connect to a different domain controller, for Computer, click Select or type
a domain or server: (Server | Domain [:port]). Provide the server name or the domain
name and Lightweight Directory Access Protocol (LDAP) port (389), and then click OK.
5. Double-click Configuration, CN=Configuration,DC=ForestRootDomainName,
CN=Services, and CN=Windows NT.
6. Right-click CN=Directory Service, and then click Properties.
7. In the Attribute column, click tombstoneLifetime.
8. Note the value in the Value column. If the value is <not set>, the default value is in effect
as follows:
441

Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service
Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008, the default value
is 180 days.

Windows 2000 Server or Windows Server 2003, the default value is 60 days.

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.
To move a server object to a new site
2. In the console tree, expand Sites and the site in which the server object resides.
3. Expand Servers to display the domain controllers that are currently configured for that
site.
4. Right-click the server object that you want to move, and then click Move.
5. In Site Name, click the destination site, and then click OK.
6. Expand the site object to which you moved the server, and then expand the Servers
container.
7. Verify that an object for the server that you moved exists.
8. Expand the server object, and verify that an NTDS Settings object exists.
Within an hour, the Net Logon service on the domain controller registers the new site information
in Domain Name System (DNS). Wait an hour, and then open Event Viewer and connect to the
domain controller whose server object you moved. Review the System log for NETLOGON errors
regarding registration of service (SRV) resource records in DNS that have occurred within the last
hour. The absence of errors indicates that the Net Logon service has updated DNS with site442
specific service (SRV) resource records. NETLOGON Event ID 5774 indicates that the dynamic
registration of DNS resource records has failed. If this error occurs, contact a supervisor and
pursue DNS troubleshooting.
See Also
Verify That an IP Address Maps to a Subnet and Determine the Site Association
Determine When Intersite Replication Is

Scheduled to Begin
Before you restart a domain controller that has been disconnected and shipped to a branch site, if
the domain controller is the only domain controller for the domain in the site, the domain controller
must be updated from the hub site. You can minimize the time that the domain controller is out of
synchronization with domain controllers in the hub site by timing the restart to coincide with
intersite replication. You can use this procedure to determine when intersite replication between
sites is scheduled to begin.
To determine when intersite replication is scheduled to begin
1. Open Active Directory Sites and Services: Click Start, point to Administrative Tools,
and then click Active Directory Sites and Services.
2. In the console tree, double-click the Sites container, double-click the Inter-Site
Transports container, and then click the IP container.
3. In the details pane, right-click the site link object for which you want to view the schedule,
4. In the SiteLinkNameProperties dialog box, click Change Schedule. Note the block of
days and hours during which replication is allowed (Replication Available), and then
click OK or Cancel.
5. In Replicate every _____ minutes, note the number of minutes for the intervals at which
replication polling takes place during an open schedule window, and then click OK.
Use Repadmin to Remove Lingering Objects

You can use the Repadmin tool to remove lingering objects when you reconnect a domain
controller that has been offline for longer than a tombstone lifetime and you want to ensure that
443
lingering objects do not exist or, if they do, that they are removed before they are replicated. You
can also use this procedure when event ID 1388 or event ID 1988 is logged on a domain
controller. In this case, the information that you need to perform the procedure is provided in the
event. For information about removing lingering objects when event ID 1388 or event ID 1988 has
been logged, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
If you are running the procedure without having received Event ID 1388 or Event ID 1988, you
must gather the following information before you begin the procedure:
The name of the server that has or might have lingering objects. This name can be the
Domain Name System (DNS) name, NetBIOS name, or distinguished name of the domain
controller.
The globally unique identifier (GUID) of the NTDS Settings object of a domain controller that
is authoritative for the domain of the domain controller from which you want to remove
lingering objects. This domain controller is the source domain controller. The source domain
controller and the domain controller from which you want to remove lingering objects must be
running a version of either Windows Server 2003 or Windows Server 2008. If either domain
controller is running Windows 2000 Server, follow the instructions in article 314282 in the
Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=37924).
Use the following procedure to determine the GUID of a domain controller.

To determine the GUID of a domain controller
repadmin /showrepl <DomainControllerName>
Where <DomainControllerName> is the NetBIOS name of the domain controller whose

GUID you want to determine.
3. In the top portion of the output, note the value in
DC object GUID:
Use the following procedure to remove lingering objects by using Repadmin.

To use Repadmin to remove lingering objects
repadmin /removelingeringobjects <ServerName ServerGUID DirectoryPartition>
/advisory_mode
444
Value
Description
repadmin
Removes objects that have been deleted and permanently
/removelingeringobjec removed from replication partners but remain on this domain
ts
controller.
<ServerName>
The DNS name or the distinguished name of the domain

controller that has or might have lingering objects.
<ServerGUID>
The GUID of a domain controller that has an up-to-date,

writable replica of the directory partition
<DirectoryPartition>
The distinguished name of the domain directory partition that

might have lingering objects. For example,
DC=RegionalDomainName,DC=ForestRootDomainName,DC=
com. Also run the command against the configuration directory
partition
(CN=configuration,DC=ForestRootDomainName,DC=com), the
schema directory partition
(CN=schema,CN=configuration,DC=ForestRootDomainName),
and any application directory partitions that are hosted on the
domain controller that you are checking for lingering objects.
/advisory_mode logs the lingering objects that will be removed so that you can review
them, but it does not remove them.
2. If lingering objects are found, repeat step 1 without /advisory_mode to delete the
identified lingering objects from the directory partition.
3. Repeat steps 1 and 2 for every domain controller that might have lingering objects.
Note
The ServerName parameter uses the DC_LIST syntax for repadmin, which allows the
use of * for all domain controllers in the forest and gc: for all global catalog servers in the
forest. To see the DC_LIST syntax, at a command prompt, type repadmin /listhelp, and
then press ENTER.

Controller
445
Note
domain.
446
Value
Description
repadmin /showrepl

<servername>

controller.
/u:

AD DS.
<domainname>

<username>

that domain.
/pw:*

ENTER.
then press ENTER.
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
447
readability.
3. Open Excel.
Or
Custom Filter.
controllers.
448
Renaming a Domain Controller

You can use the Netdom.exe command-line tool to rename a domain controller if the domain
functional level is Windows Server 2003 or Windows Server 2008. At these domain functional
levels, Netdom provides the required preparation for Domain Name System (DNS) and service
recognition of the new domain controller name. You can also use the System Properties user
interface (UI), which does not require a domain functional level and does not provide the same
preparation but which relies solely on replication to update the domain controller DNS name and
service principal name (SPN). This method can result in a longer delay before clients can use the
renamed domain controller.
The ability to rename domain controllers provides you with the flexibility to:
Restructure your network for organizational and business needs.
Make management and administrative control easier.
Renaming a domain controller is a common operation in many organizations, and it usually

occurs when:
New hardware is purchased to replace an existing domain controller.
Domain controllers are decommissioned or promoted and renamed to maintain a naming

convention.
Domain controllers are moved or placed in sites.

Note
It is important to note that domain controller names have a primary impact on
administration, rather than client access. Renaming a domain controller is an optional
exercise, and the effects of renaming a domain controller should be well understood
before the domain controller is renamed.
Although you can use System Properties to rename a domain controller (as you can for any
computer), Active Directory and DNS replication latency might temporarily prevent clients from
locating or authenticating (or both) to the renamed domain controller. To avoid this delay, you can
use the Netdom command-line tool to rename a domain controller.
Task requirements
System Properties or Netdom.exe
Ldp.exe or ADSI Edit
If you want to use Netdom, the domain functional level must be set to Windows Server 2003 or
To complete this task, use one of the following two sets of procedures:
1. Rename a Domain Controller Using System Properties
2. Update the FRS or DFS Replication Member Object
Or
1. Rename a Domain Controller Using Netdom
449
2. Update the FRS or DFS Replication Member Object
Rename a Domain Controller Using System

Properties
You can use this procedure to rename a domain controller by using the System Properties
graphical user interface (GUI).
To rename a domain controller using System Properties
1. In Server Manager, click Change System Properties.
2. On the Computer Name tab, click Change.
3. Click OK to acknowledge that renaming the domain controller may cause it to become
temporarily unavailable to users and computers.
Note
Renaming a domain controller in this way may result in Active Directory
replication latency, making it more difficult for clients to locate or authenticate the
domain controller under its new name.
4. Under Computer Name, type the new name, and then click OK.
5. Click OK to close the System Properties dialog box.
6. If you are prompted, provide the user name and password for an account with Domain
Admin or Enterprise Admin credentials.
See Also
Rename a Domain Controller Using Netdom
Rename a Domain Controller Using Netdom

You can use this procedure to rename a domain controller by using the Netdom command-line
tool.
The netdom command updates the Service Principal Name (SPN) attributes in Active Directory
Domain Services (AD DS) for the computer account. This command also registers Domain Name
System (DNS) resource records for the new computer name. The SPN value of the computer
account must be replicated to all domain controllers in the domain, and the DNS resource records
for the new computer name must be distributed to all the authoritative DNS servers for the
450
domain name. If the updates and registrations have not occurred before the removal of the old
computer name, some clients might not be able to locate this computer using the new name or
the old name.
To rename a domain controller using Netdom
2. At the command prompt, type the following command to add the new domain controller
name, and then press ENTER:
netdom computername <CurrentComputerName> /add:<NewComputerName>
Value
Description
netdom computername
Manages the primary and alternate

names for a computer.
<CurrentComputerName>
The current, or primary, fully qualified

DNS name of the computer that you are
renaming.
/add:
Specifies that a new alternate DNS name

should be added.
<NewComputerName>
The new fully qualified DNS name for the

computer that you are renaming.
3. Type the following command to designate the new name as the primary computer name,
and then press ENTER:
netdom computername <CurrentComputerName> /makeprimary:<NewComputerName>
451
Value
Description
netdom computername
Manages the primary and alternate names

for a computer.
<CurrentComputerName>
The current, or primary, fully qualified

domain name (FQDN)of the computer that
you are renaming.
/makeprimary:
Specifies that an existing alternate name

should be made into the primary name.
<NewComputerName>
The new name for the computer. The

NewComputerName must be a FQDN.
The primary DNS suffix that is specified in
the FQDN for NewComputerName must
be the same as the primary DNS suffix of
CurrentComputerName, or it must match
the DNS name of the Active Directory
domain that is hosted by this domain
controller, or it must be contained in the
list of allowed DNS suffixes that is
specified in the msDSAllowedDNSSuffixes attribute of the
domainDns object.
4. Restart the computer.

5. After the computer restarts, open a Command Prompt.
6. At the command prompt, type the following command to remove the old domain controller
name, and then press ENTER:
netdom computername <NewComputerName> /remove:<OldComputerName>
Value
Description
netdom computername
Manages the primary and alternate

names for a computer.
<NewComputerName>
The new FQDN that you added for the

computer in step 2.
/remove:
Specifies that an existing alternate name

should be removed.
<OldComputerName>
The old FQDN of the renamed computer.
452
See Also
Rename a Domain Controller Using System Properties
Update the FRS or DFS Replication Member

Object
You can use this procedure to update the File Replication Service (FRS) or Distributed File
System (DFS) Replication member object after you rename a domain controller. This object must
be updated with the new domain controller name so that the domain controller can replicate
SYSVOL.
For more information about this procedure, see article 316826 in the Microsoft Knowledge Base
To update the FRS member object
1. On the Start menu, point to Administrative Tools, and then click Active Directory
Users and Computers.
2. On the View menu, click Advanced Features.
3. Expand the domain node, System, File Replication Service, and Domain System
Volume (SYSVOL share). The <DomainControllerName> objects below Domain
System Volume (SYSVOL share) are the FSR Member objects that correspond to
domain controllers in the domain. Find the <DomainControllerName> object that shows
the old name of the domain controller.
4. Right-click the FRS Member object for the old name of the domain controller, and then
click Rename.
5. Type the new name of the domain controller.
6. To verify the name change, open ADSI Edit: On the Start menu, point to Administrative
Tools, and then click ADSI Edit.
View the fRSMemberReference attribute of the object CN=Domain System Volume
(SYSVOL share),CN=NTFRS Subscriptions,CN=<DomainControllerName>,OU=Domain
Controllers,DC=<DomainName> and confirm that the value in
CN=<DomainControllerName> is the new name.
To update the DFS Replication member object
1. On the Start menu, point to Administrative Tools, and then click Active Directory
Users and Computers.
2. On the View menu, click Advanced Features.
453
3. Expand the domain node, System, DFSR-GlobalSettings, Domain System Volume,

and Topology. The <DomainControllerName> objects below Domain System Volume
are the msDFSR-Member objects that correspond to domain controllers in the domain.
Find the <DomainControllerName> object that shows the old name of the domain
controller.
4. Right-click the msDFSR-Member object for the old name of the domain controller, and
then click Rename.
5. Type the new name of the domain controller.
6. To verify the name change, open ADSI Edit: On the Start menu, point to Administrative
Tools, and then click ADSI Edit.
View the msDFSR-MemberReference attribute of the object CN=Domain System
Volume,CN=DFSR-LocalSettings,CN=<DomainControllerName>,OU=Domain
Controllers,DC=<DomainName> and confirm that the value in
CN=<DomainControllerName> is the new name.

Decommissioning a domain controller removes all Active Directory components and related
components and returns the domain controller to a member server role.
This task provides procedures for removing a domain controller from a domain that has other
domain controllers.
Removing a domain or a forest

The following topics contain information about removing a domain or a forest:
To remove a domain, see Removing the Last Windows Server 2008 Domain Controller in a
Domain (http://go.microsoft.com/fwlink/?LinkId=93208).
To remove a forest, see Removing the Last Windows Server 2008 Domain Controller in a
Forest (http://go.microsoft.com/fwlink/?LinkId=93209).
Protecting EFS-encrypted files

If the domain controller to be decommissioned hosts any Encrypting File System (EFS)
encrypted files, you must take precautions to protect the private key for the recovery agent for the
local EFS-encrypted documents. This might be lost during Active Directory removal when the
Security Accounts Manager (SAM) is recreated on the computer. In this case, you are unable to
recover encrypted documents on this computer unless you unencrypt all the files and the
recovery agent is changed to an existing domain account before re-encryption. To prevent loss of
the private key, you must back up (export) the recovery agent private key before you
454
decommission the domain controller. After you remove Active Directory Domain Services
(AD DS), import the private key again.
You must be able to ensure that the domain account that is serving as the recovery agent for the
certificate remains the same after you remove AD DS. If you cannot guarantee that the account
will remain the same after the domain controller is decommissioned or if you removed AD DS
without backing up the certificate and you cannot recover EFS-encrypted files, see article 276239
in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=117370).
Task requirements
Dcdiag.exe
Active Directory Schema
Ntdsutil.exe
If you must protect the recovery agent private key for encrypted files, the following additional tool
is required:
Certificates snap-in

The Active Directory Domain Services Installation Wizard requires both TCP/IP connectivity
and Domain Name System (DNS) to locate another domain controller in the domain.
During the removal of AD DS, contact with other domain controllers is required to ensure the
following:
Any unreplicated changes are replicated to another domain controller.
Removal of the domain controller from the directory.
Transfer of any remaining operations master roles.
If the domain controller cannot contact another domain controller during Active Directory
removal, the decommissioning operation fails. As with the installation process, test the
communication infrastructure before you run the installation wizard. Before you remove
AD DS, use the same connectivity tests that you used before you installed AD DS.
2. View the Current Operations Master Role Holders
To avoid problems for client computers in the domain and forest, transfer any operations
master (also known as flexible single master operations or FSMO) roles before you run the
Active Directory Domain Services Installation Wizard to decommission a domain controller so
that you can control the operations master role placement. If you need to transfer any
operations master roles from a domain controller, review all the recommendations for role
placement before you perform the transfer, as described in Introduction to Administering
Operations Master Roles. Identify the domain controllers to which you will transfer each role
before you perform the transfer procedures.
455
Caution
During the decommissioning process, the Active Directory Domain Services
Installation Wizard checks for the presence of operations master roles. If the domain
controller being decommissioned holds any operations master (also known as flexible
single master operations or FSMO) role, the wizard provides a warning and attempts
to transfer the role or roles to another domain controller without any user interaction.
You do not have control over which domain controller receives the operations master
roles that are transferred, and the wizard does not indicate which domain controller
receives them. If the wizard cannot transfer an operations master role, you can
override the warnings and the wizard will continue to uninstall AD DS and leave your
domain or forest without the role. In this case, you must seize the operations master
role to another domain controller.
If the domain controller holds any operations master roles, use the following procedures to
transfer the role or roles:
Transfer the Domain-Level Operations Master Roles
3. Determine Whether a Domain Controller Is a Global Catalog Server
If you remove AD DS from a domain controller that hosts the global catalog, the
Active Directory Domain Services Installation Wizard confirms that you want to continue with
removing AD DS. This confirmation ensures that you are aware that you are removing a
global catalog server from your environment. Do not remove the last global catalog server
from your environment because users cannot log on without an available global catalog
server. If you are not sure, do not proceed with removing AD DS until you know that at least
one other global catalog server is available.
Verify that the operations master role holders are online and responding.
Important
If any verification test fails, do not continue until you determine the problems and
fixthem. If these tests fail, the uninstallation is also likely to fail.
5. If the domain controller hosts encrypted documents, perform the following procedure before
you remove AD DS to ensure that the encrypted files can be recovered after AD DS is
removed:
Back Up A Certificate With Its Private Key (http://go.microsoft.com/fwlink/?LinkId=122856).
6. Removing a Windows Server 2008 Domain Controller from a Domain
You can remove AD DS by using the Windows interface, an answer file, or the command line.
7. If the domain controller hosts encrypted documents and you backed up the certificate and
private key before you removed AD DS, perform the following procedure to import the
certificate to the server again:
Import a Certificate (http://go.microsoft.com/fwlink/?LinkID=108290).
456

9. Delete a Server Object from a Site
Note
You may not want to remove the server object if it hosts something in addition to
AD DS, for example, Microsoft Exchange.
See Also
Introduction to Administering Operations Master Roles
Verify DNS Registration and TCP/IP

Connectivity
You can use the Dcdiag command-line tests in this procedure to verify that a server can
successfully connect to domain controllers in the same site or in the enterprise and to verify that
Domain Name System (DNS) is functioning. By default, all Dcdiag tests verify TCP/IP connectivity
for both IP version 4 (IPv4) and IP version 6 (IPv6).
Note
Dcdiag is installed with Active Directory Domain Services (AD DS) by default. To perform
this test on a server that is not a domain controller, you must install Dcdiag. For
information about installing Dcdiag, see Installing Remote Server Administration Tools for
AD DS.
To verify DNS registration and TCP/IP connectivity
appears, provide Domain Admins credentials, and then click OK.
dcdiag /test:dns
Note
For a more detailed response from this command, add
command.
/v
to the end of the
If the test fails, do not attempt any additional steps until you determine and fix the
problem that prevents proper DNS functionality.
457

Holders
click OK.
3. At the fsmo
maintenance:
4. At the server

<servername>

this menu.
6. At the fsmo
maintenance:
prompt, type select

press ENTER.
quit,
operation target,
and then
role.
ntdsutil:
458

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.
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
command, you can type ? at the Ntdsutil.exe command prompt.
Membership in Schema Admins, or equivalent, is the minimum required to complete this
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.
459

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.
transfer the domain naming operations master role.
Note
command, you can also type ? at the Ntdsutil.exe command prompt.
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.
Change Active Directory Domain Controller.
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.
460
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) snapin, 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.
transfer the operations master role.
To transfer a domain-level operations master role
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.
then click Change Active Directory Domain Controller.
4. In the Name column, click the name of the domain controller to which you want to
transfer the role, and then click OK.
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.
461
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.

object.

Masters
462


properly.
463
Back Up a Certificate With Its Private Key

Certificates are important credentials. Their loss or corruption can cause serious harm. Such
harm can come from delays in authenticating your identity to an inability to retrieve encrypted
data. You can back up certificates to protect them from loss or corruption, or to move them to a
different computer.
Users or local Administrators are the minimum group memberships required to complete this
procedure. Review the details in "Additional considerations" in this topic.
To export a certificate with the private key
1. Open the Certificates snap-in for a user, computer, or service.
2. Do one of the following:
If you are in Logical Certificate Stores view mode, in the console tree, click
Certificates.
If you are in Certificate purpose view mode, in the console tree, click Purpose.
3. In the details pane, click the certificate you want to export.

4. On the Action menu, point to All Tasks, and then click Export.
5. In the Certificate Export Wizard, click Yes, export the private key. (This option will
appear only if the private key is marked as exportable and you have access to the private
key.)
6. Under Export File Format, select one of the available certificate file-format options. Also,
do one or all of the following, if available, and then click Next.
To include all certificates in the certification path, select the Include all certificates
in the certification path if possible check box.
To include all extended properties of the certificate, select Export all extended
properties.
To delete the private key if the export is successful, select the Delete the private key
if the export is successful check box.
7. If required, In Password, type a password to encrypt the private key you are exporting. In
Confirm password, type the same password again, and then click Next.
8. In File name, type a file name and path for the PKCS #12 file that will store the exported
certificate and private key, click Next, and then click Finish.
User certificates can be managed by the user or by an administrator. Certificates issued to a

computer or service can only be managed by an administrator or user who has been given
the appropriate permissions.
To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.
Strong protection (also known as iteration count) is enabled by default in the Certificate
Export Wizard when you export a certificate with its associated private key.
464
Strong protection is not compatible with older applications.
After the Certificate Export Wizard is finished, the certificate will remain in the certificate store
in addition to being in the newly-created file. If you want to remove the certificate from the
certificate store, you will need to delete it.
Removing a Windows Server 2008 Domain

Controller from a Domain
The procedures in this section describe the methods for removing a Windows Server 2008
domain controller from a domain:
Removing a Windows Server 2008 domain controller by using the Windows interface
Removing a Windows Server 2008 domain controller by using an answer file
Removing a Windows Server 2008 domain controller by entering unattended installation

Removing a Windows Server 2008 domain

controller by using the Windows interface
You can use the Active Directory Domain Services Installation Wizard to remove a domain
controller from an existing domain. If the domain controller hosts any Active Directory-integrated
DNS zones, the wizard removes those zones and by default also attempts to remove the DNS
delegations for those zones that point to the domain controller.
To perform this procedure, you must be a member of the Domain Admins group in the domain.
To remove a domain controller by using the Windows interface
1. Click Start, click Run, type dcpromo, and then press ENTER.
2. In the Welcome to the Active Directory Domain Services Installation Wizard page,
click Next.
3. If the domain controller is a global catalog server, a message appears to warn you about
the effect of removing a global catalog server from the environment. Click OK to continue.
4. On the Delete the Domain page, make no selection, and then click Next.
5. If the domain controller has application directory partitions, on the Application Directory
Partitions page, view the application directory partitions in the list, and then remove or
retain application directory partitions, as follows:
If you do not want to retain any application directory partitions that are stored on the
domain controller, click Next.
If you want to retain an application directory partition that an application has created
on the domain controller, use the application that created the partition to remove it,
465
and then click Refresh to update the list.

6. If the Confirm Deletion page appears, select the option to delete all application directory
partitions on the domain controller, and then click Next.
7. On the Remove DNS Delegation page, verify that the Delete the DNS delegations
pointing to this server check box is selected and then click Next.
8. If necessary, enter administrative credentials for the server that hosts the DNS zones that
contain the DNS delegation for this server and then click OK.
9. On the Administrator Password page, type and confirm a secure password for the local
Administrator account, and then click Next.
10. On the Summary page, to save the settings that you selected to an answer file that you
can use to automate subsequent Active Directory Domain Services (AD DS) operations,
click Export settings. Type a name for your answer file, and then click Save. Review
your selections, and then click Next to remove AD DS.
click Finish.
12. You can either select the Reboot on completion check box to have the server restart
automatically or you can restart the server to complete the AD DS removal when you are
prompted to do so.

controller by using an answer file
The answer file that you use to remove a domain controller in a domain where other domain
controllers exist requires only Domain Admin credentials. You can also create the password for
the local Administrator account for the member server. If you do not specify the password in the
answer file, the administrator password is blank.
To perform this procedure, you must be a member of the Domain Admins group in the domain.
To create an answer file for removing a domain controller
1. Open Notepad or any text editor.
2. On the first line, type [DCINSTALL], and then press ENTER.
3. Create the following entries, one entry on each line. For a complete list of parameters for
removing AD DS, see Demotion Operation or type dcpromo /?:Demotion at a command
line.
username=<administrative account in the domain>
userdomain=<domain name of administrative account>
password=<password for the account in UserName>
administratorpassword=<local administrator password for server>
466
removeapplicationpartitions=yes
removeDNSDelegation=yes
DNSDelegationUserName=<DNS server administrative account for the DNS zone that
contains the DNS delegation>
DNSDelegationPassword=<Password for the DNS server administrative account>
4. Save the answer file to the location on the installation server from which it is to be called
by dcpromo, or save the file to a network shared folder or removable media for
distribution.
5. The dcpromo command to use an answer file is the same for both removing and
installing a domain controller. Use the procedure "To install a new domain controller by
using an answer file" to remove the domain controller.

controller by entering unattended installation
The dcpromo command that you use to enter unattended installation parameters at the
command line is the same for both removing and installing a domain controller. Use the
procedure "To install a new domain controller by entering unattended installation parameters at
the command line" to remove the domain controller, but use unattended installation options that
are appropriate for removing a domain controller from an existing domain. For a complete list of
parameters for removing AD DS, see Demotion Operationor type dcpromo /?:Demotion at a
command line.
Import a Certificate
You should only import certificates obtained from trusted sources. Importing an unreliable
certificate could compromise the security of any system component that uses the imported
certificate.
You can import a certificate into any logical or physical store. In most cases, you will import
certificates into the Personal store or the Trusted Root Certification Authorities store, depending
on whether the certificate is intended for you or if it is a root CA certificate.
To import a certificate
1. Open the Certificates snap-in for a user, computer, or service.
2. In the console tree, click the logical store where you want to import the certificate.
3. On the Action menu, point to All Tasks and then click Import to start the Certificate
467
Import Wizard.
4. Type the file name containing the certificate to be imported. (You can also click Browse
and navigate to the file.)
5. If it is a PKCS #12 file, do the following:
Type the password used to encrypt the private key.
(Optional) If you want to be able to use strong private key protection, select the
Enable strong private key protection check box.
(Optional) If you want to back up or transport your keys at a later time, select the
Mark key as exportable check box.
If the certificate should be automatically placed in a certificate store based on the

type of certificate, click Automatically select the certificate store based on the
type of certificate.
If you want to specify where the certificate is stored, select Place all certificates in
the following store, click Browse, and choose the certificate store to use.
User certificates can be managed by the user or by an administrator. Certificates issued to a

computer or service can only be managed by an administrator or user who has been given
the appropriate permissions.
To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.
Enabling strong private key protection will ensure that you are prompted for a password every
time the private key is used. This is useful if you want to make sure that the private key is not
used without your knowledge.
The file from which you import certificates will remain intact after you have completed
importing the certificates. You can use Windows Explorer to delete the file if it is no longer
needed.
Determine Whether a Server Object Has

Child Objects
After Active Directory Domain Services (AD DS) is properly installed on a domain controller, the
server object for the domain controller has a child NTDS Settings object. Other applications that
are running on domain controllers can also publish child objects.
When you remove AD DS from a server, the NTDS Settings child object is removed automatically
from the server object in the Servers container in Active Directory Sites and Services. Before you
delete a server object from the Servers container for a site, verify that the server object has no
child objects. The following conditions might result in the presence of a child object:
If an NTDS Settings object is present, it is possible that replication of the deletion has not
reached the domain controller whose objects you are viewing. Check the presence of the
468
object on another domain controller, or force replication from another domain controller in the
domain. (See Force Replication Between Domain Controllers.)
If a child object other than NTDS Settings is present, another application has published the
object and is using the server object. In this case, do not delete the server object.
To determine whether a server object has child objects
2. In the console tree, expand the Sites container, and then expand the site of the server
object.
3. Expand the Servers container, and then expand the server object to view any child
objects.

469
click Delete.
Important
See Also
Add the Certificates Snap-in to an MMC

You can use the Certificates snap-in to manage certificates for a user, computer, or service
account. To switch between managing certificates for your user account, a computer, or a service,
you must add separate instances of the Certificates snap-in to the console.
Adding the Certificates Snap-in to an MMC
For a user account
For a computer account
For a service
To add the Certificates snap-in to an MMC for a user account
1. Click Start, click Start Search, type mmc, and then press ENTER.
3. Under Available snap-ins, double-click Certificates, and then:
If you are logged on as an administrator, click My user account, and then click
Finish.
If you are logged on as a user, Certificates automatically loads.
4. If you have no more snap-ins to add to the console, click OK.

470
5. To save this console, on the File menu, click Save.

User certificates can be managed by the user or by an administrator.
Local Administrators is the minimum group memberships required to complete this procedure.
Review the details in "Additional considerations" in this topic.
To add the Certificates snap-in to an MMC for a computer account
3. Under Available snap-ins, double-click Certificates
4. Select Computer account and then click Next.
To manage certificates for the local computer, click Local computer, and then click
Finish.
To manage certificates for a remote computer, click Another computer and type the
name of the computer, or click Browse to select the computer name, and then click
Finish.

To perform this procedure, you must be a member of the Administrators group on the local
computer, or you must have been delegated the appropriate authority. If the computer is
joined to a domain, members of the Domain Admins group might be able to perform this
procedure. As a security best practice, consider using Run as to perform this procedure.
To manage certificates for another computer, you can either create another instance of
Certificates in the console, or right-click Certificates (Computer Name), and then click
Connect to Another Computer.
Local Administrators is the minimum group memberships required to complete this procedure.
Review the details in "Additional considerations" in this topic.
To add the Certificates snap-in to an MMC for a service
3. Under Available snap-ins, double-click Certificates
4. Select Service account and then click Next.
To manage certificates for services on your local computer, click Local computer,
471
To manage certificates for service on a remote computer, click Another computer

and type the name of the computer, or click Browse to select the computer name,
6. Select the service for which you are managing certificates.

7. Click Finish, and then click Close.
To perform this procedure, you must be a member of the Administrators group on the local
computer, or you must have been delegated the appropriate authority. If the computer is
joined to a domain, members of the Domain Admins group might be able to perform this
procedure. As a security best practice, consider using Run as to perform this procedure.
To manage certificates for a service on another computer, you can either create another
instance of Certificates in the console, or right-click Certificates - Service (Service Name)
on Computer Name, and then click Connect to Another Computer.

Forced removal of a domain controller from Active Directory Domain Services (AD DS) is
intended to be used as a last resort to avoid having to reinstall the operating system on a domain
controller that has failed and cannot be recovered. When a domain controller can no longer
function in a domain (that is, it is offline), you cannot remove AD DS in the normal way, which
requires connectivity to the domain. Forced removal is not intended to replace the normal AD DS
removal procedure in any way. It is equivalent to permanently disconnecting the domain
controller. However, after successful metadata cleanup of a forcibly removed domain controller,
you can recreate the domain controller using the same name.
Note
On domain controllers that are running Windows Server 2008, you can perform a forced
removal of AD DS on a server that can be started only in Directory Services Restore
Mode (DSRM).
AD DS stores a considerable amount of metadata about a domain controller. During the normal
process of uninstalling AD DS on a domain controller, this metadata is removed from AD DS
through a connection to another domain controller in the domain. In a forced removal, it is
assumed that there is no connectivity to the domain. Therefore, there is no attempt at metadata
removal (cleanup) after a forced removal.
Consequently, forced removal of AD DS from a domain controller must always be followed by the
metadata cleanup procedure, which removes all references to the domain controller from the
domain and forest.
472
Forced removal should not be performed on the last domain controller in a domain. For this
domain controller, you can reinstall the operating system to restore the server to network
operation.
If the domain controller that you are forcibly removing holds an operations master (also known as
flexible single master operations or FSMO) role or roles, transfer the roles before you perform the
forced removal procedure. From a healthy domain controller in the domain of the operations
master role, or in the forest if the role is a forest-wide role, attempt to transfer the role to another
domain controller. If you do not transfer operations master roles before you forcibly remove
AD DS, the roles are transferred during the metadata cleanup process automatically. However,
during metadata cleanup, you do not have the option to select the domain controller to which the
roles are transferred. The cleanup application makes the selection automatically. If role transfer
fails during metadata cleanup, you must seize the role following the metadata cleanup procedure.
For more information about transferring and seizing operations master roles, see Introduction to
Administering Operations Master Roles.
Task requirements
Dcpromo.exe
Ntdsutil.exe or Active Directory Users and Computers

1. Identify Replication Partners. Use this procedure to identify a domain controller that is a
replication partner of the domain controller that you are removing. Identify a replication
partner in the same site, if possible. You will connect to this domain controller when you clean
up server metadata.
2. Force Domain Controller Removal
3. Clean Up Server Metadata

473
connection objects.
Note
Force Domain Controller Removal

You can use this procedure to forcefully remove Active Directory Domain Services (AD DS) from
a domain controller running Windows Server 2008. On a domain controller that is running
Windows Server 2008, you can forcefully remove a domain controller even when it can be started
only in Directory Services Restore Mode (DSRM).
Typically, you force the removal of a domain controller only if the domain controller has no
connectivity with other domain controllers. Because the domain controller cannot contact other
domain controllers during the operation, the Active Directory domain and forest metadata is not
updated automatically as it is when a domain controller is removed normally. Instead, you must
manually update the metadata after you remove the domain controller. For information about
performing metadata cleanup, see Clean Up Server Metadata.
You can forcefully remove a domain controller at a command line or by using an answer file. For
answer file parameters that you can use to remove AD DS, see Demotion Operation
To force removal of AD DS from a domain controller
1. Click Start, click Run, type the following command, and then press ENTER:
Dcpromo /forceremoval
If the domain controller hosts any operations master (also known as flexible single master
operations or FSMO) roles or if it is a Domain Name System (DNS) server or a global
catalog server, warnings appear that explain how the forced removal will affect the rest of
474
the environment. After you read each warning, click Yes. To suppress the warnings in
advance of the removal operation, type /demotefsmo:yes at the command prompt. If you
forcefully removal AD DS from a server that hosts an operations master role, you must
seize the role after the Dcpromo operation. For information about seizing an operations
master role, see Seizing an operations master role.
click Next.
3. On the Force the Removal of Active Directory Domain Services page, review the
information about forcing the removal of AD DS and metadata cleanup requirements, and
then click Next.
4. On the Administrator Password page, type and confirm a secure password for the local
Administrator account, and then click Next.
necessary.
To save the settings that you selected to an answer file that you can use to automate
subsequent AD DS operations, click Export settings. Type a name for your answer file,
and then click Save.
When you are sure that your selections are accurate, click Next to remove AD DS.
can restart the server to complete the AD DS removal when you are prompted to do so.
7. Perform metadata cleanup, as described in Clean Up Server Metadata.
See Also

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.
475
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
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
To clean up server metadata by using Active Directory Users and Computers
Administrative Tools, and then click Active Directory Users and Computers.
2. If you have identified replication partners in preparation for this procedure, and if you are
not connected to a replication partner of the removed domain controller whose metadata
you are cleaning up, right-click Active Directory Users and Computers
<DomainControllerName>, and then click Change Domain Controller. Click the name
of the domain controller from which you want to remove the metadata, and then click OK.
3. Expand the domain of the domain controller that you forcibly removed, and then click
Domain Controllers.
4. In the details pane, right-click the computer object of the domain controller whose
metadata you want to clean up, and then click Delete.
5. In the Active Directory Domain Services dialog box, click Yes to confirm the computer
object deletion.
6. In the Deleting Domain Controller dialog box, select This Domain Controller is
permanently offline and can no longer be demoted using the Active Directory
Domain Services Installation Wizard (DCPROMO), and then click Delete.
7. If the domain controller is a global catalog server, in the Delete Domain Controller
dialog box, click Yes to continue with the deletion.
8. If the domain controller currently holds one or more operations master (also known as
flexible single master operations or FSMO) roles, click OK to move the role or roles to the
domain controller that is shown.
You cannot change this domain controller. If you want to move the role to a different
domain controller, you must move the role after you complete the server metadata
cleanup procedure.
476
To clean up server metadata by using Ntdsutil

1. Open a command prompt as an administrator: On the Start menu, right-click Command
ntdsutil
3. At the ntdsutil: prompt, type the following command, and then press ENTER:
metadata cleanup
4. At the metadata
cleanup:
remove selected server <ServerName>
Or
remove selected server <ServerName1> on <ServerName2>
Value
Description
ntdsutil: metadata cleanup
Initiates removal of objects that refer to a

decommissioned domain controller.
remove selected server
Removes objects for a specified, decommissioned

domain controller from a specified server.
<ServerName> or
<ServerName1>
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.
on <ServerName2>
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.
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:

477
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
Administering Active Directory Domain

Rename
This guide provides information about planning and performing a domain rename operation in
Windows Server 2008. For checklists of the various tasks to be performed during the different
phases of this operation, see Appendix C: Checklists for the Domain Rename Operation.
Suggested formats for a variety of worksheets that you can use for gathering information about
your Active Directory Domain Services (AD DS) infrastructure are included in Appendix D:
Worksheets for the Domain Rename Operation. You can use these worksheets for planning and
tracking progress as you proceed with your domain rename operation.
In this guide
Introduction to Administering Active Directory Domain Rename
Managing Active Directory Domain Rename
Additional Resources for the Domain Rename Operation

Directory Domain Rename
You can use the Windows Server 2008 domain rename process to change the names of your
Active Directory domains, and you can also use it to change the structure of the domain trees in
your Active Directory forest. This process involves updating the Domain Name System (DNS) and
trust infrastructures as well as Group Policy and Service Principal Names (SPNs).
The ability to rename domains gives you the flexibility to make important name changes and
forest structural changes as the needs of your organization change. Using domain rename, you
478
can change the name of a domain, but you can also change the structure of the domain
hierarchy. You can also change the parent of a domain or move a domain in one domain tree to
another domain tree. The domain rename process can accommodate scenarios involving
acquisitions, mergers, or name changes in your organization, but it is not designed to
accommodate forest mergers or the movement of domains between forests.
Important
It is extremely important and highly recommended that you test the domain rename
operation before you perform it in a production environment. First, perform the domain
rename operation that is described in this section in a test environment that has a
minimum of two domains. Familiarizing yourself with the specifics of each stage in the
domain rename operation in a test environment will provide you with not only a much
better understanding of the operation itself but also better prepare you to troubleshoot
any issues that may arise during the domain rename operation in a production forest.
For more information, see Domain Rename Technical Reference (http://go.microsoft.com/fwlink/?
LinkID=122922).
Domain rename requirements

The following conditions must be in effect before you can begin a domain rename operation:
Forest functionality: You can rename domains only in a forest where all of the domain
controllers are running Windows Server 2008 or Windows Server 2003 Standard Edition,
Windows Server 2008 or Windows Server 2003 Enterprise Edition, or Windows Server 2008
or Windows Server 2003 Datacenter Edition operating systems, and the Active Directory
forest functional level has been raised to either Windows Server 2003 or Windows
Server 2008. The domain rename operation will not be successful if the forest functional level
is set to Windows 2000 native. For more information about forest functional levels and for
procedures to determine and set forest functional levels, see Enabling Windows Server 2008
Advanced Features for Active Directory Domain Services (http://go.microsoft.com/fwlink/?
LinkID=105303).
Administrative credentials: You must have Enterprise Admins credentials to perform the
various procedures for the domain rename operation. If you are running Microsoft Exchange,
the account that you use must also have Full Exchange Administrator credentials.
Control Station: The computer that you use as the control station for the domain rename
operation must be a member computer (not a domain controller) running Windows
Server 2008 Standard Edition, Windows Server 2008 Enterprise Edition, or Windows
Server 2008 Datacenter Edition.
Distributed File System (DFS) root servers: So that you can rename a domain with domainbased DFS Namespace (DFSN) roots, all DFSN root servers must be running Windows 2000
with Service Pack 3 (SP3), Windows Server 2003, or Windows Server 2008 operating
systems.
If your forest contains Exchange 2003 Service Pack 1 (SP1) servers, you can run the
Windows Server 2008 domain rename operation, but you must also use the Exchange
479
Domain Rename Fix-up Tool to update Exchange attributes. For more information, see
Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup)
(http://go.microsoft.com/fwlink/?LinkID=122982). The document that accompanies this tool
describes when and how to perform Exchange-related tasks. To perform a domain rename
operation, Exchange must not be installed on any domain controllers. If a domain controller is
running Exchange, move the Exchange data off the domain controller and then uninstall
Exchange.
Important
The Windows Server 2008 domain rename operation is not supported in an
Active Directory forest that contains Exchange Server 2003, Exchange Server 2003
SP2, Exchange Server 2007, or Exchange Server 2007 SP1.
Note
You can use "Checklist: Satisfying Domain Rename Requirements" in Appendix C:
Checklists for the Domain Rename Operation to make sure that you have met all the
necessary requirements for the domain rename operation.
Managing Active Directory Domain Rename

This section includes the following tasks for managing Windows Server 2008 Active Directory
domain rename:
Preparing for the Domain Rename Operation
Performing the Domain Rename Operation
Completing the Domain Rename Operation
Preparing for the Domain Rename Operation

This task helps you prepare for the domain rename operation. The goal of the preparation phase
for the domain rename operation is to ensure that the prerequisites for the domain rename
operation are in place. Completing these preliminary tasks will ensure a smooth implementation
of domain renaming or domain restructuring in your forest. You can use the "Checklist: Preparing
for the domain rename operation" in Appendix C: Checklists for the Domain Rename Operation to
make sure that you have completed all of the required preliminary tasks. If these prerequisites are
not satisfied, domain rename cannot be performed successfully.
Adjust Forest Functional Level
Create Necessary Shortcut Trust Relationships
Prepare DNS Zones
Redirect Special Folders to a Standalone DFSN

480
Relocate Roaming User Profiles to a Standalone DFSN
Configure Member Computers for Host Name Changes
Prepare Certification Authorities
Exchange-Specific Steps: Prepare a Domain that Contains Exchange
Adjust Forest Functional Level

You can use this procedure to adjust the forest functional level for a domain rename operation.
The domain rename operation is supported within an Active Directory forest if, and only if, all
domain controllers in the forest are running Windows Server 2003 or Windows Server 2008
Standard Edition, Windows Server 2003 or Windows Server 2008 Enterprise Edition, or
Windows Server 2003 or Windows Server 2008 Datacenter Edition, and the forest functionality
has been raised to Windows Server 2003 or Windows Server 2008. Therefore, before you can
rename a domain in your Active Directory forest, you must ensure that the forest functionality has
been set to at least Windows Server 2003 or raised to Windows Server 2008.
Setting forest functional level to

Windows Server 2003 or Windows Server 2008
You can set the forest functional level to Windows Server 2003 if all domain controllers in the
forest run either Windows Server 2003 or Windows Server 2008 operating systems. If any
domain controller in the forest is still running Windows 2000, you cannot set the forest functional
level to Windows Server 2003.
You can set the forest functional level to Windows Server 2008 if all domain controllers in the
forest run Windows Server 2008 operating system. If any domain controller in the forest is still
running Windows Server 2003, you cannot set the forest functional level to Windows
Server 2008.
For more information, see Understanding AD DS Functional Levels
To set the forest functional level to Windows Server 2003 or Windows Server 2008
1. Open the Active Directory Domains and Trusts snap-in: click Start, click Administrative
Tools, and then click Active Directory Domains and Trusts.
Raise Forest Functional Level.
3. In Select an available forest functional level, do one of the following:
To raise the forest functional level to Windows Server 2003, click

Windows Server 2003, and then click Raise.
To raise the forest functional level to Windows Server 2008, click Windows
Server 2008, and then click Raise.
481
Caution
Do not raise the forest functional level to Windows Server 2008 if you have, or
will have, any domain controllers that are running Windows Server 2003 or
earlier. After you raise the forest functional level to Windows Server 2008, you
cannot change the level back to Windows Server 2003.
Create Necessary Shortcut Trust

Relationships
You can use this procedure to create the necessary shortcut trust relationships for a domain
rename operation. You can reposition any domain within the domain tree hierarchy of a forest,
with the exception of the forest-root domain. In other words, although the forest root domain can
be renamed (its Domain Name System (DNS) and NetBIOS names can change), it cannot be
repositioned in such a way that you designate a different domain to become the new forest root
domain. If your domain rename operation involves restructuring the forest by repositioning the
domains in the domain tree hierarchy, as opposed to simply changing the names of the domains
in-place, first create the necessary shortcut trust relationships between domains so that the new
forest structure has two-way, transitive trust paths between every pair of domains in the target
forest, just as your current forest does.
Types of trust relationships

A hierarchy of Active Directory domains is implemented by trust relationships between domains.
The following types of trust relationships are established between domains within an
Active Directory forest:
Parent-child: The trust that is established when you create a new domain in an existing tree in
the forest. The Active Directory Domain Services (AD DS) installation process creates a
transitive, two-way trust relationship automatically between the new domain (the child
domain) and the domain that immediately precedes it in the namespace hierarchy (the parent
domain).
Tree-root: The trust that is established when you add a new domain tree to the forest. The
installation process for AD DS creates a transitive, two-way trust relationship automatically
between the domain that you are creating (the new tree-root domain) and the forest root
domain.
Shortcut: A manually created, one-way, transitive trust relationship between any two domains
in the forest, created to shorten the trust path. To establish two-way, shortcut trust
relationships between two domains, you set up a shortcut trust relationship manually in each
direction.
482
The effect of the transitive, two-way trust relationships that are created automatically by the
installation process for AD DS is that there is complete trust between all domains in an
Active Directory forestevery domain has a transitive trust relationship with its parent domain,
and every tree-root domain has a transitive trust relationship with the forest root domain. If you
use the domain rename operation to restructure an existing Active Directory forest by altering the
domain tree hierarchy, automatic creation of the necessary trust relationships does not occur. For
this reason, as part of the preparation phase of domain rename, the trust relationships that are
required to preserve complete trust between all domains in your new forest (after restructuring)
must be precreated manually.
Precreating parent-child trust relationships for a

restructured forest
If you plan to use the domain rename operation to reposition one or more domains in the domain
tree hierarchy, for each domain that you plan to reposition, the necessary shortcut trust
relationships must be created between the domain that you want to reposition and its new parent
domain (or the forest root domain, if the repositioned domain becomes a tree root). These
precreated trust relationships substitute for the required tree-root or parent-child trust
relationships that will be missing in the restructured forest.
Precreating a parent-child trust relationship

For example, suppose that you want to restructure the cohowinery.com forest, shown in the
following illustration, so that the products.sales.cohowinery.com domain becomes a child of the
cohowinery.com domain. Before you perform the domain rename operation to carry out this
restructure, you must first create a two-way, transitive shortcut trust relationship between
products.sales.cohowinery.com and cohowinery.com. This trust relationship precreates the twoway, parent-child trust relationship that will be required for the targeted parent and child domains.
The following illustration shows the before and after domain structures and the shortcut trust
relationships you have to create that will serve as parent-child trust relationships in the target
forest.
483
Pre-creating multiple parent-child trust relationships

For scenarios in which you have to restructure a domain that is both a child domain and a parent
domain, you might have to create shortcut trust relationships in two places. For example,
suppose that you want to restructure the cohowinery.com forest, shown in the following
illustration, to move the hr.sales.cohowinery.com domain so that it becomes a child of the
eu.cohowinery.com domain. At the same time, you want to make its child domain,
payroll.hr.sales.cohowinery.com, become a direct child of its current parent domain,
sales.cohowinery.com. To perform this restructure operation, you first have to create two shortcut
trust relationships that will become the parent-child trust relationships for the new forest that
follows the restructuring, as shown:
A two-way, transitive shortcut trust relationship between the eu.cohowinery.com and

hr.sales.cohowinery.com domains, which will create a two-way, transitive parent-child trust
relationship between eu.cohowinery.com and hr.eu.cohowinery.com after restructuring
A two-way, transitive shortcut trust relationship between the sales.cohowinery.com and

payroll.hr.sales.cohowinery.com domains, which will create a two-way, transitive parent-child
trust relationship between sales.cohowinery.com and payroll.sales.cohowinery.com after
restructuring
484
These shortcut trusts are responsible for maintaining the two-way, transitive trust relationships
that are required between the newly renamed domains when the domain rename operation is
complete.
Precreating a tree-root trust relationship with the forest root

domain
When a domain is renamed to become a new tree root, the new tree-root domain must have a
two-way, transitive trust relationship with the forest root domain. For this scenario, you create a
two-way shortcut trust relationship between the domain that you want to rename to become a
new tree-root domain and the forest root domain.
485
For example, suppose that you have a deep tree and you want to create a new tree by moving
the lowest-level domain to become a tree-root domain. The following illustration shows the twoway shortcut trust relationship that you create, and the tree-root trust relationship it provides after
the restructure, when you rename the eu.sales.cohowinery.com domain to create the tree-root
domain cohoeurope.com.
Creating shortcut trust relationships

Analyze the target forest structure that you intend to achieve. Consider the requirement of a twoway, transitive trust relationship between each pair of domains in the forest, and create a list of
shortcut trust relationships that are necessary to preserve full trust relationships between all the
domains in the target forest. Create the shortcut trust relationships so that they are in place when
you begin the domain rename procedure. You can use "Worksheet 2: Trust Information" in
Appendix D: Worksheets for the Domain Rename Operation to document all trust relationships
that are necessary to preserve full trust relationships between all the domains in the target forest.
For information about how to create shortcut trust relationships, see Create a Shortcut Trust
Prepare DNS Zones

You can use this procedure to prepare Domain Name System (DNS) zones for Active Directory
domain rename. When an application or client requests access to Active Directory Domain
486
Services (AD DS), an Active Directory domain controller is located by the domain locator
(DC Locator) mechanism. In response to client requests for AD DS services, DC Locator uses
service (SRV) resource records in Domain Name System (DNS) to locate domain controllers. In
the absence of these DNS service location (SRV) resource records, directory clients experience
failures when they attempt to access AD DS. For this reason, before you rename an
Active Directory domain, you have to be sure that the appropriate DNS zones exist for the forest
and for each domain. If the appropriate zones do not exist in DNS, you have to create the DNS
zone or zones that will contain the service (SRV) resource records for the renamed domains. We
also strongly recommend that you configure the zone(s) to allow secure dynamic updates. This
DNS zone requirement applies to each domain that is renamed as part of the domain rename
operation.
The DNS requirements to rename an Active Directory domain are identical to the DNS
requirements to support an existing Active Directory domain. Your current DNS infrastructure
already provides necessary support for your Active Directory domain by using its current name.
Usually, you only have to mirror the existing DNS infrastructure to add support for the planned
new name of your domain.
For example, suppose that you want to rename an existing Active Directory domain
sales.cohovineyard.com to marketing.cohovineyard.com. If the service (SRV) resource records
that are registered by the domain controllers of the sales.cohovineyard.com Active Directory
domain are registered in the DNS zone named sales.cohovineyard.com, you have to create a
new DNS zone called marketing.cohovineyard.com which corresponds to the new name of the
domain. For more information about how to configure DNS to provide support for AD DS, see
Creating a DNS Infrastructure Design (http://go.microsoft.com/fwlink/?LinkId=124108).
Before you begin the domain rename process, verify that any new zones that are required have
been created and configured to allow dynamic updates. Analyze your current DNS infrastructure
in relation to the new forest structure that you want after the domain rename operation has
completed and compile a list of DNS zones that have to be created. You can use "Worksheet 3:
DNS Zone Information" in Appendix D: Worksheets for the Domain Rename Operation to
document this list.
For more information about how to create DNS zones, see Add a Forward Lookup Zone
(http://go.microsoft.com/fwlink/?LinkID=108851). For more information about how to configure
dynamic updates, see Allow Dynamic Updates (http://go.microsoft.com/fwlink/?LinkId=124109).
Redirect Special Folders to a Standalone

DFSN
You can use this procedure to redirect special folders to the standalone Distributed File System
Namespaces (DFSN) for domain rename. Windows Server 2003 and Windows Server 2008 help
redirect a set of special folders for users, such as the My Documents folder, from the local
computer to a network location. Folder Redirection is an extension to Group Policy that you can
use to identify network locations for these folders on specific servers or DFSN. If you redirect
487
folders to a network location that uses domain-based DFSN (Domain_Name\DFSN_Name),

renaming the Active Directory domain invalidates the path to the domain-based DFSN. If the
redirected path is no longer valid, Folder Redirection stops working.
Note
If the NetBIOS name of a domain is used in a domain-based DFSN and the NetBIOS
name of the domain is not changed during the domain rename operation, the path to this
domain-based DFSN will continue to be valid.
So that Folder Redirection can continue to work after a domain rename operation, folders that are
redirected to a domain-based DFSN for a domain that is going to be renamed must instead be
redirected to a standalone DFSN (also known as server-based DFSN) before you rename the
domain. Stand-alone DFSNs are not affected by the domain rename operation. You can configure
Folder Redirection to a stand-alone DFSN instead of a domain-based DFSN by using the
Folder Redirection Group Policy extension. For information about how to use Group Policy to
redirect special folders to a network location, see Use Folder Redirection
Relocate Roaming User Profiles to a

Standalone DFSN
You can use this procedure to relocate roaming user profiles to a stand-alone Distributed File
System Namespace (DFSN) for domain rename. Windows Server 2003 Server and Windows
Server 2008 provide support for roaming user profiles where the user profile (as well as the home
directory) can be located on a network location. Just as for Folder Redirection, if roaming user
profiles (and the home directory) are placed on a network location by using a domain-based
DFSN, renaming the domain invalidates the path to this DFSN and roaming profiles that use this
path stop working.
Note
If the NetBIOS name of a domain is used in a domain-based DFSN and the NetBIOS
name of the domain is not changed during a domain rename operation, the path to the
domain-based DFSN continues to be valid.
To ensure that network share-based user profiles continue to work after a domain rename
operation, user profiles that are located on a domain-based DFSN for a domain that is going to be
renamed must be relocated to a stand-alone DFSN (also known as a server-based DFSN).
Server-based DFSNs are not affected by the domain rename operation. For information about
how to create roaming user profiles, see Configuring Roaming User Profiles
488
Configure Member Computers for Host Name

Changes
You can use this procedure to configure member computers for host name changes in a domain
rename operation. By default, the primary Domain Name System (DNS) suffix of a member
computer of an Active Directory domain is configured to change automatically when domain
membership of the computer changes. The same default behavior is true when the DNS name of
the domain to which a computer is joined changes. For this reason, rename of an Active Directory
domain can cause modification of the primary DNS suffix and, therefore, of the full DNS host
names of the computers that are the members of the renamed domain.
For example, if the sales.cohowinery.com domain is renamed to marketing.cohowinery.com, the
primary DNS suffix of the member computers of this domain might also change from
sales.cohowinery.com to marketing.cohowinery.com, depending on whether the default behavior
is in effect. If the default behavior is in effect, the full DNS host name of a computer in the
renamed domain changes from host.sales.cohowinery.com to host.marketing.cohowinery.com.
Conditions for automatic computer name change

The primary DNS suffix, and therefore the full DNS name of a member computer in an
Active Directory domain, changes automatically when the domain is renamed if both of the
following conditions are true:
The primary DNS suffix of the computer is configured to be updated when domain
membership changes.
No Group Policy that specifies a primary DNS suffix is applied to the member computer.
These conditions represent the default configuration for computers that are running
Windows Server 2003 and Windows Server 2008.
Remember that the DNS suffix setting also applies to servers that are running Microsoft
Exchange. When you determine the primary DNS suffix configuration for your servers, also check
your Exchange servers.
Note
The DNS host names of domain controllers in a renamed domain are not changed
automatically to use the new domain DNS name as the primary DNS suffix, regardless of
the primary DNS suffix configuration. In other words, the DNS names of domain
controllers in a renamed domain will remain unchanged. You can rename the domain
controllers in a separate step after the domain rename operation is complete by using a
special domain controller rename procedure. For more information about how to rename
a domain controller, see Renaming a Domain Controller.
489
Replication effects of renaming large numbers of

computers
If the conditions that prompt automatic update of the DNS host names for all computers in the
domain are true and if there are a large number of member computers in the domain that is being
renamed, replication of that many changes might cause excessive traffic on your network. Recall
that a computer name change triggers update of the dnsHostName and servicePrincipalName
attributes on the corresponding computer account in Active Directory Domain Services (AD DS).
These attributes will typically be updated when the member computer is restarted, as required by
the domain rename operation after you rename the domain. Update of these attributes by a large
number of computers within a short period of time might trigger replication activity that saturates
the network. Moreover, computer name change triggers update of the host (A), host (AAAA), and
pointer (PTR) resource records in the DNS database. Such updates also cause additional
replication traffic, regardless of whether DNS zones are stored in AD DS or in some other DNS
store. For these reasons, you should prepare for the domain rename operation in advance by
reconfiguring the default behavior that changes the primary DNS suffix on member computers
when a domain is renamed.
Important
If you do not think that the resulting replication traffic poses a risk of network congestion
or saturation to your infrastructure, you can allow for the DNS names of the member
computers in the renamed domain to change automatically as a result of the domain
rename operation. In other words, if there is no risk of network congestion, skip this
preparatory step of configuring member computers for host name changes and proceed
with the next step: Prepare Certification Authorities.
On the other hand, if the number of member computers in the domain to be renamed is large and
the consequent replication traffic poses the risk of network congestion in your environment, you
should prepare for an Active Directory domain rename operation in advance so that you can
rename the member computers in smaller batches to mitigate the replication traffic problem. In
this case, you can take steps so that computers will not be renamed after domain rename by
ensuring that at least one of the two conditions in Conditions for Automatic Computer Name
Change is not true.
Note
You do not have to match the DNS suffix to the new domain name. If your current
implementation uses a primary DNS suffix that does not match the DNS name of the
domain to which the member computers are joined and if you do not want the DNS suffix
to change following domain rename, you can ensure that these computers are not
renamed after the domain rename by verifying that at least one of the two conditions in
Conditions for Automatic Computer Name Change is not satisfied.
490
Using Group Policy to apply the new primary DNS

suffix
To avoid a replication "storm" that can result from thousands of computer names being changed
at approximately the same time, you can use Group Policy to revise the primary DNS suffix to the
new domain name before the domain rename so that member names are not automatically
updated but have the correct primary DNS suffix at the time that you perform the domain rename.
Apply the new primary DNS suffix before renaming domains

If you establish the planned new name of the domain as the primary DNS suffix for all computers
in the domain before you rename the domain, you can ensure that your member computers are
not renamed automatically after the domain rename opration. In this way, you can avoid a
potential problem in which replication of name-change updates negatively affects network
performance immediately after the domain rename.
You can use the Group Policy setting Primary DNS Suffix to establish the primary DNS suffix for
the domain as the new DNS domain name. When this Group Policy setting is in effect, it
overrides the default behavior of changing the primary DNS suffix when the DNS name of the
domain changes. In this case, the computer names remain the same when you rename the
domain and replication of name changes does not occur.
Apply Group Policy in stages to avoid significant replication

When you apply the Group Policy setting, Primary DNS Suffix changes the DNS suffix and
precipitates a name change. Therefore, you must manage the Group Policy application in stages,
depending on how many member computers are in the domain that is being renamed. To apply
Group Policy to all member computers in the domain or domains that are being renamed, while
also avoiding replication on a large scale, you have to divide computer objects among several
locations in AD DSeither organizational units (OUs) or sites, or both. In deployments in which
member computers exist in numbers that can affect network efficiency if all computers were
renamed at the same time, you want to have computers distributed among several OUs, for ease
of administration. If member computers at both the site and OU levels are too numerous to
undergo a name change without causing excessive replication, you might want to create
additional organizational units to temporarily house some of the computers so that you can apply
Group Policy in stages.
Important
Do not apply the Group Policy setting to cause a DNS host name change for member
servers that are housing software distribution points for managed software deployment in
your domain. You should wait until the step Fix Group Policy Objects and Links later in
this document. The member servers that house software distribution points will change
their DNS host name at that step after they are restarted.
You can rename member computers one group at a time by using the following sequence of
tasks:
491
1. Estimate the largest number of computers (N) that can be renamed in your environment so
that the resulting replication traffic can be sustained by your network without becoming
saturated. It is our expectation that 1000 is an acceptable number.
2. Divide the member computers in the domain to be renamed into groups. Each group should
contain no more than the number of computers N estimated in step 1, so that the new primary
DNS suffix can be applied to one group at a time.
Note
The "groups" that are specified in this step are purely imaginary entities that
represent some collection of computers. There might be no actual object that
corresponds to such a group in the domain. For example, the combination of two
OUs , or one site, or one site plus an OU, and so on, might be used to form one
group, provided that the number of computers in the group does not exceed the
number N of computers that is specified in step 1. If existing sites and OUs all contain
more computers than the number N that is specified in step 1, you might have to
create one or more temporary OUs to group computers so that the new primary DNS
suffix can be applied to one group (in this case, one or more OUs ) at a time. As an
alternative, you can restrict the scope of application of Group Policy to one group by
creating a temporary security group that consists of the group of computers that
should receive the policy and by setting security permissions on the Group Policy
object (GPO) accordingly using the security group that you just created.
3. Create a staggered schedule that determines when the new primary DNS suffix will be
applied to each group of computers that you established in step 2. Ensure that there is
sufficient time between two consecutive applications of the Group Policy setting Primary
DNS Suffix to two different groups of computers to allow replication to occur. Replication of
the updated dnsHostName and servicePrincipalName attributes on computer accounts and
replication of the DNS records of the renamed computers must be completed fully during the
scheduled gap.
4. Configure the domain that is being renamed to allow member computers of the domain to
register the new primary DNS suffix in the dnsHostName attribute of their corresponding
computer accounts in AD DS.
Configuration required before the application of Group Policy

When you apply the Group Policy setting Primary DNS Suffix, the DNS suffix of member
computers will no longer match the DNS name of the domain of which they are members. To
allow the member computers of a domain to have a primary DNS suffix that does not match the
DNS domain name, you must first configure the domain to accept the names that the DNS suffix
can have. This configuration must be in place before you can set Group Policy to apply to a set of
computers.
To configure the set of DNS suffixes that can be applied to computers in the domain, add a new
value (or values) to the msDS-AllowedNDSSuffixes multivalued attribute of the domain object
(the domainDns object for the domain) so that the attribute contains a list of DNS suffixes that
member computers of the Active Directory domain can have. When you apply the Group Policy
492
setting Primary DNS Suffix, you will specify one of the DNS suffixes that you have added to the
msDS-AllowedNDSSuffixes attribute.
If you apply the Primary DNS suffix Group Policy setting to the computers in the domain to be
renamed, we highly recommend that you set the DNS Suffix Search List Group Policy setting
and apply it to the computers in the domain being renamed. The DNS Suffix Search List setting
should contain the old primary DNS suffix, new primary DNS suffix, and potentially parent suffixes
of the old and new primary DNS suffixes. (The latter depends on whether parent name spaces
are being used in the organization.) For example, suppose that the old name of a domain was
payroll.hr.sales.cohowinery.com (that also corresponds with the old primary DNS suffix). Also,
suppose that the new name of the domain is payroll.sales.cohowinery.com (that also corresponds
with the new primary DNS suffix). The DNS Suffix Search List should contain the following
suffixes:
payroll.hr.sales.cohowinery.com
payroll.sales.cohowinery.com
and it may contain these suffixes:
hr.sales.cohowinery.com
sales.cohowinery.com
cohowinery.com
Such configuration preserves the ability of users to resolve the DNS names of computers in the
domain that is being renamed by specifying first label only of the full DNS names of computers
even during the transition period when a users computer and resource server may have different
primary DNS suffixes.
For the same reason, if computers in another domain were configured with DNS Suffix Search
List that contains the old name of a domain being renamed, during the domain rename operation
those computers should be reconfigured so that DNS Suffix Search List is updated to contain
both the old and new domain names.
Configuring member computers for host name

changes in large deployments
If your AD DS implementation is large enough to warrant updating the primary DNS suffix before
the domain rename (that is, you want to avoid the effects of excessive replication of computer
name changes that follow domain rename), you must complete the following tasks:
Determine the Primary DNS Suffix Configuration
Determine Whether Group Policy Controls the Primary DNS Suffix
Configure the Domain to Allow a Primary DNS Suffix that Does Not Match the Domain Name
Apply Group Policy to Set the Primary DNS Suffix
493
Determine the primary DNS Suffix configuration

As a preliminary step, if you do not know how your member computers are configured in relation
to updating the primary DNS suffix if the membership domain changes, you first want to establish
these conditions.
The following procedures describe two ways to view the setting for a member computer that
determines whether the primary DNS suffix changes when the name of the membership domain
changes.
To check for primary DNS suffix update configuration using Control Panel
1. On a member computer, in Control Panel, double-click System.
2. Click the Change settings link.
3. On Computer Name tab, click Change.
4. Click More, and then verify whether Change primary domain suffix when domain
membership changes is selected.
5. Click OK until all dialog boxes are closed.
To check for primary DNS suffix update configuration for a computer using the registry
1. On the Start menu, click Run.
2. In Open, type regedit, and then click OK.
Caution
3. Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
4. Verify whether the value of REG_RWORDSyncDomainWithMembership is 0x1. This
value indicates that the primary DNS suffix changes when the domain membership
changes.
Determine whether Group Policy controls the primary DNS suffix

You can also determine whether Group Policy is applied to the computer to specify the primary
DNS suffix. There are several ways to discover this information, as described in the following
procedure.
You can determine whether Group Policy specifies the primary DNS suffix for a computer on a
member computer using either of the following two procedures.
494
To determine whether Group Policy specifies the primary DNS suffix by using the
command line
1. To open a command prompt, click Start, click Run, type cmd, and then click OK.
gpresult
3. In the output, under Applied Group Policy objects, check to see whether Primary DNS
Suffix is listed.
Or
4. Type the following command, and then press ENTER:
ipconfig /all
5. Check Primary DNS Suffix in the output. If it does not match the primary DNS suffix that
is specified in Control Panel for the computer, the Primary DNS Suffix Group Policy
setting is applied.
To determine whether Group Policy specifies the primary DNS suffix by using the
registry
1. On the Start menu, click Run.
2. In Open, type regedit and then click OK.
3. Navigate to
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\WindowsNT\DNSclient.
4. Check for the presence of the entry Primary DNS Suffix. If a value is present, the
Primary DNS Suffix Group Policy setting is applied to the computer.
Configure the domain to allow a primary DNS suffix that does

not match the domain name
Before you apply Group Policy to set the primary DNS suffix for each renamed domain, create a
list of the DNS suffixes that you want to use for each domain. The only primary DNS suffix
available to the domain, by default, is the DNS name of the domain itself. To make these different
DNS suffixes available to member computers, you must first make the DNS suffixes known to the
domains in which you want to use them. You add DNS suffixes to the domain by editing the
attribute msDS-AllowedDNSSuffixes on the domain object to contain the additional DNS
domain names that are available to be used as DNS suffixes for that domain.
For you to be able to add a primary DNS suffix that is different from the current DNS domain
name, your environment must meet the following requirements:
All domain controllers in the domain must be running Windows Server 2003 or Windows
Server 2008.
For each new DNS suffix that you add, a subdomain by that name must exist in DNS.
495
Caution
The same value in the msDS-AllowedDNSSuffixes attribute cannot be used for more
than one domain in the forest. This undesired configuration enables a malicious
administrator of a computer that is joined to one such domain to set the
servicePrincipalName attribute of its computer account to the same value as the
Service Principal Name (SPN) of a computer in the other domain that is configured to
allow the same DNS suffix. Such a configuration prevents Kerberos authentication
against both of these computers.
The attribute msDS-AllowedDNSSuffixes is an attribute of the domain object. Therefore, you
must set DNS suffixes for each domain whose name is going to change.
To use ADSI Edit to add DNS suffixes to msDSAllowedDNSSuffixes
1. Click Start menu, click Administrative Tools, and then click ADSI Edit.
2. Double-click the domain directory partition for the domain that you want to modify.
3. Right-click Domain container object, and then click Properties.
4. On the Attribute Editor tab, in Attributes, double-click the attribute msDSAllowedDNSSuffixes.
5. In the Multi-valued String Editor dialog box, in Value to add, type a DNS suffix, and
then click Add.
6. When you have added all the DNS suffixes for the domain, click OK.
7. Click OK to close the Properties dialog box for that domain.
8. In the console tree, right-click ADSI Edit, and then click Connect to.
9. Under Computer, click Select or type a domain or server.
10. Type the name of the next domain for which you want to set the primary DNS suffix, and
then click OK.
11. Repeat steps 2 through 7 for that domain.
12. Repeat steps 8 through 10 to select each subsequent domain and repeat steps 2 through
7 to set the primary DNS suffix for each subsequent domain that is being renamed.
Apply Group Policy to set the primary DNS suffix

Start applying the Group Policy setting Primary DNS Suffix to one group of computers at a time.
(For more information, see Apply Group Policy in stages to avoid significant replication.) The new
primary DNS suffix must be applied to all member computers in a domain before the domain is
renamed.
Note
The group of member computers to which this Group Policy setting is applied will have to
be restarted for the host name change to take effect.
496
To apply the Group Policy setting Primary DNS Suffix to groups of member computers
1. Open the Group Policy Management Editor snap-in: click Start, click Administrative
Tools, and then click Group Policy Management.
2. In Group Policy Management Editor, right-click the domain or OU that contains the group
of computers to which you are applying Group Policy.
3. In Group Policy Objects, right-click the GPO that you want to contain the Primary DNS
Suffix setting, and then click Edit.
Note
To create a new GPO that will contain the Primary DNS Suffix setting, right-click
Group Policy Objects, click New, and then type a name for the object.
4. Under Computer Configuration, expand Policies and Administrative Templates,
Network, and then click DNS Client.
5. In the results pane, double-click Primary DNS Suffix.
6. Click Enabled, and then in the Enter a primary DNS suffix box, type the DNS suffix for
the domain whose member computers are in the group that you selected in step 2.
After the Active Directory domain has been renamed and all member computers have had time to
restart, you can disable the Group Policy setting that you enabled in step 6 of the previous
procedure.
Note
The steps in the previous procedure result in naming member computers only, not
domain controllers. Renaming mission-critical servers, such as domain controllers,
requires special preparation that is beyond the scope of this document. For information
about how to rename a domain controller, see Renaming a Domain Controller. We
strongly recommend that you carefully read this Help documentation and then rename
domain controllers in a renamed domain according to the specified recommendations
only after the domain rename operation has completed successfully.
Prepare Certification Authorities

You can use this procedure to prepare certification authorities (CAs) for domain rename.
Management of enterprise certificates can be sustained through a domain rename operation
when the following requirements are in effect before domain rename:
The CAs are not installed on domain controllers.
As a best practice, all the CAs should include both Lightweight Directory Access Protocol
(LDAP) and Hypertext Transfer Protocol (HTTP) URLs in their Authority Information Access
(AIA) and Certificate Distribution Point (CDP) extensions.
497
Caution
If any certificate that the CA issues has only one of these URL types, the certificate may
or may not work. Depending on the complexity of your domain configuration, steps in this
document might not be sufficient for proper management of CAs after the domain rename
operation. Proceed with these steps only if you have considerable expertise in handling
Microsoft CAs.
If one or more of the following conditions exist at the time of domain rename, CA management is
not supported:
The CA is configured to have only LDAP URLs for its CDP or AIA. Because the old LDAP
extensions would be invalid after the domain rename operation, all the certificates that are
issued by the CA are no longer valid. As a workaround, you have to renew the existing CA
hierarchy and all issued End Entity certificates.
After the domain rename operation, the name constraints might not be valid. As a
workaround, you will have to reissue cross-certificates with appropriate name constraints.
A Request for Comments (RFC) 822style e-mail name is used in the user account. If the CA
(or the certificate template) is configured to include RFC 822-style e-mail names and this
name style is used in the certificates that are issued, these certificates will contain an
incorrect e-mail name after domain rename operation. Any such Active Directory accounts
should be changed before any certificate is issued.
As a best practice, the default LDAP and HTTP URLs require no special configuration before the
domain rename operation.
Before you begin the domain rename operation, ensure that the certificate revocation lists (CRLs)
and the CA certificates will not expire soon. If you find that they are close to expiration, complete
the following tasks before the domain rename operation:
1. Renew the CA certificates.
2. Issue a new CRL with the appropriate validity period.
3. Wait until both of these previous items have propagated to all client computers.
For more information, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?
LinkID=122981).
Exchange-Specific Steps: Prepare a Domain

that Contains Exchange
Important
You can use this procedure to prepare a domain that contains Exchange for a domain
rename operation. The Windows Server 2008 domain rename operation is not supported
in an Active Directory forest that contains Exchange Server 2003, Exchange Server 2003
Service Pack 2 (SP2), Exchange Server 2007, or Exchange Server 2007 Service Pack 1
(SP1).
498
If your forest contains Exchange 2003 Service Pack 1 (SP1) servers, you can run the
Windows Server 2008 domain rename operation, but you must also use the Exchange Domain
Rename Fix-up Tool to update Exchange attributes. For more information, see Microsoft
Exchange Server Domain Rename Fixup (XDR-Fixup) http://go.microsoft.com/fwlink/?
LinkID=122982). This document describes preliminary steps and instructions for running the
Exchange Domain Rename Fix-up Tool. As part of the preliminary steps, you must move
Exchange off all domain controllers and discontinue Exchange configuration changes.
Performing the Domain Rename Operation

This task provides information about performing the domain rename operation. This task
describes in detail the procedures that you complete to perform the domain rename operation in
your forest. Be sure that you have reviewed and completed every preliminary procedure that
applies to your domain rename conditions, as described in Preparing for the Domain Rename
Operation.
After you complete all the procedures in this task, the target domain name changes will be
effective in your forest. The domain name changes will have propagated toall the domain
controllers in your forest, as well as to the member computers in the renamed domains.
A brief period of interruption in your Active Directory forest service occurs during the time when all
of the domain controllers in the forest are automatically restarting. The exact point at which the
service interruption occurs is indicated in Run Domain Rename Instructions. Except for this brief
period of interruption, the Active Directory Domain Services (AD DS) service should continue to
be available and function normally throughout the rest of the domain rename process.
Task requirements
Rendom.exe
Repadmin.exe
Gpfixup.exe
Set Up the Control Station
Freeze the Forest Configuration
Back Up All Domain Controllers
Generate the Current Forest Description
Specify the New Forest Description
Generate Domain Rename Instructions
Push Domain Rename Instructions to All Domain Controllers and Verify DNS Readiness
Verify Readiness of Domain Controllers

499
Run Domain Rename Instructions
Exchange-Specific Steps: Update the Exchange Configuration and Restart Exchange Servers
Unfreeze the Forest Configuration
Re-establish External Trusts
Fix Group Policy Objects and Links

You can use this procedure to set up the control station for a domain rename operation. To
perform an Active Directory domain rename operation, you must set up a single computer as the
administrative control station for the entire domain rename operation. All the domain rename
procedures are performed and controlled from this computer. You copy all the required tools to
perform the domain rename operation to a directory on the local disk of the control station and
run the tools from that control station. Although the domain rename operation involves contacting
each domain controller in the forest, the domain controllers are contacted remotely by the domain
rename tools from the control station.
Prerequisites
Computer: Use a computer that is a member of a domain in the forest in which domain
rename operation is to be performed to serve as the control station.
Operating system: The computer must be a member computer (not a domain controller) that
is running Windows Server 2003 Standard Edition or Windows Server 2008 Standard,
Windows Server 2003 Enterprise Edition or Windows Server 2008 Enterprise, or
Windows Server 2003 Datacenter Edition or Windows Server 2008 Datacenter.
Important
Do not use a domain controller to act as the control station for the domain rename
operation.
Operating system CD: You must have the Windows Server 2003 Standard Edition,
Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition
operating system CD.
Membership in the Local Administrators group (or a write access to a local disk drive) on the
computer that is the control station is the minimum required to complete these procedures.
To set up the control station on a Windows Server 2003 member server
1. On a local disk drive of the selected control station computer, create a working directory
for the domain rename tools, for example, C:\domren
Note
Each time that you use the tools in this procedure, run them from this directory.
500
2. Insert the Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise
Edition, or Windows Server 2003 Datacenter Edition operating system CD into the
CDROM drive and copy the files from the valueadd directory into your working directory
as follows:
copy D:\valueadd\msft\mgmt\domren\*.* C:\domren
In particular, verify that the two tools Rendom.exe and Gpfixup.exe have been copied into
the working directory on the control station.
3. Install the Support Tools from the Support\Tools folder on the Windows Server 2003
Standard Edition, Windows Server 2003 Enterprise Edition, or Windows Server 2003
Datacenter Edition operating system CD. (To install Support Tools, run Suptools.msi in
the Support\Tools directory.) In particular, verify that the tools Rendom.exe,
Repadmin.exe, Dfsutil.exe, and Gpfixup.exe are installed on the control station.
To set up the control station on a Windows Server 2008 member server
1. On a local disk drive of the selected control station computer, create a working directory
for the domain rename tools, for example, C:\domren.
Note
Each time that you use the tools in this procedure, run them from this directory.
2. To obtain the necessary tools for the domain rename operation, install the Remote Server
Administration Tools Pack. For more information, see Installing or Removing the Remote
Server Administration Tools Pack (http://go.microsoft.com/fwlink/?LinkId=124111).
Verify that the tools Rendom.exe, Repadmin.exe, Dfsutil.exe, and Gpfixup.exe are
installed on the control station in the %\Windows\System32 directory.
3. Copy Rendom.exe, Repadmin.exe, Dfsutil.exe, and Gpfixup.exe tools from the
%\Windows\System32 directory into your working directory as follows:
robocopy %:\Windows\System32 C:\domren rendom.exe repadmin.exe dfsutil.exe
gpfixup.exe

You can use this procedure to freeze the forest configuration for a domain rename operation.
When your domain rename plan is in place and all preliminary procedures are complete, you
must ensure that the configuration of your forest will not change until after the domain rename
operation is complete. Therefore, before you begin the domain rename operation you must
discontinue the following activities in your forest:
Creating new domains in, or removing existing domains from, your forest
Creating new application directory partitions in, or removing existing application directory
partitions from, your forest
501
Adding domain controllers to, or removing domain controllers from, your forest
Creating or deleting shortcut trusts within your forest
Adding attributes to, or removing attributes from, the set of attributes that replicate to the
global catalog (the partial attribute set).
You can resume these activities after you successfully complete the domain rename operation.
For more information see, Unfreeze the Forest Configuration.
Back Up All Domain Controllers

Back up all domain controllers before you begin a domain rename operation. Perform a full
system state backup of all domain controllers in the forest. For more background information and
detailed step-by-step instructions for backing up domain controllers, see the Step-by-Step Guide
for Windows Server 2008 Active Directory Domain Services Backup and Recovery
Generate the Current Forest Description

You can use this procedure to generate a current forest description for a domain rename
operation. In this procedure, you use the domain rename tool Rendom.exe to generate a textual
description of your current forest structure as an XML-encoded file named Domainlist.xml, which
contains a list of all domain directory partitions as well as application directory partitions that
constitute your forest. This file includes an entry for every domain and application directory
partition, and each entry is bounded by the <Domain></Domain> XML tags. Each entry for a
domain (or an application directory partition) contains its naming data, which includes the object
globally unique identifier (GUID) of the partition root object, the Domain Name System (DNS)
name of the domain (or application directory partition), and the NetBIOS name of the domain. (An
application directory partition does not have a NetBIOS name.) The domain name changes will be
specified from this XML-encoded forest description file in the subsequent step of the domain
rename operation.
The following is a sample Domainlist.xml file that is generated in a forest with two domains
named cohovineyard.com (with a NetBIOS name of COHOVINEYARD) and
sales.cohovineyard.com (with a NetBIOS name of SALES). In addition to the two entries that
correspond to the two domains in the forest, the following three entries appear. These entries
correspond to the application directory partitions that the Active Directoryintegrated DNS service
uses:
DomainDnsZones.sales.cohovineyard.com
DomainDnsZones.cohovineyard.com
ForestDnsZones.cohovineyard.com
These application directory partitions must also be renamed.

<?xml version = 1.0?>
502
<Forest>
<Domain>

<Guid>59add6bb-d0e8-499e-82b9-8aaca5d3e18b</Guid>
<DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<Guid>89cf8ae3-f4a3-453b-ac5c-cb05a76bfa40</Guid>
<DNSname>sales.cohovineyard.com</DNSname>
<NetBiosName>SALES</NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<Guid>f018941b-c899-4601-bfa7-5c017e9d31e7</Guid>
<DNSname>ForestDnsZones.cohovineyard.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<Guid>f018941b-c899-4601-bfa7-5c017e9d31f3</Guid>
<DNSname>DomainDnsZones.cohovineyard.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<! - ForestRoot -->
<Guid>89cf6b34-d753-32a8-da6b-6a8e04bc48a4</Guid>
<DNSname>cohovineyard.com</DNSname>
<NetBiosName>COHOVINEYARD</NetBiosName>
<DcName></DcName>
503
</Domain>
</Forest>
Important
The functional level of the forest in which you perform the domain rename operation must
be set to Windows Server 2003 or Windows Server 2008. Otherwise, the domain rename
tool, Rendom.exe, reports an error and it cannot proceed with further steps.
Membership in the Enterprise Admins group in the current forest and the Local Administrators
group (or write access to the domain rename C:\domren working directory) on the control station
computer is the minimum required to complete this procedure. Review details about using the
Note
You can use credentials other than those credentials with which you are currently logged
on. To use alternative credentials, use the /user and /pwd command-line switches of
rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool.
To generate the current forest description file
1. On the control station, click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type the following command to change to the working directory,
C:\domren
3. To generate the XML-encoded forest description file, at the command prompt, type the
rendom /list
4. Save a copy of the current forest description file (Domainlist.xml) that was generated in
step 3 as Domainlist-save.xml for future reference by using the following copy command:
copy domainlist.xml domainlist-save.xml
Note
The Rendom tool contacts the domain controller that is the current domain naming
operations master role owner in the target forest to gather the information that is
necessary to generate the forest description file. The command might fail if the domain
naming master is unavailable or unreachable from the control station.
Specify the New Forest Description

You can use this procedure to specify the new forest description for a domain rename operation.
In this procedure, you use a text editor to specify your new target forest structure by editing the
forest description file Domainlist.xml that you created with the procedure Generate the Current
Forest Description. The new forest description, which is specified through changes to the domain
504
and the application directory partition names in the Domainlist.xml file will form the starting point
for the remainder of the steps in the domain rename operation.
You can change either the Domain Name System (DNS) name (the field that is bounded by the
<DNSname></DNSname> tags) or the NetBIOS name (the field that is bounded by the
<NetBiosName></ NetBiosName> tags), or both names, for any given domain in the forest. You
cannot, however, change the globally unique identifier (GUID) in the field that is bounded by the
<Guid></ Guid> tags.
Furthermore, pay special attention to the fact that when the DNS name of a parent domain
changes, the DNS name of its child domain should also be changed, unless you are deliberately
restructuring the child domain into a new domain tree root in the forest. For example, if the root
domain cohovineyard.com is renamed to cohowinery.com, the child domain
sales.cohovineyard.com should also be renamed to sales.cohowinery.com, unless you want to
make the domain sales.cohovineyard.com become the root of a new domain tree.
Here is a sample of a forest description Domainlist.xml file before and after you edit it for domain
name changes to rename the root domain from cohovineyard.com to cohowinery.com. This name
change of the forest root domain also results in a renaming of the child domain from
sales.cohovineyard.com to sales.cohowinery.com. Furthermore, assume that the NetBIOS name
of the root domain is also being changed from COHOVINEYARD to COHOWINERY.
BEFORE editing (root domain name: cohovineyard.com)
<Forest>
<Domain>
<!- PartitionType:Application -->
<DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<DNSname>sales.cohovineyard.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<! - PartitionType:Application -->
<Guid> f018941b-c899-4601-bfa7-5c017e9d31e7</Guid>
<DNSname>ForestDnsZones.cohovineyard.com</DNSname>
505
<DcName></DcName>
</Domain>
<Domain>
<Guid> f018941b-c899-4601-bfa7-5c017e9d31f3</Guid>
<DNSname>DomainDnsZones.cohovineyard.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<! - ForestRoot -->
<DNSname>cohovineyard.com</DNSname>
<NetBiosName>COHOVINEYARD</NetBiosName>
<DcName></DcName>
</Domain>
</Forest>
AFTER editing (root domain name: cohowinery.com)

<Forest>
<Domain>
<DNSname>DomainDnsZones.sales.cohowinery.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<DNSname>sales.cohowinery.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
506
<Guid> f018941b-c899-4601-bfa7-5c017e9d31e7</Guid>
<DNSname>ForestDnsZones.cohowinery.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<Guid> f018941b-c899-4601-bfa7-5c017e9d31f3</Guid>
<DNSname>DomainDnsZones.cohowinery.com</DNSname>
<DcName></DcName>
</Domain>
<Domain>
<! - ForestRoot -->
<DNSname>cohowinery.com</DNSname>
<NetBiosName>COHOWINERY</NetBiosName>
<DcName></DcName>
</Domain>
</Forest>
Note
The current forest description must be available as the XML-encoded file Domainlist.xml
that can be modified.
Membership in the Local Administrators group (or write access to the domain rename
C:\domren working directory) on the control station computer is the minimum required to
To edit the Domainlist.xml file
1. Use a simple text editor, such as Notepad.exe, to open the current forest description file
Domainlist.xml that you created in Generate the Current Forest Description.
2. Edit the forest description file, replacing the current DNS or NetBIOS names of the
domains and application directory partitions to be renamed with the planned new DNS or
NetBIOS names.
Note
It is not necessary to change the NetBIOS name of a domain when its DNS
507
name changes.
Renaming application directory partitions

In the previous sample forest description Domainlist.xml file, notice that there are two DNSname
entries that are not domains. These directory partitions are labeled as follows:
These directory partitions store DNS zone data. By default, application directory partitions can be
used to store DNS zone data and Microsoft Telephony Application Programming Interface (TAPI)
data in Active Directory Domain Services (AD DS). Other applications must be programmed to
create and use application directory partitions in AD DS.
Application directory partitions can exist anywhere in the domain hierarchy where a domain
directory partition can exist, except for the forest root or tree root domain positions. However,
when you rename a domain, an application directory partition that occurs below the renamed
domain in the domain tree is not renamed automatically. You must take care to edit the names of
application directory partitions if they occur below a renamed domain in the hierarchy.
DNS data
If you have Active Directoryintegrated DNS that is running on a domain controller, the DNS
server might have created one or more application directory partitions to store data for DNS
zones. There is one DNS-specific application directory partition dedicated for each domain
(named DomainDnsZones.<domain DNS name>, where <domain DNS name> is the name of the
domain), and another DNS-specific application directory partition dedicated for the entire forest
(named ForestDnsZones.<forest DNS name>, where <forest DNS name> is the name of the
forest root domain).
Important
When an Active Directory forest root domain or other domain is renamed, the
corresponding DNS-specific application directory partition must be renamed. If the DNSspecific application directory partition is not renamed, new DNS servers that are added to
the network will not automatically load the DNS zones that are stored in the DNS-specific
application directory partition, and therefore they will not function correctly.
As you can see from the contents of the sample Domainlist.xml file before and after editing, the
following three DNS-specific application directory partitions in the original forest
DomainDnsZones.sales.cohovineyard.com
DomainDnsZones.cohovineyard.com
ForestDnsZones.cohovineyard.com
are renamed to
DomainDnsZones.sales.cohowinery.com
DomainDnsZones.cohowinery.com
508
ForestDnsZones.cohowinery.com
in the new forest as a result of the domain name sales.cohovineyard.com that is being
changed to sales.cohowinery.com and the forest root domain name cohovineyard.com being
changed to cohowinery.com, respectively.
TAPI data
If you have a Microsoft TAPI dynamic directory for a domain that is hosted by AD DS, you may
have created one or more application directory partitions (one for each domain) to store TAPI
application data. There is one TAPI-specific application directory partition configured for each
domain. When you rename an Active Directory domain, the corresponding TAPI-specific
application directory partition is not renamed automatically. We recommend that you rename a
TAPI-specific application directory partition when its corresponding domain name is changed.
To rename application directory partitions
1. Examine the forest description file to determine if any application directory partitions in
the forest must be renamed as a result of the domain DNS name changes that are being
specified.
2. Consult the documentation for the application that created the application directory
partition to see if the directory partition should be renamed. Any DNS name changes for
application directory partitions must also be specified in the forest description file
Domainlist.xml, along with the domain directory partition name changes.
Specifying the source domain controllers

In Generate Domain Rename Instructions, the Rendom.exe tool contacts one arbitrarily chosen
domain controller in each domain of the forest to gather the information that is required for
translating your new forest specification in the Domainlist.xml file into a sequence of required
directory changes that areee encoded as a script to be run at each domain controller. As an
option, you can specify a particular domain controller in each domain from which to pull the
domain-specific information.
To specify domain controllers for each renamed domain in domainlist.xml
In the field that is bounded by the <DcName></DcName> tags within each domain entry,
type the DNS host name of the domain controller that you want to use. For example, to
retrieve information for the domain sales.cohovineyard.com from the domain controller
dc1.sales.cohovineyard.com, specify <DcName>dc1.sales.cohovineyard.com</DcName>
within the domain entry for the renamed domain sales.cohowinery.com. (Recall that
domain controller names do not change when the domain is renamed.)
509
Reviewing the new forest description

Verify that the domain name changes that you have specified in the forest description file
Domainlist.xml yield the new forest structure that you want. You can use Rendom.exe to display
the new forest structure that you specified in the Domainlist.xml file in a user-friendly format by
using text indentation to reflect the domain hierarchy.
To review the new forest description in Domainlist.xml
1. Click Start, click Run, type cmd, and then click OK.
rendom /showforest
This command simply displays the contents of the Domainlist.xml file in a format that is
easier to read and in which you can better see the forest structure. Use this command
each time that you make any changes to the Domainlist.xml file to verify that the forest
structure looks as you intended.
Note
It is essential at this step to specify an accurate forest description that reflects the
desired changes to the forest structure, because any error at this stage will result
in an unintended forest structure when the domain rename operation is complete.
If your target structure is not what you intended, you must perform the entire
domain rename procedure again.
Note
To gather the information that is necessary to process the /showforest command-line
option, Rendom.exe contacts the domain controller that is the current domain naming
master in the target forest. The command might fail if the domain naming master is
unavailable or unreachable from the control station.
Generate Domain Rename Instructions

You can use this procedure to generate domain rename instructions. In this procedure, you use
the Rendom.exe tool to generate the domain rename instructions that are required to make your
new target forest structure effective. Rendom.exe translates the new forest structure as specified
in the edited forest description file that you prepared in Specify the New Forest Description into a
sequence of directory update instructions that are run individually and remotely on each domain
controller in the forest. The XML-encoded script that contains the domain rename instructions is
written to the single-valued, octet-string attribute msDS-UpdateScript on the Partitions container
object (cn=partitions,cn=configuration,dc=ForestRootDomain) in the configuration directory
partition on the domain naming operations master. For more information about the exact directory
changes that occur on the domain naming master, see Preparing Domain Controllers for Domain
Rename in How Domain Rename Works (http://go.microsoft.com/fwlink/?LinkId=124104).
Rendom.exe also generates a state file called Dclist.xml (the default name) and stores this file in
510
the control station's working directory. The Dclist.xml state file is used to track the progress and
state of each domain controller in the forest for the rest of the domain rename operation.
The following is a sample Dclist.xml file that is generated for the two-domain forest in which there
are two domain controllers named DC1 and DC2 in the cohovineyard.com domain and two
domain controllers named DC3 and DC4 in the sales.cohovineyard.com domain.
<?xml version = 1.0?>
<DcList>
<Hash>zzzzzzzz</Hash>
<Signature>zzzzzzzz</Signature>
<DC>
<Name>DC1.cohovineyard.com</Name>
<State>Initial</State>
<LastError>0</LastError>
<Password />
<LastErrorMsg />
<FatalErrorMsg />
<Retry></Retry>
</DC>
<DC>
<Name>DC2.cohovineyard.com</Name>
<Password />
<LastErrorMsg />
<FatalErrorMsg />
<Retry></Retry>
</DC>
<DC>
<Name>DC3.sales.cohovineyard.com</Name>
<Password />
<LastErrorMsg />
<FatalErrorMsg />
511
<Retry></Retry>
</DC>
<DC>
<Name>DC4.sales.cohovineyard.com</Name>
<Password />
<LastErrorMsg />
<FatalErrorMsg />
<Retry></Retry>
</DC>
</DcList>
Notice that there is an entry for every domain controller in the forest in the Dclist.xml state file,
and the state of each domain controller entry (the field that is bounded by the <State></State>
tags) is set to Initial at this step. This state will change independently for each domain controller
as it progresses through the rest of the domain rename operation.
Ensure that the following conditions are in effect before you generate domain rename
instructions:
The source domain controller must be available and reachable. Rendom contacts one
arbitrarily chosen domain controller in each domain (or the domain controller that is
designated for each domain in the <DCname></DCname> field in the Domainlist.xml file) to
gather the information that is necessary to generate the domain rename instructions. The
command might fail if a designated domain controller in a domain is unavailable or
unreachable from the control station (or if a designated domain controller was not specified, if
no domain controller in a domain is reachable from the control station).
The domain naming master must be available and reachable. Rendom writes the domain
rename instructions to the Partitions container in the Configuration directory partition on the
domain naming master, and Rendom gathers the information that is necessary to generate
the state file Dclist.xml. The command might fail if the domain naming master is unavailable
or unreachable from the control station.
Membership in the Enterprise Admins group in the target forest (with a write access to the
Partitions container object and the cross-reference objects that are its children in the
configuration directory partition) and the Local Administrators group (or a write access to the
domain rename C:\domren working directory) on the control station computer is the minimum
512
Note
You can use credentials other than the credentials with which you are currently logged
To generate the domain rename instructions and upload them to the domain naming
master
2. At the command prompt, type the following to change to the working directory, and then
press ENTER:
C:\domren
3. From within the working directory, type the following command, and then press ENTER:
rendom /upload
4. Verify that the state file Dclist.xml is created in the working directory and that it contains
an entry for every domain controller in your forest.
Push Domain Rename Instructions to All

Domain Controllers and Verify DNS
Readiness
You can use this procedure to push domain rename instructions to all domain controllers and
verify Domain Name System (DNS) readiness. In this procedure, you force Active Directory
replication to push the domain rename instructions that were uploaded to the domain naming
operations master in Generate Domain Rename Instructions to all domain controllers in the
forest. In addition, you verify that the domain controller Locator (DC Locator) records that are
registered in DNS by each domain controller for the new domain names have replicated to all
DNS servers that are authoritative for those records.
Pushing domain rename instructions to all

domain controllers
You can use Repadmin.exe tool to force Active Directory replication of directory changes on the
domain naming master to all domain controllers in the forest.
Note
Forcing replication is not required, but it serves to accelerate the replication of the
changes to the Partitions container in the configuration directory partition to all domain
513
controllers in the forest. As an option, you can wait for replication to complete according
to the usual replication intervals and delays that are characteristic of your forest.
If the command in the following procedure completes successfully, the changes that originate at
the domain naming master domain controller have replicated to every domain controller in the
forest. If the command reports an error for some subset of the domain controllers in the forest, the
replication must be reattempted for those failed domain controllers until all domain controllers in
the forest have successfully received the changes from the domain naming master.
Membership in the Enterprise Admins group in the target forest is the minimum required to
To force synchronization of changes made on the domain naming master to all domain
controllers in the forest
repadmin /syncall /d /e /P /q DomainNamingMaster
Note
The repadmin command-line options are case sensitive.
Note
If read-only domain controllers (RODCs) are included in your domain, run this
command one more time to ensure that the RODC new servicePrincipalName
attribute is replicated to all the domain controllers in the forest.
Parameter
Description
/syncall
Synchronizes a specified domain controller with

all replication partners.
/d
Identifies servers by distinguished name in

messages.
/e
Enterprise, cross sites.
/P
Pushes changes outward from the home server.
/q
Quiet mode; suppresses callback messages.
DomainNamingMaster
Specifies the DNS host name of the domain

controller that is the current domain naming
master for the forest.
If you do not know the DNS host name of the domain naming master, you can use the
Dsquery.exe tool to discover it.
514
Membership in the Enterprise Admins group in the target forest, or equivalent, is the minimum
To discover the DNS host name of the domain naming master
Dsquery server -hasfsmo name
Parameter
Description
Dsquery server -hasfsmo
Finds the domain controller in Active Directory

Domain Services (AD DS) that holds the
specified operations master (also known as
flexible single master operations (FSMO)) role.
name
Specifies the Active Directory domain controller

name.
Verifying DNS readiness

During domain rename, the service (SRV) resource records that are associated with the new
domain name that are used by the domain controller Locator (DC Locator) are prepublished in the
authoritative DNS servers by the Net Logon service that is running on the domain controllers of
the domain. For domain controller location to be functional after domain rename, there are a
subset of records whose presence at the authoritative DNS servers is critical for authentication
and replication to take place.
The following table lists the necessary resource records, in order of importance.
Type
Name of owner
Explanation
CNAME
DsaGuid._msdcs.DnsForestName
There must be one alias

(CNAME) resource record
associated with every
domain controller in all
authoritative DNS servers.
This record ensures that
replication will take place
from that domain
controller.
SRV
_ldap._tcp.pdc._msdcs.DnsDomainName
There must be one service

(SRV) resource record that
pertains to the primary
515
domain controller (PDC)

on all authoritative DNS
servers. This record
ensures that
authentication of users
and computers is
functioning.
SRV
_ldap._tcp.gc._msdcs.DnsForestName
There must be at least one

resource record that
pertains to at least one
global catalog server on all
and computers is
functioning. For example,
one DNS server might
contain a record of this
type that is registered by
one gobal catalog, while
other DNS servers might
contain the records of this
type that are registered by
other global catalogss. It is
sufficient, temporarily, if
there is at least one record
of this type that is present
on all authoritative DNS
servers. The other records
will eventually replicate to
all authoritative DNS
servers.
SRV
_ldap._tcp.dc._msdcs.DnsDomainName
There must be at least one

resource record pertaining
to at least one domain
controller on all
and computers is
functioning. For example,
one DNS server might
contain a resource record
516
of this type that is

registered by one domain
controller, while other DNS
servers might contain the
records of this type that
are registered by other
domain controllers. It is
sufficient, temporarily, if
there is at least one record
of this type present on all
The other records will
eventually replicate to all
Note
The word "must" in the context of this table means do notunder any circumstances
proceed with domain rename unless this requirement is fulfilled.
The following two resource records are also required for authentication:
KDC: A service (SRV) resource record that is owned by

_kerberos._tcp.dc._msdcs.DnsDomainName.
GcIpAddress: A host (A) resource record that is owned by _gc._msdcs.DnsForestName.
However, because these resource records are closely linked with the global catalog and the
domain controller service (SRV) resource records that are described in the table, it is sufficient to
confirm the presence of the global catalog and the domain controller service (SRV) resource
records to assume that these two records have also been prepublished.
You can use the DcDiag.exe tool to confirm that the correct service (SRV) resource records that
DC Locator uses have been registered in DNS.
Membership in the Enterprise Admins group in the target forest, or equivalent, is the minimum
To verify DNS records readiness
Dcdiag /test:DNS /DnsRecordRegistration /s:domaincontroller
For more information about dcdiag syntax and parameters, see Dcdiag Syntax
517
Verify Readiness of Domain Controllers

You can use this procedure to verify the readiness of domain controllers for a domain rename
operation. In this procedure, you run a preparatory check on every domain controller in the forest
to verify that the directory database at each domain controller in the forest is in a good state and
ready to perform the directory modifications that are dictated by the domain rename instructions.
You perform the verification by using the Rendom.exe tool to issue a remote procedure call (RPC)
individually to each domain controller in the forest that is tracked by the state file Dclist.xml. The
RPC causes each domain controller to verify that its directory replica is in a good state to perform
the changes that are dictated by the domain rename instructions. For each domain controller that
is successfully verified for readiness, Rendom updates the state field in the corresponding
domain controller entry in the state file Dclist.xml to Prepared (<State>Prepared</State>).
Important
All domain controllers must be in the Prepared state before domain rename instructions
can be run.
Ensure that the following conditions are in effect before you use Rendom.exe to verify that your
domain controllers are ready for the domain rename operation:
The preparatory changes that are made to the Partitions container of the forests domain
naming operations master during the generation of domain rename instructions must have
replicated to every domain controller in the forest. This status is checked for and enforced by
Rendom.exe during this step.
Service (SRV) resource records, which are required for domain controller location of the
renamed domains, must be registered in Domain Name System (DNS) and they must have
replicated to all DNS servers.
Membership in the Enterprise Admins group in the target forest (with write access to the
configuration directory partition) and the Local Administrators group (or write access to the
Note
To verify the readiness of domain controllers in the forest
C:\domren
518
rendom /prepare
4. After the command finishes, examine the state file Dclist.xml to determine whether all
domain controllers achieved the Prepared state. If not, repeat step 2 in this procedure
until all domain controllers achieve the Prepared state.
Note
Each time that it runs, the Rendom tool consults the Dclist.xml state file and, it
does not connect to and verify the domain controllers that are already in the
Prepared state. Therefore, no redundant operations are performed when you run
this command repeatedly.
In a large forest with a large number of domain controllers, it is very likely that all domain
controllers cannot be reached from the control station at the same time. In other words, it is not
likely that all domain controllers that are tracked by the state file Dclist.xml will reach the Prepared
state in a single running of the rendom /prepare command. Therefore, multiple invocations of
this command might be necessary to make incremental progress with groups of domain
controllers that reach the Prepared state at the same time. If you determine thatfor any reason
it is impossible to make any further progress with a specific domain controller, you can remove
the entry for that domain controller (bounded by the <DC></DC> tags) from the Dclist.xml file by
simply editing the state file with a text editor. Remember that, when a domain controller is
removed in this manner from participating in the domain rename procedure, it must be retired
(that is, Active Directory Domain Services (AD DS) must be removed from domain controller) in
the new forest after the domain rename operation is complete.
Note
Make sure that you save a copy of the state file Dclist.xml every time before you edit by
using a text editor. This makes an easy fallback and recovery possible in case you make
an error in editing the file.
As Rendom.exe executes the various command-line options, the command execution log is
cumulatively captured in a log file named Rendom.log (the default name) in the current working
directory (C:\domren). When execution of a Rendom.exe command fails, examination of this log
file can yield valuable information about the actual tasks that the tool performed, and at what
stage or on which domain controller a problem occurred.
Run Domain Rename Instructions

You can use this procedure to execute domain rename instructions. In this procedure, you
execute the domain rename instructions that are contained in the special script that is uploaded
to the msDS-UpdateScript attribute on the Partitions container on every domain controller in the
forest. To execute the script, the control station computer issues a remote procedure call (RPC) to
each domain controller in the forest individually, which causes each domain controller to execute
the domain rename instructions and then restart automatically after it runs the instructions
519
successfully. At the end of this procedure, every domain controller that is tracked by the state file
dclist.xml will be in one of two final states:
Done, which means that the domain controller successfully completed the domain rename
operation.
Error, which means that the domain controller encountered an irrecoverable error and did not
complete the domain rename operation.
In other words, if a domain controller successfully executes the domain rename instructions, it
restarts automatically and its corresponding state for the domain controller entry in the state file is
updated to read <State>Done</State>. But, if a fatal or irrecoverable error is encountered on a
domain controller while you attempt to execute the domain rename instructions, its corresponding
state for the domain controller entry in the state file is updated to read <State>Error</State>. For
the Error state, the error code is written to the last error field <LastError></LastError> and a
corresponding error message is written to the <FatalErrorMsg></FatalErrorMsg> field.
The rendom command must be repeated until all domain controllers have either successfully
executed the domain rename or you have established that one or more domain controllers are
unreachable and will be removed from the forest.
Important
This step will cause a temporary disruption in service while the domain controllers are
running the domain rename instructions and restarting after they run the instructions
successfully. The Active Directory Domain Services (AD DS) service in the forest has not
been disrupted up to this point in the domain rename operation.
Important
All domain controllers in the forest must be in the Prepared state, as indicated by the
state field (<State>Prepared</State>) in the state file Dclist.xml. This state is checked for
and enforced by rendom at this step.
Note
To run the domain rename instructions on all domain controllers
520
C:\domren
rendom /execute
4. When the command has finished running, examine the state file Dclist.xml to determine
whether all domain controllers have reached either the Done state or the Error state.
5. If the Dclist.xml file shows any domain controllers as remaining in the Prepared state,
repeat step 2 in this procedure as many times as necessary until the stopping criterion is
met.
Important
The stopping criterion for the domain rename operation is that every domain
controller in the forest has reached one of the two final states of Done or Error in
the Dclist.xml state file.
Note
Each time that you run it, the rendom /execute command consults the Dclist.xml
state file and skips connecting to the domain controllers that are already in the
Done or Error state. Therefore, no redundant operations are performed if you
repeatedly attempt this command.
If you determine that an error that has caused a domain controller to reach the Error state in the
Cclist.xml file is actually a recoverable error and you think that progress can be made on that
domain controller by trying to run the domain rename instructions again, you can force the
rendom /execute command to run again by issuing the RPC to that domain controller (instead of
skipping it) as described in the following procedure.
To force rendom /execute to reissue the RPC to a domain controller in the Error state
1. On the control station, navigate to the working directory C:\domren, and using a simple
text editor, such as Notepad.exe, open the Dclist.xml file.
2. In the Dclist.xml file, locate the <Retry></Retry> field in the domain controller entry for the
domain controller that you think should be reissued the RPC, and then edit the Dclist.xml
file so that the field reads <Retry>yes</Retry> for that entry.
C:\domren
rendom /execute
Running the rendom /execute command reissues the execute-specific RPC to that
domain controller.
When all the domain controllers are in either the Done or Error state (there should be no domain
controller in the Prepared state), declaring the execution of the domain rename instructions to be
521
complete is at your discretion. You can continue to retry execution attempts on domain controllers
that are in the Error state if you think that they will eventually succeed. However, when you
declare that the execution of the domain rename instructions is:
Complete, and you will not retry the rendom /execute command, you must remove AD DS from
all domain controllers that are still in the Error state. For detailed step-by-step instructions to
remove the AD DS server role, see the Step-by-Step Guide for Windows Server 2008
Active Directory Domain Services Installation and Removal (http://go.microsoft.com/fwlink/?
LinkID=86716).
Note
The Domain Name System (DNS) host names of the domain controllers in the renamed
domains do not change automatically as a result of the domain rename operation. In
other words, the DNS suffix in the fully qualified DNS host name of a domain controller in
the renamed domain will continue to reflect the old domain name. You can use a special
domain controller rename procedure, which you run as a separate post-domain-rename
task, to change the DNS host name of a domain controller so that it conforms to the DNS
name of the domain to which it is joined. For information about renaming domain
controllers, see Renaming a Domain Controller.
Exchange-Specific Steps: Update the

Exchange Configuration and Restart
Exchange Servers
You can use this procedure to update the Exchange configuration and restart Exchange servers
for a domain rename operation. If the domain contains servers running Microsoft Exchange
Server 2003 Service Pack 1 (SP1), before you continue with step 9, run the Exchange Domain
Rename Fix-up Tool (XDR-fixup). Then, restart all the servers running Exchange twice. For more
information, see Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup)
Important
Service Pack 2 (SP2), Exchange Server 2007, or Exchange Server 2007 SP1.
Unfreeze the Forest Configuration

You can use this procedure to unfreeze the forest configuration after a domain rename operation.
After you generated the domain rename instructions (see Generate Domain Rename
Instructions), your forest configuration was frozen with respect to certain types of changes. In this
frozen configuration, addition or removal of domains, addition or removal of domain controllers
522
(DCs), and addition or removal of trusts were not allowed within the forest. For more information,
see Freeze the Forest Configuration.
In this procedure, you use the rendom command to unfreeze the forest so that changes that
were not allowed can once again be made.
Important
All the procedures in Run Domain Rename Instructions, including the automatic domain
controller restart, must have been completed on all domain controllers in the renamed
domains.
Partitions container object) is the minimum required to complete this procedure. Review details
LinkId=83477.
Note
Rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool.
To unfreeze the forest configuration
1. Restart the control station computer twice to ensure that all services that are running on it
learn of the new name (Domain Name System (DNS) name or NetBIOS name) of the
domain of which the control station is a member. Do not restart the control station by
turning its power off and then back on.
C:\domren
rendom /end
The rendom /end command connects to the domain controller that holds the domain
naming operations master role and removes the attribute msDS-UpdateScript on the
Partitions container.

You can use this procedure to re-establish external trusts after a domain rename operation. All
intraforest shortcut trusts within the forest in which the domain rename occurred are automatically
adjusted during the domain rename operation so that they continue to work. However, as a result
of the domain name changes in your forest, any external trust relationships that your forest has
523
with other forests (including trusts across forests) will not be valid. Therefore, they must be reestablished.
In particular, when a domain in your forest is renamed, the following trust relationships are not
valid:
Any interforest trust relationship that is established at the forest root level (a trust across
forests).
Any external trust relationship with a domain in another forest.
All external trusts from or to the forest in which the domain rename operation occurred must be
deleted and recreated. You can use the Active Directory Domains and Trusts Microsoft
Management Console (MMC) snap-in to delete and recreate all such trust relationships. For more
information, see Administering Domain and Forest Trusts.
Fix Group Policy Objects and Links

You can use this procedure to fix Group Policy objects (GPOs) and links after a domain rename
operation. In this procedure, you use the Gpfixup.exe command-line tool to repair GPOs as well
as GPO references in each renamed domain. It is necessary to repair the GPOs and the
Group Policy links after a domain rename operation to update the old domain name that is
embedded in these GPOs and their links. This procedure is necessary so that Group Policy
continues to function normally in the new forest after the domain rename operation is complete.
The Gpfixup.exe tool also repairs any Group Policybased Software Installation and Maintenance
data (such as Software Distribution Point network paths), if they are present in Active Directory
Domain Services (AD DS), so that managed software deployment continues to work in your
environment. The GPO and link fix-up tool must be run once in each renamed domain. There is
no GPO and link fix-up required that corresponds to renamed application directory partitions
because you cannot apply Group Policy to an application directory partition.
Important
The GPO/link fix-up procedure does not fix any interdomain GPO links that might exist in
your forest. Any existing interdomain GPO links must be either removed or reconfigured
so that they can work properly. In addition, this fix-up procedure does not repair network
paths for Software Distribution Points (present in AD DS) that are external to the domain.
As a best practice, do not use GPO links that cross domain boundaries.
Before you repair GPOs, ensure that the following conditions are satisfied:
All procedures that are described in Run Domain Rename Instructions, that include the
automatic domain controller restart, must have been completed on all domain controllers in
the renamed domains.
The domain controller with the primary domain controller (PDC) emulator operations master
role in a renamed domain must have successfully completed the domain rename operation,
and it must have reached the final "Done" state as described in Run Domain Rename
Instructions.
524
The control station computer must have been restarted twice, as described in Unfreeze the
Forest Configuration.
All member servers in the domain that host Software Distribution Points (network locations
from which users deploy managed software in your environment) must have been restarted
twice, as described in Run Domain Rename Instructions. This prerequisite step is extremely
important and necessary for the Software Installation and Maintenance data fix-up to work
correctly.
Membership in the Enterprise Admins group in the target forest is the minimum required to
complete these procedures. The access check that you perform in this procedure requires that
you have write access to the gpLink attribute on the site, domain, and organizational unit (OU)
objects, as well as write access to the GPOs themselves.
Note
gpfixup, as described in Appendix B: Command-Line Syntax for the Gpfixup Tool.
To fix up GPOs and GPO references
C:\domren
3. From within the working directory, type the following command, and then press ENTER.
The entire command must be typed on a single line, although it is shown on multiple lines
for clarity.
gpfixup /olddns:OldDomainDnsName
/newdns:NewDomainDNSName
/oldnb:OldDomainNetBIOSName
/newnb:NewDomainNetBIOSName
/dc:DcDnsName 2>&1 >gpfixup.log
Note
The command-line parameters /oldnb and /newnb are required only if the
NetBIOS name of the domain changed. Otherwise, you can omit these
parameters from the command line for Gpfixup.
The output of the commandboth status or error outputis saved to the file Gpfixup.log,
which you can display periodically to monitor the progress of the command.
4. To force replication of the Group Policy fix-up changes that are made at the domain
controller that is named in DcDNSName in step 3 of this procedure to the rest of the domain
controllers in the renamed domain, type the following command, and then press ENTER:
repadmin /syncall /d /e /P /q DcDnsName NewDomainDN
525
Where:
DcDnsName
NewDomainDN
is the Domain Name System (DNS) host name of the domain controller
that was targeted by the gpfixup command.
is the distinguished name that corresponds to the new DNS name of the
renamed domain.
5. Repeat steps 2 and 3 in this procedure for every renamed domain. You can enter the
commands in sequence for each renamed domain.
For example, using the sample forest and domain name changes in Specify the New
Forest Description, you run the gpfixup command twiceonce for the renamed
cohovineyard.com domain and once for the sales.cohovineyard.com domain, as
indicated in the following example:
gpfixup /olddns:cohovineyard.com
/oldnb:cohovineyard
/newdns:cohowinery.com
/newnb:cohowinery
/dc:dc1.cohovineyard.com
2>&1 >gpfixup1.log
repadmin /syncall /d /e /P /q dc1.cohovineyard.com dc=cohowinery,dc=com

gpfixup /olddns:sales.cohovineyard.com
/dc:dc3.sales.cohovineyard.com
/newdns:sales.cohowinery.com
2>&1 >gpfixup2.log
repadmin /syncall /d /e /P /q dc3.sales.cohovineyard.com

dc=sales,dc=cohowinery,dc=com
Important
Run the gpfixup command only once for each renamed domain. Do not run it for
renamed application directory partitions.
Note
The DNS host names for the domain controllers in the renamed domains that are
used in these command invocations still reflect the old DNS name for the
domain. As mentioned earlier, the DNS host name of a domain controller in a
renamed domain does not change automatically as a result of the domain name
change.
Parameter
Description
gpfixup
Fixes domain name dependencies in

Group Policy objects and Group Policy links
after a domain rename operation.
/olddns:OldDomainDnsName
Specifies the old DNS name of the renamed

domain.
/newdns:NewDomainDNSName
Specifies the new DNS name of the renamed

domain.
526
Parameter
Description
/oldnb:OldDomainNetBIOSName
Specifies the old NETBIOS name of the

renamed domain.
/newnb:NewDomainNetBIOSName
Specifies the new NETBIOS name of the

renamed domain.
/dc:DcDnsName 2>&1 >gpfixup.log
Contains status or error output of the command.
Completing the Domain Rename Operation

This task provides information and procedures for completing the domain rename operation. After
you complete the domain rename procedures in Performing the Domain Rename Operation,
complete the instructions in this task to be sure that all functionality that relies on the accurate
domain name has been addressed with any needed related tasks.
Task requirements
Rendom.exe
Verify Certificate Security
Perform Miscellaneous Tasks
Back Up Domain Controllers
Restart Member Computers
Exchange-Specific Steps: Verify the Exchange Rename and Update Active Directory
Connector
Perform Attribute Cleanup
Rename Domain Controllers

You can use this procedure to verify certificate security after you complete a domain rename
operation. If you use enterprise certificates, perform all the following procedures after the domain
rename operation is complete.
527
Preparing URLs for CRL distribution point and

Authority Information Access (AIA) extensions
after a domain rename
To ensure that the old certificates function properly after a domain rename operation, make an
alias (CNAME) resource record Domain Name System (DNS) entry that redirects the old
Hypertext Transfer Protocol (HTTP) server (that services the Certificate Revocation List (CRL) of
the certification authority (CA)) name query to the new DNS name for the server. This redirection
causes the HTTP URLs in the old certificates to be valid. Client computers can then obtain CRLs
and CA certificates for verification.
Note
You can remove the alias (CNAME) resource record after you know that the existing
certificates have been renewed.
Note
If you only have Lightweight Directory Access Protocol (LDAP) URLs in the certificates,
all the previously issued certificates will no longer be validated. The only workaround for
correcting the LDAP CRL distribution point and AIA pointers is to renew the entire CA
hierarchy and reissue the End Entity certificates. Expect public key infrastructure (PKI)
downtime until these issues are resolved.
Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is
the minimum required to complete this procedure. Review details about using the appropriate
To configure the redirecting alias DNS entry
1. Open the DNS Manager snap-in. To open DNS Manager, click Start, click
Administrative Tools, and then click DNS.
2. In the console tree, expand the DNS server node, and locate the old DNS zone.
3. Right-click the old DNS zone, and then click New Alias (CNAME).
4. In Alias name, type the original fully qualified domain name (FQDN) of the HTTP server.
5. In Fully qualified domain name for target host, type the new FQDN of the HTTP
server, and then click OK.
At this point you can test the redirection by pinging the FQDN of the old HTTP server. The ping
should be remapped to the new FQDN of the HTTP server.
Verifying the use of UPNs

Authentication protocols, such as Kerberos (Smart Card Logon), require the user principal name
(UPN) in the user certificate to match the UPN in the user account (implicitly or explicitly) in
Active Directory Domain Services (AD DS). You should be aware of the differences in behavior
between implicit and explicit UPNs.
528
Implicit UPN: If a user account in AD DS does not have an explicitly assigned value for its
UPN attribute, it is assumed to have an implicit UPN for authentication purposes that is based
on the DNS name of the domain in which the account exists. When the DNS name of a
domain changes as a result of the domain rename operation, the implicit UPNs of all user
accounts in the domain also change. Both the old and the new implicit UPN forms will be
accepted for authentication until the attribute cleanup procedures are complete (see Perform
Attribute Cleanup). After the attribute cleanup procedures are complete, only the new implicit
UPN form will be accepted.
Note
This behavior implies that if you want to continue using implicit UPNs for user
accounts, you must reissue all existing authentication certificates after the DNS name
of a domain has changed and before you perform the attribute cleanup procedures.
Explicit UPN: If a user account in AD DS has an explicitly assigned value for its UPN
attribute, it is said to have an explicit UPN that can be used for authentication purposes.
When the DNS name of a domain changes as a result of the domain rename operation, the
explicit UPNs of user accounts in the domain are not affected. Therefore, if you are using
explicit UPNs for user accounts, no maintenance is necessary after the domain rename
operation.
Enabling certificate enrollment in a renamed

domain
To enable certificate enrollment using either autoenrollment or the Certificates Microsoft

Management Console (MMC) snap-in in the new domain, you have to make a small change
in AD DS to the Enrollment Services Container in the configuration directory partition
(cn=Enrollment Services,cn=Public Key Services,
cn=Services,cn=Configuration,dc=ForestRootDomain). The CA object in this container has a
dNSHostName attribute that still contains the old DNS name of the CA computer. You can
use the following Microsoft Visual Basic script to change the value of this attribute, as
follows:
Container = LDAP://CN=YOURCA,CN=Enrollment Services,CN=Public Key Services,
CN=Services,CN=Configuration,DC=YoursubDomain,DC=YourDomain,DC=com
Set obj = GetObject(container)
Obj.dnshostname = NEWDNSNAMEOFTHECAMACHINE
Obj.setinfo
Note
You must perform this procedure for all the CAs in your domain. Also note that the
container name depends on your domain configuration.
You must also change the registry on the CA computer to reflect the new DNS name for the
CA computer.
529
Caution
Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent,
is the minimum required to complete this procedure. Review details about using the
appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
To update the DNS name of the CA computer
1. On the CA computer, click Start, click Run, type regedit to open the Registry Editor,
and then locate the entry CAServerName under
HKLM\System\CurrentControlSet\CertSvc\Configuration\YourCAName.
2. Change the value in CAServerName to correspond to the new DNS host name.
To enable proper Web enrollment for the user, you must also update the file that is used by
the Active Server Pages (ASPs) for Web enrollment. The following change must be made on
all the CA computers in your domain.
Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent,
is the minimum required to complete this procedure. Review details about using the
appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
To update the Web enrollment file
1. On the CA computer, search for the Certdat.inc file. If you have used default
installation settings, this file should be located in %windir%\system32\certsrv
directory.
2. Open the file, which appears as follows:
<%' CODEPAGE=65001 'UTF-8%>
<%' certdat.inc - (CERT)srv web - global (DAT)a
' Copyright (C) Microsoft Corporation, 1998 - 1999 %>
<%' default values for the certificate request
sDefaultCompany=""
sDefaultOrgUnit=""
sDefaultLocality=""
sDefaultState=""
sDefaultCountry=""
' global state

sServerType="Enterprise" 'vs StandAlone
530
sServerConfig="OLDDNSNAME\YourCAName"
sServerDisplayName="YourCAName"
nPendingTimeoutDays=10
3. Change the SServerConfig entry so that it has the NewDNSName of the CA

computer.
If the CA was installed with the shared folder option (which is available only if the server was
upgraded to Windows Server 2008from Windows Server 2003), the file Certsrv.txt (under the
shared folder) should be edited to reflect the new DNS name of the CA computer. Save a
copy of this file before you edit it, open the file by using Notepad.exe, make the change to the
DNS name of the CA computer, and then save the file.
If you have a Web proxy computer (for CA Web pages) whose DNS host name changed as a
result of the domain rename operation, you have to make changes to the following registry
key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
Under this key there is a value named WebClientCAMachine that holds the DNS name of
the CA computer. Change this value to correspond to the new DNS name.
To update the Netscape revocation check mechanism
On all computers where Web pages for the CA reside (for example, on the Web proxy and
the CA computers) there is a file named nsrev_CANAME.asp that contains the DNS host
name of the CA computer that is used by the Netscape revocation checking mechanism.
Search for this file, and change the DNS host name of the CA computer that is embedded in
the file.
If you have used the default installations settings, this file will be in the folder %Windir
%\system32\certsrv\certenroll and its content looks like the following.
<%
Response.ContentType = "application/x-netscape-revocation"
serialnumber = Request.QueryString
set Admin = Server.CreateObject("CertificateAuthority.Admin")
stat = Admin.IsValidCertificate("CAMachineDnsHostname\CANAME", serialnumber)
if stat = 3 then Response.Write("0") else Response.Write("1") end if
%>
Open this file with Notepad.exe, and change CAMachineDnsHostName to correspond to the
new DNS host name.
531
Verifying the validity of CRL distribution point and

AIA extensions
CRL distribution point and AIA extensions can be hard coded. Therefore, the extension URLs will
not reflect the new DNS name of the CA computer. First, check to see whether the extensions are
hard coded, and, if they are, you must change the URL to reflect the new DNS name.
You must perform this procedure on every CA computer in each renamed domain.
The Manage CA permission on the CA computer is the minimum required to complete this
procedure. Manage CA is a special privilege that you can configure with the Certification
Authority snap-in.
To check whether the CRL distribution point and AIA extensions are flexible
1. Open the Certification Authority snap-in. To open Certification Authority, see Add the
Certificates Snap-in to an MMC (http://go.microsoft.com/fwlink/?LinkId=124114).
2. Right-click the CA name, and then click Properties.
3. On the Extensions tab, check the flexibility of the CRL distribution point and AIA
extensions, as follows:
a. Flexible extensions have the following format:
http://<ServerDNSName>/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowe
d>.crl
b. Hard-coded extensions have the following format:
http://mydnsname.mycompanyname.com/certenroll/<CAName><CRLNameSuffix><
DeltaCRLAllowed>.crl
4. If the CRL distribution point and AIA extensions are flexible, you do not have to change
the extensions.
5. If the CRL distribution point and AIA extensions are not flexible, change the extension
URLs to reflect the new DNS name of the CA computer.
6. Repeat this procedure for every CA computer in the domain.
Renewing subordinate and issuing CA certificates

After all the preceding CA-related procedures have been performed on all CA computers, you can
renew certificates to update the CRL distribution point and AIA locations in the CA certificate.
Renew all subordinate and issuing CA certificates in hierarchical order. In addition, update Group
Policy on all the computers to ensure that they have new root CA certificates.
Publish new CRLs

To publish new Delta and Base CRLs, run the following command on all the CA computers in the
renamed domain:
Certutil.exe crl
532
Updating domain controller certificates

The domain controller certificates have to be updated so that any authentication mechanism that
is based on certificates (for example, replication and Smart Card through Kerberos) continues to
work. To update these certificates, if template-based autoenrollment is set before the domain
rename operation, increment the version number for Domain Controller Authentication and
Directory E-mail Replication Certificate templates to force re-enrollment. Otherwise, use Group
Policy to set Machine Based Autoenrollment. The domain controllers will re-enroll and supersede
the existing V1 Domain Controller Certificate.
You might also want to increase the version number on other templates (particularly the templates
that are related with authentication) to set autoenrollment for the users and their computers.
Fix Cross and Qualified Subordination Certificates and name constraints. For more information,
see Planning and Implementing Cross-Certification and Qualified Subordination Using
Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkID=123176).
Changing the user identity for the NDES add-on

If the Network Device Enrollment Services (NDES) add-on for Microsoft Certificate Services is
installed, you might have to change the identity of the user under whose context the NDES
process was created. For example, if NDES was originally running with the identity
OriginalDomainName\UserName, after domain rename operation, Internet Information Services
(IIS) will attempt to start the process with the same identity. (The IIS metabase is not altered
during the domain rename operation.) You can change this identity in IIS.
To change the user identity for NDES in IIS
1. In the IIS MMC snap-in, browse to Application pools.
2. Under Application pools, right-click the folder for NDES, and then click Properties.
3. On the Identity tab, change the identity for NDES to correspond to the new domain
name.

You can use this procedure to perform miscellaneous tasks after a domain rename procedure.
There are a number of miscellaneous follow-up tasks that you have to perform after the core
domain rename tasks are complete. There is no particular order in which these tasks have to be
performed.
Publish service connection points for renamed TAPI-specific application directory

partitions.
If you renamed Telephony Application Programming Interface (TAPI)specific application
directory partitions as part of specifying the new forest description procedure (Specify the
533
New Forest Description), you have to publish service connection points in Active Directory
Domain Services (AD DS) for the new name of the application directory partition so that TAPI
clients can locate it. At the same time, you can remove the service connection points for the
old name of the application directory partition.
For example, suppose that you had a TAPI-specific application partition named
mstapi.cohovineyard.com that was configured for the domain cohovineyard.com. As a result
of the Domain Name System (DNS) name of the domain changing to cohowinery.com, you
renamed the corresponding application directory partition to mstapi.cohowinery.com during
the domain rename operation.
You should now remove the service connection point for the old application directory partition
name mstapi.cohovineyard.com by running the following command from a command prompt
on the control station computer:
tapicfg removescp /directory:mstapi.cohovineyard.com /domain:cohowinery.com
Then, publish a service connection point for the new application directory partition name
mstapi.cohowinery.com by running the following command from a command prompt on the
control station:
tapicfg publishscp /directory:mstapi.cohowinery.com /domain:cohowinery.com
/forcedefault
Orchestrate password reset for Digest authentication.

A Digest authentication mechanism uses the DNS domain name as the realm, which is then
used to precompute the Digest user password hash that is stored in AD DS. If you are using
Digest authentication in a domain that was renamed by the domain rename operation, a user
in that domain will not be able to use Digest authentication until the user password is
changed.
If you are using Digest authentication in a domain that is renamed, you must do something to
cause a password reset to occur. For example, you could do the following:
After you complete all the procedures in Run Domain Rename Instructions, (the domain
rename instructions have all been followed and domain controllers have restarted in a
renamed domain), expire all user passwords by changing domain password policy in the
renamed domain.
Send out e-mail that warns users that they must change their passwords immediately
after they reboot their computers twice (as described in Restart Member Computers).
Users change their passwords by pressing Ctrl+Alt+Del.
Remove any redundant interdomain trusts within your forest.

If you performed a forest restructure operation in which the existing domains were rearranged
into a different tree structure, you would have created the necessary shortcut trusts to
preserve complete trust between all the domains in your new forest, as described in "PreCreating Parent-Child Trust Relationships for a Restructured Forest" in Create Necessary
Shortcut Trust Relationships. This type of a restructure can result in one or more parent-child
or tree-root trust relationships remaining in your forest that reflect the old domain structure
and are no longer required. Although their presence does no harm, you can use the
534
Active Directory Domains and Trusts snap-in to remove these redundant trust relationships
after the domain rename operation is complete. For more information, see Active Directory
Domains and Trusts (http://go.microsoft.com/fwlink/?LinkId=124088).
Fix Start menu shortcuts for Domain Security Policy and Domain Controller Security
Policy Microsoft Management Console (MMC) snap-ins.
1. Click Start, click Programs, and then click Administrative Tools.

2. Right-click Domain Security Policy, and then click Properties.
3. Modify the Target field to replace the old distinguished name of the domain that
appears as part of the /gpobject: parameter with the new distinguished name of the
domain.
4. Click OK.
Note
For example, if you renamed the domain cohovineyard.com to
cohowinery.com, the /gpobject: parameter will have to be changed from
/gpobject:"LDAP://CN={31B2F340-016D-11D2-945F00C04FB984F9},CN=Policies,CN=System,DC=cohovineyard,DC=com" to
/gpobject:"LDAP://CN={31B2F340-016D-11D2-945F00C04FB984F9},CN=Policies,CN=System,DC=cohowinery,DC=com".
5. To fix the Domain Controller Security Policy snap-in shortcut, follow steps 1 through 4
above, but select Domain Controller Security Policy in step 2.
Note
For example, if you renamed the domain msn.com to msnzone.com, the
/gpobject: parameter will have to be changed from /gpobject:"LDAP://CN=
{6AC1786C-016F-11D2-945F00C04fB984F9},CN=Policies,CN=System,DC=cohovineyard,DC=com" to
/gpobject:"LDAP://CN= {6AC1786C-016F-11D2-945F00C04fB984F9},CN=Policies,CN=System,DC=cohowinery,DC=com".
Remove the Group Policy to set primary DNS suffix of member computers in renamed
domains.
If you followed the recommendations to avoid excess replication due to member computers
being renamed in a large domain, as described in "Configuring Member Computers for Host
Name Changes in Large Deployments" in Configure Member Computers for Host Name
Changes, you might have configured and applied a Group Policy setting Primary DNS Suffix
to member computers in your renamed domains. Because the intended purpose of this Group
Policy setting has now been served, it can be removed. To remove this Group Policy setting,
follow steps 1 through 5 of the procedure "Apply Group Policy to Set the Primary DNS Suffix"
in Configure Member Computers for Host Name Changes, click Disabled, and then click OK.
Remove DNS zones that are no longer needed.

535
As a result of the domain DNS name changes that occurred during the domain rename
operation, some of the DNS zones in your DNS infrastructure might no longer be necessary.
For example, if there was a DNS zone with a name that matched the old DNS name of a
renamed domain, there might be no more DNS resource records (service (SRV), host (A),
and pointer (PTR) resource records) with the old domain suffix that have to be registered with
DNS. In this case, you can remove these DNS zones that are no longer necessary.

You can use this procedure to back up domain controllers after a domain rename operation. As a
result of the domain rename operation, the content of the Active Directory database, system
registry, and Group Policy objects (GPOs) on the domain controllers change. Therefore, the
existing backups that you have taken for the domain controllers are no longer valid.
Back up system state

Perform a full system state backup of all domain controllers in the forest so that you have a
recoverable backup state. For more information, see the Step-by-Step Guide for
Windows Server 2008 Active Directory Domain Services Backup and Recovery
Back up GPOs
If you use Group Policy, consider installing the Group Policy Management Console (GPMC).
For more information, see GPMC (http://go.microsoft.com/fwlink/?LinkID=123307). GPMC
makes Group Policy easier to use, and it adds functional improvements such as the ability to
back up GPOs independently of the rest of Active Directory Domain Services (AD DS). GPOs
that you back up with GPMC before the domain rename operation cannot be restored after
domain rename. Therefore, we recommend that after a domain rename operation, you use
GPMC to back up all the GPOs again.
Note
Saved GPMCs for a domain will no longer work after you rename a domain. If you
want to use saved GPMCs, you have to re-create them after the domain rename
operation.

You can use this procedure to restart member computers after a domain rename operation. After
the domains are renamed, you have to create a process by which all member computers in the
renamed domains in your forest recognize and propagate the domain name changes to all
applications and services that are running on member computers. You can do this by notifying all
users to restart their computers (the member computers) to cause those computers to pick up the
domain name changes.
536
Important
When the member computers are restarted, their Domain Name System (DNS) host
names will also change after the restart as a result of the fact that their primary DNS
suffix changes as a result of the name change of the domain of which they are members.
The primary DNS suffix of a member computer in an Active Directory domain is, by
default, configured to change automatically when domain membership of the computer
changes. If you have very large domains whose DNS name was changed by the domain
rename operation and these domains have a large number of member computers, you
might observe a large replication storm and a surge in network traffic as a result of the
member computer restarts. For information about how to avoid excess replication under
these conditions, see Configure Member Computers for Host Name Changes.
Perform the following tasks after the domain rename operation:
Restart all member computers twice.

Restart twice all member workstations, member servers, and standalone servers (excluding
domain controllers) that are running Windows 2000, Windows XP, Windows Server 2003, and
Windows Server 2008 in the renamed domains in your forest. When you restart these
computers twice, this ensures that each member computer learns of the domain name
changes and propagates the changes to all applications and services that are running on the
member computer.
Note
Each computer must be restarted by logging into the computer and by using the
Shutdown/Restart administrative option. Computers must not be restarted by turning
off the computers power and then turning it back on.
Note
Member computers on a wired local area network (LAN) can simply be restarted
twice. Member computers on a wireless LAN should be connected to a wired network
while you perform the two required restarts. If that is not possible, eject the wireless
network card and then reinsert it after logon before each restart.
Unjoin and then join any remote computers that connect to the renamed domain
through a remote connection, such as dial-up and virtual private network (VPN).
If there are any remote computers that are members of a renamed domain that connect to the
domain through remote connection mechanisms such dial-up lines or VPNs, you will have to
unjoin each member computer from the old domain name and then rejoin it to the new
domain name.
537
Exchange-Specific Steps: Verify the

Exchange Rename and Update Active
Directory Connector
You can use this procedure to verify the Exchange rename and update the Active Directory
Connector after a domain rename operation. If the domain contains Exchange Server 2003
Service Pack 1 (SP1) servers, follow the steps to verify the Exchange rename and update
Active Directory Connector. For more information, see Microsoft Exchange Server Domain
Rename Fixup (XDR-Fixup) (http://go.microsoft.com/fwlink/?LinkID=123322).
Important
Service Pack 2 (SP2), Exchange Server 2007, or Exchange Server 2007 SP1.

You can use this procedure to perform attribute cleanup after a domain rename operation. This
post-domain-rename cleanup procedure removes all values of the msDS-DnsRootAlias and
msDS-UpdateScript attributes from Active Directory Domain Services (AD DS) that were written
during the domain rename operation.
Important
Perform this cleanup procedure only after all member computers in the renamed domains
have been restarted as described in Restart Member Computers. If smart card logon is
used in your environment, make sure that all authentication certificates have been
renewed before this step; otherwise, authentication will start to fail for the certificates.
Note
To perform attribute cleanup after a domain rename
538
C:\domren
rendom /clean
The rendom /clean command removes the values for the msDS-DnsRootAlias and
msDS-UpdateScript attributes from AD DS by connecting to the domain controller that
has the domain naming operations master role.
After the steps in this procedure are complete, the new forest is ready for another domain rename
(or forest restructuring) operation, if necessary.

You can use this procedure to rename domain controllers after a domain rename operation.The
Domain Name System (DNS) host names of the domain controllers in the renamed domains do
not change automatically as a result of the domain rename operation. In other words, the DNS
suffix in the fully qualified DNS host name of a domain controller in the renamed domain
continues to reflect the old domain name. You can change the DNS host name of domain
controllers in a renamed domain at a later time by using a special procedure.
Modification of the computer name causes updates to the DNS and Active Directory databases.
The computer performs these updates automatically. After the updated data propagates to the
DNS servers and Active Directory domain controllers that a client computer uses, the client
computer can locate and authenticate to the renamed domain controller computer. However, DNS
and Active Directory replication latency (the time that it takes for the name change to replicate
throughout the databases) might cause a temporary inability of clients to locate or authenticate
the renamed domain controller. Therefore, renaming a mission-critical server, such as a domain
controller, requires that you follow a computer rename preparation procedure before you rename
the domain controller. This preparation procedure ensures that there will be no interruption in the
ability of client computers to locate or authenticate the renamed domain controller. For more
information about how to rename a domain controller, see Renaming a Domain Controller.
Note
If your forest contains Exchange 2003 Service Pack 1 (SP1) servers, and you chose to
rename domain controllers, you must perform several Exchange-specific steps to update
the Recipient Update Service and DSAccess registry keys. For more information, see
Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup)
539
Additional Resources for the Domain

Rename Operation
For more information about the Active Directory domain rename operation, see the following
resources:
Appendix A: Command-Line Syntax for the Rendom Tool
Appendix B: Command-Line Syntax for the Gpfixup Tool
Appendix C: Checklists for the Domain Rename Operation
Appendix D: Worksheets for the Domain Rename Operation
Appendix A: Command-Line Syntax for the

Rendom Tool
The Rendom command-line tool collects forest-wide information, monitors domain rename status,
and performs the actions that are necessary to complete a domain rename operation in your
forest.
Syntax
rendom [/?] [/dc:{DCNAME | DOMAIN}]
[/user:USERNAME] [/pwd:{PASSWORD|*}]
[/list] [/upload] [/prepare] [/execute] [/end] [/clean]
[/showforest] [/listfile:LISTFILE] [/statefile:STATEFILE]
[/logfile:LOGFILE]
Parameter
Description
/?
Optional. Displays the Help and the version

number of the tool.
/dc:{DCNAME | DOMAIN}
Optional. Specifies that the command connect

to a specific domain controller, indicated by
DCNAME (a Domain Name System (DNS)
name or a NetBIOS name), to run the operation
that is specified by one of the operation
switches: /list, /upload, /prepare, /execute, or
/clean. If the name of a domain is specified
instead as DOMAIN, the command connects to
a domain controller in that domain. Default:
When this switch is not specified, connects to
any domain controller in the domain to which
540
Parameter
Description
the computer on which this command is being

run belongs.
If this command is run on a computer that is not
a member of any domain, the /dc switch is
required; otherwise, an error is returned.
/user:USERNAME
Optional. Requests that the command run in the

security context of a specific user, indicated by
USERNAME, that is different from the logged
on user. USERNAME can currently be in only
one form: domain\user, for example,
ntdev\jdow.
/pwd:{PASSWORD | *}
Optional. Specifies the password for the

alternate security context indicated by
USERNAME. If the value that is specified for
this switch is *, the command prompts for the
password to allow hiding of the password.
/list
This operation creates a list of the directory

partitions in the forest. The list is written as text
to a file using an XML format. Therefore, this
command creates a textual description of the
forest structure using a structured XML format.
If a file name is specified with the /listfile
switch, below, the forest description is written
into that file. If no file name is specified, the
forest description is written to a file named
DOMAINLIST.XML in the current directory from
which this command is run. If the specified file
already exists, it is renamed and a new file is
created.
/upload
Performs the following functions:

Based on the new forest description that is
provided in the file that is created by the /listfile
switch (or the file DOMAINLIST.XML in the
current directory, by default), this operation
generates an instructions file in the form of a
special script that will run later on every domain
controller in the forest. The instructions file is
not a file that is stored on the disk.
Writes the autogenerated script (instructions
file) to the msDS-UpdateScript attribute of the
541
Parameter
Description
Partitions container on the domain controller

that holds the domain naming operations
master role.
Sets the msDS DnsRootAlias attribute on the
crossRef object that corresponds to every
domain that is being renamed.
Writes a new state file, indicated by the
/statefile switch (or the file DCLIST.XML in the
current directory, by default), to track the state
of every domain controller in the forest. All
domain controllers are marked to be in the
Initial state. If the specified file already exists, it
is renamed and a new file is created.
The forest configuration is frozen for certain
types of operations after successful completion
of this command.
/prepare
Attempts to contact every domain controller in

the forest (as tracked by the state file), and
verifies the following:
The correct instructions file (the special script
that is uploaded by the /upload operation) has
replicated to the domain controller.
The changes that are dictated by the
instructions file are consistent with the contents
of the directory partition replicas that the
domain controller holds.
The domain controller has authorized the
running of the domain rename operation.
After successful verification of the previous
conditions on a given domain controller, the
corresponding state for that domain controller is
advanced to the Prepared state in the state file.
/execute
Attempts to contact every domain controller in

the forest (as tracked by the state file), and
executes the changes that the instructions file
dictates to cause the actual domain rename to
occur.
After successful execution of the instructions file
on a given domain controller, the corresponding
state in the state file for that domain controller is
542
Parameter
Description
advanced to Donea final state that indicates

that the restructuring is finished on that domain
controller. If an irrecoverable error occurs on a
given domain controller, the corresponding state
in the state file for that domain controller is set
to Erroralso a final state, that indicates that
the domain controller is not functioning and that
it must have Active Directory removed. (That is,
it can no longer be used as a domain
controller.)
The state file that this operation uses is the
state file that is specified by the /statefile switch
(or the file DCLIST.XML in the current directory,
by default).
/end
Attempts to contact the domain controller that

holds the domain naming operations master
role of the forest, and removes the msDSUpdateScript attribute on the Partitions
container.
After successful removal of this attribute on the
domain naming master, this operation returns a
SUCCESS summary status message. The
forest configuration, which was frozen for
certain types of operations that follow the
/upload operation, is now unfrozen.
/clean
Attempts to contact the domain controllers that

holds the domain naming operations master
role of the forest, and performs the following
functions:
Removes all values of the msDSDnsRootAlias attribute on all crossRef objects
in the Partitions container.
Removes the msDS-UpdateScript attribute on
the Partitions container.
After successful removal of these attributes on
the domain naming master, this operation
returns a SUCCESS summary status message.
/showforest
Requests that the forest description, which is

represented by the list of its directory partitions
and their hierarchy), that is contained in the list
543
Parameter
Description
file be displayed in a user-friendly format with

indentation that reflects the domain hierarchy.
The list file will typically have been generated
by the /list operation of this command.
If a file name is specified with the /listfile
switch, below, the forest description is read from
that file. If no file name is specified, the forest
description is assumed to be in a file named
which this command is being run. If the
specified file (or the default file) does not exist,
an error is reported with an indication to run the
/list operation first.
/listfile:LISTFILE
Optional. Specifies that LISTFILE is the name

of the file that holds the forest description. The
list file contains a list of the directory partitions
in the forest that is written as text in an XML
format. You can use this switch to specify the
output file for the /list operation or the input file
for the /upload operation.
If this switch is not specified, the forest
description is assumed to be in a file named
which this command is being run.
/statefile:STATEFILE
Optional. Specifies that STATEFILE is the name

of the file that is used to track the state of each
domain controller in the forest during the
domain rename operation. The state file
contains a list of all the domain controllers in the
forest and their corresponding states that is
written as text in an XML format. You can use
this switch to specify the state file for the
/upload, /prepare, and /execute operations.
If this switch is not specified, the state of the
domain controllers is assumed to be in a file
that is named DCLIST.XML in the current
directory from which this command is being run.
/logfile:LOGFILE
Optional. Specifies that LOGFILE is the name

of the file that is used to write the execution log
of the command as any operation runs. The
544
Parameter
Description
contents of the log file varies, depending on

which operation (/list, /upload, /prepare,
/execute, /clean) is running.
If this switch is not specified, the execution log
is written to a file named RENDOM.LOG in the
current directory from which this command is
being run.
Appendix B: Command-Line Syntax for the

Gpfixup Tool
You can use the gpfixup command-line tool to fix the dependencies that Group Policy objects
(GPOs) and Group Policy links in Active Directory Domain Services (AD DS) have on Domain
Name System (DNS) and NetBIOS names after a domain rename operation.
Syntax
gpfixup [/?] [/v] [/dc:DCNAME]
[/user:USERNAME] [/pwd:{PASSWORD|*}]
[/olddns:OLDDNSNAME] [/newdns:NEWDNSNAME]
[/oldnb:OLDFLATNAME] [/newnb:NEWFLATNAME]
[/sionly]
Parameter
Description
/?
Optional. Displays the Help syntax and the

version number of the tool.
/v
Optional. Requests that detailed status

messages be displayed. In the absence of this
switch, only error messages or a brief summary
status message of SUCCESS or FAILURE
appears.
/olddns:OLDDNSNAME
Optional. When the domain rename operation

changes the DNS name of a domain, this switch
specifies the old DNS name of the renamed
domain as OLDDNSNAME, (for example,
olddom.contoso.com. You can use this switch if
and only if you also use the /newdns switch to
provide a new domain DNS name.
545
Parameter
Description
/newdns:NEWDNSNAME

changes the DNS name of a domain, this switch
specifies the new DNS name of the renamed
domain as NEWDNSNAME, for example,
newdom.contoso.com. You can use this switch
to specify the new domain DNS name if and
only if you use the /olddns switch to provide the
old domain DNS name.
/oldnb:OLDFLATNAME

changes the NetBIOS name of a domain, this
switch specifies the old NetBIOS name of the
renamed domain as OLDFLATNAME, for
example, olddom. You can use this switch if and
only if you use the /newnb switch to provide a
new domain NetBIOS name.
/newnb:NEWFLATNAME

changes the NetBIOS name of a domain, this
switch specifies the new NetBIOS name of the
renamed domain as NEWFLATNAME, for
example, newdom. You can use this switch to
specify the new NetBIOS name of the domain if
and only if you use the /oldnb switch to provide
the old NetBIOS name of the domain.
/sionly
Optional. Requests that only the Group Policy

fix that relates to managed software installation
(that is, the SI extension for Group Policy) be
performed. Skips the actions that fix up the
Group Policy links and the SYSVOL paths in the
GPOs.
/dc:DCNAME
Optional. Requests that the command connect

to a specific domain controller, indicated by
DCNAME (a DNS name or a NetBIOS name),
to run the fix-up operation. If DCNAME is
specified, it must host a writable replica of the
domain directory partition, as indicated by either
of the following:
The DNS name NEWDNSNAME, using
/newdns
The NetBIOS name NEWFLATNAME, using
/newnb
546
Parameter
Description
Default: When this switch is not specified,

connects to any domain controller in the
renamed domain, as indicated by either
NEWDNSNAME or NEWFLATNAME. You can
use the function DsGetDcName() to obtain a
proper domain controller for the given domain.
/user:USERNAME
Optional. Requests that the command run in the

security context of a specific user, indicated by
USERNAME, that is different from the logged
on user. USERNAME can currently be specified
in only one form: domain\user, for example,
ntdev\jdow.
/pwd:{PASSWORD | *}
Optional. Specifies the password for the

alternate security context that is indicated by
USERNAME. If the value that is specified for
this switch is *, the command prompts for the
password to allow hiding of the password.
Appendix C: Checklists for the Domain

Rename Operation
This appendix provides checklists for the tasks to be performed during the various phases of the
Complete the tasks in these checklists in the order in which they are presented. If a reference link
takes you to a conceptual topic, return to the checklist after you review the conceptual topic so
that you can proceed with the remaining tasks.
Satisfying domain rename requirements

This checklist provides the list of requirements that must be met before you can begin a domain
rename operation.
Checklist: Satisfying domain rename requirements
Task
Reference
Adjust the forest functional

level.
For more information about forest functional

levels and for procedures to determine and set
You can rename domains only forest functional levels, see Enabling
547
Task
Reference
in a forest in which all the

Windows Server 2008 Advanced Features for
domain controllers are running Active Directory Domain Services
Windows Server 2008
Standard or
Windows Server 2003
Standard Edition, Windows
Server 2008 Enterprise or
Windows Server 2003
Enterprise Edition, or
Windows Server 2008
Datacenter or
Windows Server 2003
Datacenter Edition operating
systems, and the
Active Directory forest
functional level has been
raised to either
Windows Server 2003 or
Windows Server 2008. The
domain rename operation will
not succeed if the forest
functional level is set to
Windows 2000 native.
Obtain the necessary
administrative credentials.
You must have Enterprise
Admins credentials to perform
the various steps in the
domain rename procedures. If
you are running Microsoft
Exchange, the account that
you use must also have Full
Exchange Administrator
credentials.
Set up the control station.
The required credentials for each procedure

in the domain rename operations are described
throughout the topics in Managing Active
Directory Domain Rename.
The computer that is to be

used as the control station for
the domain rename operation
must be a member computer
(not a domain controller) that
is running Windows
548
Task
Reference
Server 2008 Standard,

Windows Server 2008
Enterprise, or Windows
Server 2008 Datacenter.
Configure Distributed File
System (DFS) root servers.
If you want to rename a
domain with domain-based
DFS roots, all DFS root
servers must be running
Windows 2000 Service Pack 3
(SP3) or a later release of
Windows Server, up to
Satisfy Exchange-specific
requirements:
Exchange 2003 SP1: If

your Active Directory
forest contains only
Exchange 2003
Service Pack 1 (SP1)
servers, you can run the
domain rename operation,
but you must also use the
Exchange Domain
Rename Fix-up Tool to
update Exchange
attributes. So that you can
perform a domain rename
operation, Exchange must
not be installed on any
domain controllers. If a
domain controller is
running Exchange, move
the Exchange data off the
domain controller and
uninstall Exchange.
Exchange 2003,
Exchange 2000, or
Exchange 5.5: The
domain rename operation
For more information, see Distributed File

System Technology Center
The Exchange Domain Rename Fix-up Tool

is available at Microsoft Exchange Server
Domain Rename Fixup (XDR-Fixup)
549
Task
Reference
is not supported in an
Active Directory forest that
contains
Exchange Server 2003,
Exchange 2000, or
Exchange 5.5 servers. If
the domain rename tool
detects Exchange 2000
servers, the tool will not
proceed. The domain
rename tool will not detect
whether Exchange 5.5
servers exist. Therefore,
do not attempt the domain
rename operation if the
forest contains
Exchange 5.5 servers.
Preparing for the domain rename operation

This checklist provides the list of tasks for preparing for the domain rename operation.
Checklist: Preparing for the domain rename operation
Task
Reference
Adjust the forest functional level.
Adjust Forest Functional

Level
Note
You can rename domains only
in a forest in which all of the
domain controllers are running
Windows Server 2008
Standard or
Windows Server 2003
Standard Edition, Windows
Server 2008 Enterprise or
Windows Server 2003
Enterprise Edition, or
Windows Server 2008
Datacenter or
Windows Server 2003
Datacenter Edition operating
550
Task
Reference
systems, and the

Active Directory forest
functional level has been
raised to either
Windows Server 2003 or
Windows Server 2008. The
domain rename operation will
not succeed if the forest
functional level is set to
Windows 2000 native.
Create necessary shortcut trust
relationships within the forest, and
document all trusts.
Compile a list of domains to be

renamed based on the new forest
structure that you want.
Create shortcut trusts, if

necessary.
Compile a list of all existing trusts

shortcut, external, and across
forestsin the forest.
Prepare Domain Name System (DNS)

zones.
Compile a list of DNS zones for

the domain rename operation.
Create new DNS zones as

necessary as a result of the name
changes to be performed.
Create Necessary Shortcut

Trust Relationships
Prepare DNS Zones
Redirect Special Folders to a StandAlone Distributed File System

Namespace (DFSN).
Redirect Special Folders to

a Standalone DFSN
Relocate Roaming User Profiles to a

Stand-Alone DFSN.
Relocate Roaming User

Profiles to a Standalone
DFSN
Prepare member computers for host

name changes.
Configure Member
Computers for Host Name
Changes
Prepare certification authorities (CAs).
Prepare Certification
551
Task
Reference
Authorities
Prepare a domain that contains
Exchange.
Exchange-Specific Steps:
Prepare a Domain that
Contains Exchange
Performing the domain rename operation

This checklist provides the list of tasks that to perform during the core domain rename operation.
Checklist: Performing the domain rename operation
Task
Set up your control station for the

Reference
Freeze the Forest

Configuration
Back up all the domain controllers

in your forest.
Back Up All Domain

Controllers
Generate the current forest

description.
Generate the Current Forest

Description
Specify the new forest description.
Specify the New Forest

Description
Generate domain rename

instructions.
Generate Domain Rename

Instructions
Push domain rename instructions

to all domain controllers, and
verify DNS readiness.
Push Domain Rename

Instructions to All Domain
Controllers and Verify DNS
Readiness
Verify the readiness of the domain

controllers.
Verify Readiness of Domain

Controllers
Execute the domain rename

instructions.
Run Domain Rename

Instructions
Update the Exchange

configuration, and restart the
Exchange servers.
Update the Exchange
Configuration and Restart
Exchange Servers
Note
552
Task
Reference
This is an optional,
Exchange-specific task.
Unfreeze the forest configuration.
Re-establish external trusts.
Fix Group Policy objects (GPOs)
and links.
Unfreeze the Forest

Configuration
Fix Group Policy Objects and
Links
Completing the domain rename operation

This checklist provides a list of tasks that have to be performed after the core domain rename
procedures are complete. Some tasks may be optional, depending on your situation and business
needs.
Checklist: Completing the domain rename operation
Task
Reference
Verify certificate security.
Perform certain miscellaneous

procedures.
Back up domain controllers.
Restart all member computers.
Verify the Exchange rename, and

update Active Directory
Connector.
Note
Verify the Exchange Rename
and Update Active Directory
Connector
This is an optional,
Exchange-specific step.
Perform attribute cleanup.
Rename domain controllers.
553
Appendix D: Worksheets for the Domain

Rename Operation
This section includes worksheets in suggested formats that you can to gather information about
your Active Directory infrastructure. You can use these worksheets to prepare for the domain
rename operation and to track progress as you perform the operation.
Worksheet 1: Domain Name Change Information

You can use this worksheet to create a list of name changes that will be completed during your
domain rename operation. List changes for all forests and domains and all application directory
partitions.
Old NetBIOS name
Old DNS name
New NetBIOS name
New DNS name
1
2
3
4
5
Worksheet 2: Trust Information

You can use this worksheet to document all trust relationships (for shortcut trusts and external
trusts) and the status of each trust that has to be created or removed during the domain rename
operation.
Trusting
Trusted
domain name
domain name
Trust direction
Trust type
Date created/removed
1
2
3
4
5
554
Worksheet 3: DNS Zone Information

You can use this worksheet to list all Domain Name System (DNS) zones that must be added in
preparation for the domain rename operation.
DNS zone name
Add/remove
Completed?
Date/time
1
2
3
4
5
Worksheet 4: DFSN, Folder Redirection, and

Roaming Profiles
You can use this worksheet to document all domain Distributed File System Namespaces (DFSN)
paths, including the paths that are used by folder redirection and roaming profiles. All domain
DFSN paths will require reconfiguration after the domain rename operation is complete.
Domain
Old domain
New
Server share
Group Policy
DFSN fixed?
name
DFSN path
domain
path for folder
updated?
Date/time?
DFSN path
redirection and
roaming
Date/time?
profiles
1
2
3
4
5
Worksheet 5: Domain Controller Information

You can use this worksheet to document information about specific domain controllers, including
information about operations master roles (also known as flexible single master operations or
FSMO roles).
555
Domain
DC
IP
FSMO
CRL
Execute
Automatic
Dcdiag
name
address
roles
expiry
successfully?
restart?
notes
held by
DC
1
2
3
4
5
Worksheet 6: Domain Rename Execution

Readiness
You can use this worksheet to track the readiness of domains, forests, and application partitions
before the beginning of the domain rename operation. You can also use the information in this
worksheet to check the forest description before you proceed.
Domain/application
Run Dcdiag?
Backed up?
DNS zone ready?
partition
1
2
3
4
5
Worksheet 7: Certification Authority (CA)

Information
You can use this worksheet when you enable certificate enrollment in a renamed domain.
556
Old
New
Alias
Certificate
CDP and
Subordinate
Group
DNS
DNS
created?
enrollment
AIA
and issuing
Policy
name of
name of
Date/time
CA certs
updated?
CA
enabled?
extensions
CA
flexible?
renewed?
1
2
3
4
5
Additional Resources
For general information about how Active Directory Domain Services (AD DS) works and how to
deploy, manage, and troubleshoot AD DS, see the following resources:
Active Directory Domain Services (http://go.microsoft.com/fwlink/?LinkId=96418)
AD DS Design Guide (http://go.microsoft.com/fwlink/?LinkId=100493)
AD DS Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=116283)
Best Practices for Delegating Active Directory Administration (http://go.microsoft.com/fwlink/?

LinkId=46579)
Active Directory Script Center (http://go.microsoft.com/fwlink/?LinkId=122875)
For specific information about troubleshooting Active Directory problems, see the following
resources:
Troubleshooting: AD DS (http://go.microsoft.com/fwlink/?LinkId=122878)
Directory Services Community (http://go.microsoft.com/fwlink/?LinkId=20151)
For development information about Active Directory, see the following resources:
Active Directory Domain Services (http://go.microsoft.com/fwlink/?linkid=142)
Lightweight Directory Access Protocol (LDAP) (http://go.microsoft.com/fwlink/?LinkID=2972)
Request for Comments (RFC) Pages and Internet-Drafts on the Internet Engineering Task
Force Web site (http://go.microsoft.com/fwlink/?LinkID=121)

Guide - cover
Insert introduction here.
557
Section Heading
Insert section body here.
Subsection Heading
Insert subsection body here.
558

Active Directory Domain Services Operations Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Active Directory Domain Services Operations Guide

Uploaded by

Copyright:

Available Formats

Active Directory Domain Services Operations

Create a Two-Way, Shortcut Trust for One Side of the Trust........................................................50

Configuring Selective Authentication Settings...............................................................................79

Stop the DFS Replication Service and Netlogon Service............................................................131

See Also.................................................................................................................................. 166

Verify Successful Replication to a Domain Controller.................................................................187

Backup frequency.................................................................................................................... 214

Performing Authoritative Restore of Active Directory Objects.....................................................245

Turn on Inbound Replication....................................................................................................... 272

Verify DNS Registration and TCP/IP Connectivity......................................................................305

See Also.................................................................................................................................. 344

Preparing for Active Directory Installation...................................................................................391

Verify DNS Server Configuration for a Domain Controller...........................................................416

Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection...............438

Determine Whether a Domain Controller Is a Global Catalog Server.........................................466

Precreating a tree-root trust relationship with the forest root domain...................................489

Verify Readiness of Domain Controllers.....................................................................................522

Appendix D: Worksheets for the Domain Rename Operation.....................................................559

Active Directory Domain Services Operations

New in This Guide

Administering Active Directory Domain Services

New in This Guide

Administering Active Directory Domain

Introduction to Administering Active Directory Domain Services

Administering Domain and Forest Trusts

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

Introduction to Administering Active

When to use this guide

You want to configure AD DS to increase network availability.

How to use this guide

If you are an IT manager who is delegating tasks to operators in your organization:

Administering Domain and Forest Trusts

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

Introduction to Administering Domain and

Best Practices for Administering Domain and

Optimize authentication speed in multidomain forests.

Keep a current list of trust relationships for future reference.

Back up domain controllers.

Managing Domain and Forest Trusts

Creating Domain and Forest Trusts

Configuring Domain and Forest Trusts

Creating Domain and Forest Trusts

Creating External Trusts

Creating Shortcut Trusts

Creating Forest Trusts

Creating Realm Trusts

New Trust Wizard terminology

Domain-wide authentication: An authentication setting that permits unrestricted access by

Forest-wide authentication: An authentication setting that permits unrestricted access by

Selective authentication: An authentication setting that restricts access over an external

Known Issues for Creating Domain and