Best Practices for Adding Domain Controllers in Remote Sites

  • Article

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

By reviewing the information in Known Issues for Adding Domain Controllers in Remote Sites, you can determine the best method to use for installing domain controllers in your remote sites. You can use this topic to learn about the best practices for the method that you decide to use.

Important

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

Using Backup Media to Install Active Directory in the Remote Site

The primary purpose of using restored backup media to install a domain controller is to provide a local source for the domain, configuration, and schema directory partitions — and, optionally, global catalog partial, read-only directory partitions and Domain Name System (DNS) application directory partitions. The local source is the restored system state backup files that reside on the server that you are installing. Updates to object attributes that occur since the system state backup was made will replicate over the network from an existing domain controller in the domain or forest. Although SYSVOL is part of the system state backup, under some conditions SYSVOL is not sourced from the backup media. Configuring SYSVOL to be sourced from local backup media is more challenging and might not prove worthwhile. For more information about the conditions that determine the need for SYSVOL replication, see Known Issues for Adding Domain Controllers in Remote Sites.

To use restored backup files for installation of one or more additional domain controllers in a domain, you can either:

  • Copy ("burn") either the unrestored .bkf file or the restored backup files onto removable media, such as a portable disk drive, CD, or DVD, which can be shipped with the workgroup computer when it leaves the staging site or shipped separately.

  • Restore system state backup to the local hard drive of the workgroup computer before it leaves the staging site.

For information about the advantages and disadvantages of these methods, see Preparing a Server Computer for Shipping and Installation from Backup Media.

The Dcpromo /adv option in Windows Server 2003 to install a domain controller from backup media eliminates the Windows 2000 Server requirement to either promote the domain controller before shipping it to the remote site or promote the domain controller in the remote site by replicating the entire directory over a wide area network (WAN) connection when another domain controller for the domain is not present in the site.

The following best practices are recommended to optimize data security and consistency when you add domain controllers in remote sites:

  • Upgrade to Windows Server 2003 with Service Pack 1 (SP1). If you use Active Directory-integrated DNS or if you want other application directory partitions to be included in the domain controller replica, upgrade the server computer to Windows Server 2003 with SP1 before Active Directory installation. When you use restored backup media to install a computer running Windows Server 2003 with no service pack installed, the replica installation does not include application directory partitions. In the case of DNS application directory partitions, the impact of replicating these directory partitions over the WAN might be significant. When you use restored backup media to install a computer running Windows Server 2003 with SP1, you can use an answer file to include application directory partitions in the replica that you install.

  • Back up the type of domain controller that you want to add. You must back up the type of domain controller that you want to add. If you want to add a global catalog server in the remote site, back up a global catalog server in the domain. If you want to add a DNS server, back up a DNS server in the domain.

  • Take the same security precautions for shipment of removable backup media or a server computer that contains a restored backup as you would take for shipping an installed domain controller. For information about securing domain controllers, see Best Practice Guide for Securing Windows Server Active Directory Installations on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=28521).

  • Minimize the time between the backup and installation. Minimizing this delay reduces the number of updates that will be required to replicate after installation.

  • Install the operating system before shipping the server to the remote site. Installing the operating system requires expertise that might not be available at branch sites. Ideally, installation routines are available in the staging site to automate the operating system installation process and ensure uniformity for all domain controllers (partition sizes, drive letter assignments, and so on). As part of the operating system installation, apply a standardized set of hotfixes plus any available service packs to ensure service consistency throughout the forest.

  • Ship the server as a member of a workgroup rather than a member server in a domain. If the server is joined to a domain and then stolen during shipment, information about domain names, DNS suffixes, and number of domains in the forest can aid attackers in attempts to compromise or steal directory data.

  • Ship computers with properly configured Internet Protocol (IP), subnet mask, and default gateway addresses. Remember to reconfigure the server with TCP/IP settings that are appropriate to the target site, not the staging site. Specifically, the domain controller must not point to itself for DNS.

  • Enable Remote Desktop on the server computer before shipping. This best practice assumes that you need to be able to install and manage Active Directory remotely rather than employing an administrator with Domain Admins credentials in each remote site.

Installing Domain Controllers Prior to Shipping to the Remote Site

When you install Active Directory in the hub or staging site, disconnect the installed domain controller, and then ship the computer to the remote site, you are disconnecting a viable domain controller from the replication topology. The most significant risk from disconnection is that the domain controller will remain offline long enough to exceed the tombstone lifetime and thereby become capable of retaining objects that have been permanently deleted from the directory on all other domain controllers in the domain. Such objects, called lingering objects, cause directory inconsistency and, under certain conditions, can be reintroduced into the directory. For information about the causes and effects of lingering objects and how to avoid them, see Known Issues for Adding Domain Controllers in Remote Sites.

