Known Issues for Adding Domain Controllers in Remote Sites

Article
08/09/2010

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

You can use the following two methods to add domain controllers in remote sites:

Ship the member computer to the remote site, and then install Active Directory by using the dcpromo /adv option, which uses restored system state backup media as the source for the Active Directory installation in the remote site.
Install Active Directory in the hub site by using the normal Dcpromo method, and then ship the installed domain controller to the remote site.

You can use the information in this section to determine the method for adding domain controllers in remote sites that is best for your environment. SYSVOL replication issues potentially affect both methods, and each method has advantages and disadvantages that are discussed in this section.

Important

Do not attempt to perform actions based only on the recommendations that are discussed in this topic. Step-by-step guidance is provided in the task-based topics for all actions that are recommended in this topic. Follow the See Also links to the related task-based topics.

SYSVOL Replication

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

The primary focus for both methods of installing additional domain controllers in remote sites is to avoid the replication of Active Directory over a wide area network (WAN) between the remote site and the hub site. Each method accomplishes this goal. However, depending on the size of your SYSVOL, you might also be concerned about replication of SYSVOL files over the network. Unless you follow specific instructions, the SYSVOL tree might be created on the new domain controller through replication of the entire tree from an existing domain controller in the domain. Regardless of which method you use to add domain controllers to remote sites, you might want to take additional steps to manage SYSVOL creation on the new domain controller to avoid replicating the full SYSVOL from another domain controller in the domain.

When you install a domain controller from backup media, preliminary steps are required to ensure that SYSVOL is created from the local copy of the restored backup media. Similarly, preliminary steps are required to avoid full SYSVOL synchronization when you ship an installed domain controller and restart it in the remote site. These requirements are discussed for each method respectively in the following topics:

Using Backup Media to Install Active Directory in a Remote Site

The ability to use restored backup media to install domain controllers is a new feature in Windows Server 2003. The method for using backup media to install domain controllers includes the following general steps:

Back up system state on a domain controller in the domain in which you are adding the new domain controller. If you want the additional domain controller to be a global catalog server, back up a global catalog server. If you want the additional domain controller to be a Domain Name System (DNS) server, back up a DNS server.
Restore the backup to an alternate location. You can restore the backup directly to the computer that you want to install as a domain controller, or you can transfer it to removable media.
Run Dcpromo with the /adv option and indicate the restored backup as the source for the Active Directory installation.

This method of installing domain controllers in remote sites has several advantages. One of the primary advantages of this method is that it substantially reduces the network bandwidth requirement compared to network-based installations. This method also has a few issues that mostly affect deployments that have a large number of remote sites. If you deploy more than 100 remote sites, additional considerations might be necessary. For information about large branch office deployments, see the Windows Server 2003 Active Directory Branch Office Guide on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=42506).

Advantages of Using Backup Media to Install Active Directory in a Remote Site

The following advantages are associated with using backup media to install a domain controller in a remote site:

You can install many domain controllers from a single source of removable backup media. Although you can restore backup media directly to an alternate location on the server computer that you are going to install as a domain controller, you can also use that media as the source for any number of domain controllers by either copying or restoring the system state backup to removable media. For more information about the effects of copying — as opposed to restoring — a system state backup to removable media, see Preparing a Server Computer for Shipping and Installation from Backup Media.
You do not have to disconnect the domain controller from the replication topology. Therefore, you can avoid the disadvantages that are associated with a domain controller that does not replicate. For information about the problems that are associated with domain controller disconnection, see Issues with Installing Domain Controllers Before Shipping Them to the Remote Site.
You avoid replicating the entire Active Directory over a WAN link, particularly a link that requires a dial-up connection.
If you enable Remote Desktop on the server before you ship it, you do not have to employ an administrator with Domain Admins credentials in the remote site.

Issues with Using Backup Media to Install Active Directory in Remote Sites

The following issues are associated with using backup media to install a domain controller in a remote site:

Domain Admins credentials and remote installation. An administrator must have Domain Admins credentials to install Active Directory. Assuming that you do not employ a service administrator with this level of administrative credentials in each branch site, a domain administrator in the hub site must be able to connect remotely to the server to perform the installation. Therefore, you must be sure to enable Remote Desktop on the server before you ship it to the remote site.
Time to restore the system state backup. The installation media is prepared by restoring a system state backup to an alternate location. Therefore, preparing the media requires taking the backup itself and restoring the backup. These tasks add time to the installation of a single domain controller. However, if you take advantage of the ability to transfer the restored backup files to removable media, you perform the preliminary backup and restore processes only once to install any number of domain controllers. In addition, you can follow instructions to prepare a smaller backup file to further decrease the time that is required for restoring and copying backup media. The volume on which you restore the backup on the target server also affects the speed of the installation. Moving the Ntds.dit file is faster than copying it. If you restore the media to the same location that will be used to host the Active Directory database, the Ntds.dit file will be moved (as opposed to being copied) into the new location, eliminating the additional time required to copy the file. For more information about the criteria that affect how long installation from backup media takes, see Preparing a Server Computer for Shipping and Installation from Backup Media.
Backup source for application directory partitions. When DNS zone data is stored in application directory partitions, the replication impact can be significant if application directory partitions must be replicated over the corporate network. System state data that you restore from backup to an alternate location does not include application directory partitions if the backup is performed on servers running Windows Server 2003 with no service pack installed.

