Domain Controller Placement


One of the biggest questions in an Active Directory design session is on the placement of Domain Controllers. In NT 4.0 domain controllers were often used as a Band -Aid for poor network performance. By placing local backup domain controllers at every site, users were assured of having authentication and login scripts available in case of a WAN failure. Maintenance and management of remote domain controllers quickly became a major issue for large companies.

In Windows Server 2003 there have been great improvements in replication traffic, replication topologies, and the reduction of single master operations over NT 4.0. As such, many companies take the upgrade to Active Directory as an opportunity to reduce the number of domain controllers in the environment as well as to centralize them to reduce administrative costs.

Replication Traffic Migrating from Windows NT 4.0 Versus Authentication Traffic

One of the most popular arguments in favor of domain controllers at each location is that of authentication traffic across the WAN. Most network administrators cringe at the thought of users authenticating across the WAN instead of locally. In reality, user authentication is only a few KB of data per authentication. Although domain controllers might not be local, login script locations can be.

In large companies, domain controllers can spend a lot of bandwidth replicating changes to objects that occur in other parts of the network. Users, on the other hand, rarely authenticate more then once per day. As such, it is not uncommon to see replication traffic take up more bandwidth then authentication traffic. Many companies have found that domain controllers placed in smaller sites that were intended to reduce bandwidth usage actually increased it. Removing those domain controllers freed up precious bandwidth.

A simple test is to enable monitoring on a WAN connection of a remote office and temporarily unplug its domain controllers. Their site will be adopted and another set of DCs will handle its authentication. Place a replica of login scripts on its local file server and make sure the users in that site point to that location for their scripts. If login scripts reference a DFS share, this will be unnecessary. Monitor the WAN connection for a day and compare it to the same day of the week from the previous week. This will provide the objective data needed to make a decision about the cut off point for the size of office that should maintain local domain controllers.

Determining the Value of Local Domain Controllers

One of the most important considerations when looking at removing domain controllers from a site is determining exactly what the benefits are of having a local domain controller. Although being able to authenticate seems like a requirement for a site, if there are no resources locally that would be accessed via a local authentication, there is only minimal benefit. If all resources are remote and the domain controllers are also located remotely, a failure of the WAN would make local domain controllers pointless. If an office has local resources, most users could still access the resources via locally cached credentials if there was a WAN failure and no local domain controllers. These types of scenarios must be considered to determine if local domain controllers would add value to a site.

Spending on WAN Connectivity Versus Domain Controllers

In many situations WAN traffic is more about replication than it is about authentication. But it is still important that client computers are able to reach domain controllers. If there is a WAN failure and there are no local domain controllers, users will only be able to reach resources for which they have cached credentials. But if there are local domain controllers, the users in the location are still limited to accessing only the local resources. In this type of situation it is often better to spend your budget on redundant network connections as opposed to spending the money on additional domain controllers. The redundant WAN links will not only ensure the users within a site will be able to authenticate properly with an available domain controller, but it will improve the users' connectivity to resources throughout the enterprise.

Many companies have literally removed all domain controllers from all remote sites and placed a much lower number of domain controllers in a central location. In this way, all the domain controllers are centrally located and centrally managed. Additional domain controllers are placed in a recovery site with connectivity between the two primary locations. Remote sites are given WAN connections to both locations for redundancy. The result has been improved overall performance and reliability along with a significant reduction in costs for managing the remote systems.



Microsoft Windows Server 2003 Insider Solutions
Microsoft Windows Server 2003 Insider Solutions
ISBN: 0672326094
EAN: 2147483647
Year: 2003
Pages: 325

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net