When dealing with a large enterprise-level Active Directory structure, one of the more important concepts is replication. Replication is the process of sharing Active Directory updates between domain controllers. Many challenges are involved in replicating database changes across a large enterprise. To make this process easier, Windows 2000 uses an organizational structure called a site. In this article, I’ll discuss the ways that sites are used within Windows 2000.
What’s a Site?
If you’re familiar with Exchange 5.5, then you’re probably already familiar with the idea of sites. The main difference between Exchange and Windows sites is that whereas an Exchange site consists of a group of mail servers, a Windows 2000 site is made up of a group of domain controllers. Unlike Windows NT version 4.0, Windows 2000 uses what’s known as a multimaster domain model. This means that rather than making all administrative changes directly to a primary domain controller and replicating them out, administrative changes can be made to any domain controller. These changes are then replicated to each domain controller.
The Site Model
The multimaster domain model can be a bit chaotic. Imagine a large network with dozens of domain controllers that are constantly trying to replicate changes to each other, and you’ll understand how quickly the network could be flooded with replication traffic. To help reduce this constant bombardment, Microsoft implemented the site model. The site model groups domain controllers that are members of the same domain and that are connected by high-speed, low-cost links. Dividing the domain controllers in this way eases the strain caused by replication.
For example, suppose that your domain consists of three domain controllers. Now, imagine that an Ethernet segment connects two of those domain controllers to each other, and the third connects via a dedicated ISDN line. Needless to say, Ethernet offers a speed that’s more than sufficient to sustain replication. Therefore, you’d probably want to form a site that contains the two domain controllers connected by the Ethernet segment. Doing so would allow the two domain controllers to replicate freely between each other as needed. And it makes sense because you usually don’t have to worry about bogging down an Ethernet segment with replication traffic. If your network is too congested with traffic already, you can install a second network card into each server and form a dedicated segment between the servers that’s used solely as a backbone for replication traffic.
Once you’ve established your initial site, you’ll probably want to create a second site to contain the server on the other end of the dedicated ISDN line. The reason for doing so is that ISDN is a slow, and potentially expensive, medium, and you don’t want to risk congesting your ISDN link with constant replication traffic. You can solve this problem with the two-site model. Servers within each site will replicate Active Directory changes with each other freely, but servers in different sites will only replicate directory information at scheduled times. You can set the replication schedule to replicate across the slow link at a time when network traffic will be minimal. In the future, as you add servers to the network, you can place them in the site to which they have the most efficient link. If a new server is connected to the rest of the domain only by slow links, you can always create another site.
So far, the model I’ve given you for creating sites has applied to multi-facility networks. For example, you might use this site model when most of a company’s employees reside in an office building, but the network also needs to be linked to a warehouse across town. However, it sometimes makes sense to use multiple sites in one physical location. A good rule of thumb to follow is that each subnet that contains at least one domain controller should be its own site. In fact, you can actually associate individual subnets with sites within the Active Directory.
Remember that if you do decide to use a separate site for each subnet, you should plan carefully how often those sites will replicate with each other. For example, suppose that some of the users in subnet A frequently use some of the network resources found in subnet B. If replication doesn’t occur frequently enough, users in subnet A might not be able to see changes made to their resources in B until several hours after the change has occurred. A guideline to follow is connection speed. Basically, if the sites are on different subnets, but those subnets are connected by low-cost, high-speed links, then there’s little reason not to replicate the sites more often than you would if they were separated by a slow wide-area connection.
Creating a Site
Creating a site within Windows 2000 is a relatively simple process. First, click Start and select Programs|Administrative Tools|Active Directory Sites And Services. When you do, you’ll see the Active Directory Sites and Services snap-in for Microsoft Management Console. In the column to the left, right-click on the Sites folder and select New Site from the context menu. At this point, you’ll see the New Object Site dialog box. Enter the name of the site you want to create in the Name field. You should also select the site link object that you want to use for the site from the bottom portion of the dialog box. Usually, if you’re establishing your first site, the only available link name will be DEFAULTSITELINK. The default site link is automatically set up to use the IP protocol.
When you install the first domain controller in a site, Windows 2000 will automatically create a site with the name Default-First- Site-Name. If you’re planning to use multiple sites in your enterprise, you should definitely change this name to something more fitting to your organizational naming scheme. Even if you don’t currently plan to create other sites, it isn’t a bad idea to give the default site a custom name just to make your Active Directory structure a little easier to follow. Besides, you never know when you may have to create a second site.
If you do decide to rename the default site (or any other site, for that matter), go back into the Active Directory Sites and Services snap-in. In the column on the left, navigate to Active Directory Sites and Services|Sites. When you select the Sites folder, the column on the right will display all the existing sites. Right- click on the site you want to rename and select Rename from the context menu.
So far, I’ve shown you how to create sites; but a critical piece of the puzzle is still missing. Unless you link the sites, replication will never occur between them. Remember that as far as Windows 2000 is concerned, each site is a separate entity unless you tell it otherwise. The task of linking sites is accomplished by a mechanism known as a site link.. A site link is bound to a protocol that both sites joined by the link can use to communicate. The site link itself also contains the replication schedule and various security mechanisms.
When you create your first site, Windows 2000 automatically creates one site link. This is the DEFAULTSITELINK that you saw earlier when you created the site. If you had selected this option when creating a site, this site link would be used to join the new site to any existing sites that were also set to use the link.
You can access the DEFAULTSITELINK by going into the Active Directory Sites and Services snap-in and navigating to Active Directory Sites and Services|Sites|Inter-Site Transports|IP. When you select the IP folder, the DEFAULTSITELINK will appear in the column on the right. Right-click on the DEFAULTSITELINK and select Properties from the context menu. When you do, you’ll see the DEFAULTSITELINK’s Properties sheet. The General tab displays which sites are linked by the site link. The tab also displays the link’s cost and replication schedule. You can use the Change Schedule button to replicate the connected sites more or less often. The default replication schedule is set to replicate the connected sites every 180 minutes.
By looking through the various options found on the properties sheet, you can easily establish basic inter-site replication. However, this is just the tip of the proverbial replication iceberg. I cover site links and replication in more detail in part 2 of this series (
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.