Including application directory partitions in the backup media has the following requirements:
- The domain controller that you back up and the computer that you intend to install as a domain controller must both be running Windows Server 2003 with Service Pack 1 (SP1).
- The forest functional level must be set to Windows Server 2003 because linked-value replication is required to ensure that cross-references are correctly updated for the application directory partition replica set.
- You must use an answer file to install Active Directory because the Dcpromo user interface (UI) does not provide an option for specifying application directory partitions. Use the answer file to provide the distinguished names of the application directory partitions that you want to include in the installation.
For more information about how to include application directory partitions and create a DNS server, see Preparing a Server Computer for Shipping and Installation from Backup Media.
Bridgehead server load balancing. If backup media are sent to many sites and if enough domain controllers are promoted at the same time, you might experience performance issues with the bridgehead servers that are the source for Active Directory and FRS replication.

Note

These issues are of concern only in situations in which hundreds of domain controllers might be promoted at the same time and their need for bridgehead server resources is very high. If you are deploying hundreds of domain controllers in branch sites, see the Windows Server 2003 Active Directory Branch Office Guide on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=42506).
- Active Directory intersite replication. You cannot load-balance intersite connections to and from the hub site until the domain controller is installed. If a large number of domain controllers are being installed in remote sites (more than 100), manual rebalancing of connections might be required after the domain controllers are installed. For information about how to use the Active Directory Load Balancing (ADLB) tool to rebalance connections, see the Windows Server 2003 Active Directory Branch Office Guide on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=42506).
- FRS replication. Because FRS on the source computer uses CPU, memory, and disk resources, the FRS recommendation is to perform a staged update on no more than 10 branch office domain controllers at a time per source hub domain controller. If a single domain controller functions as the source for SYSVOL replication to more than 10 destination domain controllers, performance on the source domain controller can decrease significantly. To balance source domain controllers, you can use an answer file with Dcpromo to specify the source domain controller.

Installing Domain Controllers Before Shipping Them to the Remote Site

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

Advantages of Installing Domain Controllers Before Shipping Them to the Remote Site

The following advantages are associated with installing domain controllers before shipping them to the remote site:

Standardization. The process for installing domain controllers can be automated and standardized in the hub or staging site, with the one additional step of packing and shipping the domain controller. If you follow the instructions for safe disconnection and reconnection, restarting the domain controller in the remote site is all that is required.
Branch site personnel. The requirement for personnel with Domain Admins credentials is contained within the hub site; that is, intervention by personnel with Domain Admins credentials is not required at the branch site.

Issues with Installing Domain Controllers Before Shipping Them to the Remote Site

The following issues are associated with installing domain controllers and then disconnecting them from the network while they are shipped to the remote site:

Disconnection error conditions. After disconnection, online domain controllers in the domain continue to attempt replication with the disconnected domain controller, causing Active Directory and FRS errors to be generated for as long as the domain controller is disconnected.
Additional preparation. Additional preparation is required to ensure smooth reconnection:
- Preparing for the nonauthoritative restart of SYSVOL.
- Ensuring an adequate tombstone lifetime to avoid the possibility of objects remaining on the domain controller that have been permanently deleted from the directory on all other domain controllers. The tombstone lifetime is a forest-wide setting that determines how long an object deletion persists in the directory.
Protection of existing accounts and metadata. You must ensure that computer accounts and metadata for the domain controller are not deleted or improperly modified while the domain controller is disconnected.
Risk of lingering objects. A lingering object is an object that remains on a disconnected domain controller after the object has been permanently deleted from Active Directory on all connected domain controllers. Deletion updates are replicated as tombstone objects. These objects have a limited lifetime in Active Directory, which is defined by the tombstone lifetime. After a tombstone is permanently removed from Active Directory, replication of the deletion it represented is no longer possible. Therefore, if you restart a domain controller on which such an object remains, replication does not recognize that object as a deleted object, and it remains in Active Directory on only the reconnected domain controller and nowhere else. If you plan to disconnect a domain controller for longer than the period of time that a domain controller keeps track of object deletions (the tombstone lifetime), you must take additional steps to ensure directory consistency. For more information about lingering objects and their causes and effects, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042).