The following best practices reduce the possibility of Active Directory consistency problems due to lingering objects remaining on domain controllers that are disconnected for long periods of time. Take the following precautions to avoid directory consistency problems when you disconnect an existing domain controller and to ensure that if inadvertent long disconnections occur, lingering objects cannot be replicated.

  • Upgrade all Windows 2000 Server domain controllers to Windows Server 2003. This process requires upgrading the forest schema by using the adprep /forestprep command. Thereafter, you can begin upgrading domain controllers to Windows Server 2003. The Windows Server 2003 schema update adds 25 indexed attributes to the schema directory partition. An update of this size can cause replication delays in a large database. For this reason, domain controllers that are running Windows 2000 Server must be running — at a minimum — Windows 2000 Service Pack 2 (SP2) plus all additional Windows updates. However, it is highly recommended that you install Windows 2000 Service Pack 3 (SP3) on all domain controllers before preparing your infrastructure for upgrade to the Windows Server 2003 operating system. For information about upgrading to Windows Server 2003, see "Upgrading from Windows 2000 Domains to Windows Server 2003 Domains" in the Windows Server 2003 Deployment Guide on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=46082).

  • Enable strict replication consistency on all domain controllers. This registry setting, which stops inbound replication of a directory partition from a source domain controller that is suspected of having a lingering object, should be set for the forest to prevent the reintroduction of a lingering object into the directory. You can use the Repadmin /regkey command, which is available in the version of Windows Support Tools that is included with Windows Server 2003 SP1, to enable this setting on a specific domain controller or on all domain controllers in the forest, which eliminates the need to update the registry manually.

  • Monitor the Knowledge Consistency Checker (KCC) topology and replication to ensure that unintended long disconnections are detected. By monitoring replication, you can detect disconnections that occur as a result of network failures, service failures, or configuration errors. Use the Active Directory Management Pack or other monitoring application to implement a monitoring solution for your Active Directory deployment. Event IDs to monitor include 1311, 1388, 1925, 1988, 2042, 2087, and 2088.

  • Ship computers with properly configured IP, subnet mask, and default gateway addresses. Remember to reconfigure the server with TCP/IP settings that are appropriate to the target site, not the staging site. Specifically, the domain controller must not point to itself for DNS.

  • Configure the tombstone lifetime appropriately. Ensure that the tombstone lifetime is not lowered below the default. The default tombstone lifetime in a forest that was created on a domain controller running Windows 2000 Server or Windows Server 2003 is 60 days. The default tombstone lifetime in a forest that was created on a server running Windows Server 2003 with SP1 is 180 days. If you must disconnect a domain controller for a period of several weeks or months, before you disconnect the domain controller, do the following:

    • Estimate the anticipated length of disconnection.

    • Determine the value of the tombstone lifetime for the forest. This value is stored in the tombstoneLifetime attribute of CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain.

    • Determine the maximum length of time that the domain controller can be safely disconnected. From the tombstone lifetime number of days, subtract a generous estimate of the number of days that are required for end-to-end replication latency. The resulting amount of time is the maximum period for which the domain controller can safely be disconnected.

    • Determine whether to extend the tombstone lifetime for the forest. If you estimate the maximum time of disconnection to be longer than the tombstone lifetime, you must determine whether to extend the tombstone lifetime or perform the procedure to remove lingering objects from the domain controller after it is reconnected. If you extend the tombstone lifetime, you must also make sure that all domain controllers have adequate disk space to store additional tombstones. In addition, make sure that replication of the tombstone lifetime change has reached all potential source domain controllers before you run Dcpromo to install an additional domain controller.

  • Prepare the registry for automatic nonauthoritative restart of SYSVOL when the domain controller restarts. SYSVOL cannot be updated manually before disconnection. By editing a registry setting, you can ensure that SYSVOL is updated as soon as the domain controller is restarted.

  • Ensure that the domain controller replicates successfully with all replication partners. Immediately before you disconnect the domain controller, force replication with its partners. Check that replication has succeeded before you disconnect the domain controller.

  • Label the domain controller. When you disconnect the domain controller, attach a label to the computer that identifies the date and time of disconnection, the destination, and the IP settings.

  • When you reconnect the domain controller, restore SYSVOL as quickly as possible. The domain controller does not serve as a domain controller until SYSVOL has been updated through replication. If the site has one or more other domain controllers in the same domain, start the domain controller anytime. If the site contains no other domain controller in the same domain, time the restart of the domain controller to coincide with the beginning of intersite replication.

  • Do not allow an outdated Windows 2000 Server domain controller to replicate. If a domain controller running any version of Windows 2000 Server has been disconnected for longer than the maximum safe time of disconnection (the tombstone lifetime minus end-to-end replication latency), do not allow the domain controller to replicate. Instead, force the removal of Active Directory, perform metadata cleanup, and then reinstall Active Directory. As an alternative, you can reinstall the domain controller with Windows Server 2003. For more information about completing these tasks, see Reconnecting a Domain Controller After a Long-Term Disconnection.

    Note

    This recommendation applies to additional domain controllers in an existing domain. If the outdated domain controller is the only domain controller in the domain, the recommendation is to reconnect the domain controller and follow the instructions to remove lingering objects in article 314282, "Lingering objects may remain after you bring an out-of-date global catalog server back online," in the Microsoft Knowledge Base on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=37924).

  • To avoid time skew issues, ensure that the system clock is synchronized with the domain source on startup. When you start the domain controller in the remote site, use the following command to set the hardware clock:

    **net time /domain:**DomainName /set /y

See Also

Concepts

Known Issues for Adding Domain Controllers in Remote Sites
Preparing a Server Computer for Shipping and Installation from Backup Media
Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection
Reconnecting a Domain Controller After a Long-Term Disconnection
Managing SYSVOL

Other Resources

How the Active Directory Replication Model Works
Active Directory Management Pack Technical Reference for MOM 2005