Windows DevCenter    
 Published on Windows DevCenter (http://www.windowsdevcenter.com/)
 See this if you're having trouble printing code examples


Getting the Most Out of Site Links

by Mitch Tulloch, author of Windows Server Hacks
06/29/2004

A couple of aspects of Active Directory (AD) that often seem confusing are sites and site links. The basic definition of these concepts seems simple enough. For example, a site is defined as a portion of your network that has high-bandwidth connectivity.

Typically this means a site is one or more IP subnets in a single location such as a campus, building, or floor. A site link, on the other hand, is a group of sites linked together by a router or some other WAN device. A typical site link joins only two sites together, but you can have site links with three or more sites on backbone networks that connect groups of buildings on a campus.

Also important to remember is that sites and site links represent a logical topology that is separate from the domain namespace of your AD deployment. In other words, one domain can contain multiple sites while one site can belong to several domains. And while domains are generally deployed to mirror the business or administrative structure of your organization, sites and site links are created to mirror the structure of the underlying physical network that supports your AD deployment.

The main reasons for using this second structure are to provide mechanisms for controlling the replication of AD information between domain controllers (DCs) in different locations and for enabling users to find and access resources that have proximity to where they are located. For example, the site topology of your network enables a user at a remote branch office to find and use a DC at his or her branch office to log on to the network instead of a DC at headquarters. The advantages of using a nearby domain controller this way include shorter latency for faster logons and reduced bandwidth usage of costly WAN connections.

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

So far so good, but what administrators often forget is that while sites and site links are supposed to mirror the underlying physical network for your company, they may not do this depending on how your sites and site links have been created.

For example, while a site link should normally represent a physical WAN link between two locations that are different sites, AD has no way of actually determining if this is the case, if there actually is a WAN link connecting the locations, what kind of WAN link it is, and so on.

So if you made a mistake in the way you designed your site topology, failed to create the appropriate site links, or did something else wrong when you designed and implemented your sites and site links, you may end up with replication problems, stale directories, and frustrated users.

Site Link Confusion

One example of the typical kind of misconception that occurs concerning site links is that you can create two or more site links between the same pair of sites to ensure redundancy when a WAN link fails.

For example, say your company headquarters is in Minneapolis and you have a branch office in Fargo. Your primary WAN link between the two locations is a T1 line, but you have a dialup ISDN connection as a backup in case your T1 line goes down. You decide to deploy AD with a single domain but two sites, Minneapolis-Site and Fargo-Site.

You figure that you can then ensure redundancy for replication purposes by first creating two site links, one for the leased line joining the two sites and the other for the dialup link joining the same two sites, and then assigning a higher-cost value to the dialup link so that AD prefers the lower-cost leased line for replication purposes. Here's what you figure you'll do:


                 ------ T1-Site-Link ------
Minneapolis-Site                            Fargo-Site
                 ----- ISDN-Site-Link -----

Well, guess what, you figured wrong. The mistake you made is a common one -- you assumed AD has some sort of awareness of how your physical network actually works. It doesn't -- site links don't have a clue about how packets are being routed across your network. If they did, then every time your network hiccuped and a WAN link went down for a few minutes, AD would start recalculating the replication topology and creating new connection objects to try to optimize traffic routing across your network. Then when your WAN link came back up you might be left with a non-optimal topology resulting in increased latency and replication problems.

Instead of following the above approach, which on its face seemed logical enough, here's what you should do:


Minneapolis-Site ----- Minneapolis-Fargo-Site-Link ----- Fargo Site

In other words, even though you have two different WAN links between your two sites, you should only create a single site link joining the sites together and leave your WAN link redundancy to your access router, which can switch to ISDN when the T1 line fails.

Moral of the Story

While mapping your physical network to your site topology is a good thing, too much of a good thing can be bad. Sure, by disabling site-link transitivity you can create a site topology that (almost) exactly mirrors the way your actual network works, but the harder you try to make things match the more maintenance you're going to have to perform as the administrator to keep AD replication working optimally on your network.

It's best then to simply paint the broad outlines of your network when you create your sites and site links, and leave AD to work out the rest by creating the topology and connection objects it feels are necessary to ensure sufficient redundancy for AD replication to occur without problems.

And of course, simpler is always better. If you can get away using only one domain and one site for your company, do it -- if your primary WAN links are T1 or higher, it shouldn't be a problem.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.


Return to WindowsDevCenter.com.

Copyright © 2009 O'Reilly Media, Inc.