Maintaining Directory Consistency When Disconnecting a Domain Controller

Maintaining consistency of Active Directory data involves several related issues. Review the following known issues before disconnecting an installed domain controller:

Relationship of tombstone lifetime to Active Directory backup
Protection against lingering object replication
Availability of operations master roles in the domain and forest
Up to dateness of Active Directory replication at the time of disconnection
SYSVOL consistency on reconnection

For procedures to ensure that all of these issues are addressed, see the following topics:

Tombstone Lifetime and Backup

Active Directory backups are useful for recovering a domain controller for only as long as the tombstone lifetime. When an object is deleted, Active Directory replicates the object as a tombstone, which consists of a small subset of the attributes of the deleted object. The tombstone is retained in Active Directory for 60 days by default in a Windows Server 2003 forest. This default value is changed in Windows Server 2003 with Service Pack 1 (SP1). The tombstone is retained for 180 days by default in a new forest that is created on a domain controller running Windows Server 2003 with SP1. NTBackup.exe, the Windows Server backup utility, will not restore a system state backup that is older than the tombstone lifetime.

The tombstone lifetime value that is in effect when a domain controller is upgraded to Windows Server 2003 SP1 is not changed by the installation of Windows Server 2003 SP1. The existing value is maintained until you change it manually. You can determine the value of the tombstoneLifetime attribute by viewing the properties of CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain in ADSI Edit (adsiedit.msc), which is available in Windows Support Tools. A value in tombstoneLifetime of <Not Set> always indicates that the Windows Server 2003 default value of 60 is in effect. If you create a new forest on a domain controller running Windows Server 2003 with SP1, the default tombstoneLifetime value of 180 is displayed in the UI.

When the number of days in the tombstone lifetime has passed, the tombstone is permanently removed. Because a domain controller that is disconnected for a period that is longer than the tombstone lifetime cannot receive deletions that occurred before the beginning of the tombstone lifetime, a backup that is older than the tombstone lifetime cannot be used to restore Active Directory.

When conditions beyond your control cause a domain controller to be disconnected for a period that is longer than the tombstone lifetime, one or more objects that have been deleted from the rest of the directory while the domain controller was offline might remain on the disconnected domain controller.

If planned domain controller disconnections are consistently lasting longer than the number of days in the tombstone lifetime, consider extending the tombstone lifetime for the forest prior to disconnecting any domain controllers.

For more information about the causes and effects of lingering objects, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042).

Protection Against Lingering Object Replication

Domain controllers that have not performed inbound replication in the previous tombstone lifetime number of days are vulnerable to retaining lingering objects. If a domain controller that has one or more lingering objects is reconnected to the replication topology and a lingering object is subsequently updated on that domain controller, the object might be recreated in Active Directory, depending on how the strict replication consistency registry setting is configured.

A lingering object is made known to the replication system only if it is updated on the domain controller that stores it. In this case, the source domain controller attempts replication of an update to an object that the destination does not store. On destination domain controllers running Windows 2000 Server with Service Pack 3 (SP3) or Service Pack 4 (SP4) and Windows Server 2003, the strict replication consistency registry entry (type REG_DWORD) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters) determines whether replication is allowed to proceed if the domain controller receives a request for an update to an object that it does not have.

The value in the strict replication consistency registry entry determines whether replication proceeds or is stopped, as follows:

1 (enabled): Inbound replication of the specified directory partition from the source is stopped on the destination. Replication of the directory partition is halted on both the source and destination domain controllers.
0 (disabled): The destination requests the full object from the source domain controller and the destination domain controller reanimates a full copy of an object it has previously deleted and permanently removed through garbage collection.

For more information about how to manage the strict replication consistency setting, including its effects and its default values, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042).

Up to Dateness of Active Directory Replication

Ensure that a domain controller is updated before you disconnect it. Immediately before you disconnect the domain controller, force replication with all replication partners and verify that each directory partition replicates to the domain controller that you are disconnecting. If replication of any directory partition does not succeed, resolve the replication problem before you disconnect the domain controller. By ensuring that replication is up to date, you can maximize the possible safe disconnection period, which cannot exceed the tombstone lifetime for the forest.

SYSVOL Consistency

SYSVOL replication cannot be synchronized manually. For this reason, ensuring that SYSVOL is updated before you disconnect the domain controller is more difficult than simply updating SYSVOL when the domain controller is reconnected. Regardless of the length of the disconnection, to ensure that SYSVOL is synchronized when the domain controller is reconnected, prepare the domain controller to perform a nonauthoritative restart of SYSVOL before you disconnect the domain controller. When the domain controller restarts, nonauthoritative restart of SYSVOL occurs automatically.

Share via