AD Sites, Part 1

Managing your Windows 2000 traffic

Windows 2000's (Win2K's) Active Directory (AD) has garnered the most technical attention of all the Win2K features. Despite this focus, users haven't given as much attention to AD's sites feature compared with the new Win2K domain structure and the Global Catalog (GC). Although Win2K's tasks might be overloading you, you should learn about AD sites because they can make a huge difference in how Win2K affects your corporate network. After you learn how to use AD sites to manage replication over your Win2K network, you'll see that AD sites deserve the spotlight.

The AD Site Concept
Microsoft introduced AD's sites feature in Win2K to solve a Windows NT 4.0 problem. The physical network topology for large corporate networks resembles islands of high connectivity (i.e., the LAN in an office complex) that an ocean of lower connectivity (i.e., WAN circuits connecting islands) surrounds. In comparison, NT 4.0 doesn't recognize the physical network topology underlying its architecture and can't directly control WAN usage. NT Server 4.0 uses only its domains and domain controllers to control replication across a network, so the NT Workstation 4.0 client, with help from WINS, chooses which domain controller the client authenticates with, depending on its domain.

When your domain spans several WAN circuits, you can have clients that authenticate to remote domain controllers, a situation that causes slow or failed resource access and slow or failed network logons. Utilities such as Setprfdc can resolve these problems, but the logical nature of NT domains often conflicts with the network topology's physical nature. (For information about Setprfdc, see Mark Minasi, This Old Resource Kit, "SETPRFDC," February 1999.) Microsoft designed AD sites to help the OS understand the physical network topology so that Win2K can define highly connected islands and more intelligently manage traffic.

Microsoft defines a site as a set of IP subnets that have good bandwidth connections. Sites typically have well-connected computers, although well-connected computers aren't a requirement. Several factors (i.e., WAN bandwidth and circuit latency) influence connectivity, and the definition of well-connected computers might vary among companies. Therefore, I can't give you a standardized site boundary definition that you can apply to every circumstance in your company's network. Also, whenever I use the terms computer and server, I'm referring to Win2K systems. NT 4.0 servers aren't site-aware and never will be. However, you can use the Directory Service (DS) client on the Win2K distribution media to make Windows 9x clients site-aware.

You might find it difficult to distinguish sites from domains. The difference between the two is that sites represent the network's physical structure and domains represent the region's or organization's logical structure. You can have several domains in a site, which might be a complicated scenario to manage, or a domain that spans many sites.

Sites serve three functions. First, sites control AD replication more precisely than domains can. Second, sites play a major role in how AD-aware clients locate a domain controller for network authentication. Finally, sites localize client-server resource selection for AD-aware applications (e.g., Win2K's Dfs).

Managing Replication
A good AD site design manages replication to a finer degree than domains alone can. Uncompressed replication between domain controllers inside a site (e.g., your entire network if you don't create sites beyond the original site Default-First-Site-Name) occurs every 5 minutes. Also, administrators can't schedule replication between domain controllers inside a site. AD assumes that good connectivity and reliability exist between domain controllers inside a site and therefore makes low latency a higher priority than paring down network utilization.

When you create AD sites, you can control and configure replication in several ways. You can define how often and when you want replication to occur between sites (the minimum replication interval is 15 minutes). Although AD doesn't compress replication traffic within a site, AD automatically compresses replication traffic between sites. The resulting traffic is 10 to 40 percent of its original size. You can also create links between sites to force replication over virtual paths. And you can assign costs to site routes to influence which routes you want the replication traffic to favor.

Creating AD sites. To create an AD site, you must create the site object, add subnets to it, move preexisting servers into the site, use site links to connect it to other sites, and customize replication between the sites. To show you how to create sites, I'll start with a simple example and build on it. Figure 1 shows a fictitious Texas company that has offices in Dallas, Fort Worth, and Austin. Dallas is the company's WAN hub for the other two locations. For this example, I call each location and its computers a site. Each site has several IP subnets on an Ethernet LAN topology, so sites have well-connected IP subnets. The company has only one domain, and each site has several Win2K domain controllers.

To create the site object, right-click the Sites container on the Active Directory Sites and Services Microsoft Management Console (MMC) snap-in from the Start Menu's Administrative Tools list and select New site to launch the New Object-Subnet dialog box, which Screen 1 shows. Enter the site name, and don't use spaces. I recommend that you follow DNS naming conventions because you store site names in DNS SRV records. Select the site link object that this site will use (i.e., the path that will connect this site to other sites), and choose OK. A message will tell you that to complete the site definition, you must use site links to link the new site to other sites, add subnets to the new site container, install domain controllers or move them into the site, and select the licensing computer for the site.

Before you can add subnets to the site, you must add your subnets to AD in the Subnets container. Launch the Active Directory Sites and Services snap-in, right-click the Subnets container, and select New Subnet. For each subnet you want to define, enter the subnet address and subnet mask that defines the subnet's size. Assign these parameters to a site, and click OK.

You next move servers into the appropriate sites. Right-click a server name and select move from the context menu. In the resulting Move Server dialog box, choose the destination site, as Screen 2 shows. You don't need to reboot your servers after you move them. If you create new servers after you moved your initial servers and the new servers have IP addresses that match site subnets, the new servers automatically register in the site when they join the domain. If your new servers don't have IP addresses that match site subnets, the servers fall into the Default-First-Site-Name site.

When you define distinct sites instead of leaving your computers in Default-First-Site-Name, you take the first step in managing replication. You ensure that AD-aware clients will preferentially chose a domain controller in their local office location when one is available, which keeps logon authentication traffic local to each site. You also relax the replication interval between these locations from every 5 minutes to the default interval of 3 hours and compress the replicated data between locations.

The example Texas company has network bandwidth difficulties that require a more detailed site configuration. AD replication traffic is always heavy on the network between Dallas and Fort Worth, so you want to minimize this traffic's impact on the WAN's limited bandwidth between the two sites. Also, the Dallas-Austin AD replication traffic is heavy during the day, but not at night because the office closes at 7:00 p.m. You can use several site features to minimize the Win2K replication traffic, but before you learn how to use them, you need to understand the concept of site links.

Configuring site links. Site links are virtual circuits (VCs) that exist between sites for Win2K replication traffic. Site links typically control replication between two member sites. You can use two transports to create site links—SMTP and remote procedure call (RPC) over TCP/IP (which appears as IP in the snap-in). Ninety-five percent of your site links will use the IP transport. Site links use SMTP transport for situations such as transporting traffic over highly unreliable links to a remote site, or transporting over a firewall that doesn't pass RPC traffic on ports 137 and 139. Unlike a real telecommunication circuit, a site link can connect more than two sites. Therefore, site links are useful when you want all the sites that use the link to have the same intersite replication characteristics. DEFAULTIPSITELINK, which Screen 3 shows, is the default site link for IP connections and acts as a shared site link because when you don't add explicit links, all sites use it.

To configure site links in the AD Sites and Services snap-in, click the plus sign that is next to the Inter-Site Transports container (or double-click the container) to view the IP and SMTP containers. Right-click the IP container, then select New Site Link. Screen 4 shows the New Object-Site Link dialog box that appears. You next create the Dallas-FortWorth site link in a point-to-point configuration. You can also add Austin and Default-First-Site-Name to the list of sites that use this site link. However, adding Default-First-Site-Name is redundant to DEFAULTIPSITELINK because every new site uses DEFAULTIPSITELINK by default. If you add all the sites to the link that you create and don't change cost parameters or the schedule, the link will act like DEFAULTIPSITELINK. Name a site link to identify the sites that it links (name the hub site first, which is Dallas-FortWorth in the example) to ensure that the site links line up in a readable manner in the Administration MMC snap-in.

Customizing replication. After you add site links, you can customize replication between the sites to tailor the replication to each location's business needs. To customize replication between the sites for the Texas company, right-click the Dallas-FortWorth site-link object under the IP container of the Inter-Site Transports container to edit the properties of the Dallas-FortWorth site link. The site-link Properties dialog box looks the way it did when I originally created the link, except I added three controls—cost, replication interval, and replication schedule.

You use the replication control on the Dallas-FortWorth Properties dialog box to decrease the replication interval between Dallas and Fort Worth from its default of 3 hours to 1 hour, as Screen 5 shows. The replication will be more frequent but smaller, and you reduce the amount of time it takes a change to propagate across the enterprise between the sites. To avoid the heavy Dallas-Austin Win2K replication traffic during daylight hours, configure the Dallas-Austin site link to prevent replication between 7:00 a.m. and 7:00 p.m, as Screen 6 shows. You can also decrease the replication interval from 180 to 30 minutes so that changes that occur at the other sites before 7:00 a.m. will replicate to Austin right away. Figure 2 shows the final site design with the site links that I created for the Texas company.

Client-Domain Controller Selection
Site designs influence the site-aware client's Win2K domain controller selection for network authentication. (Windows 2000 Professional—Win2K Pro—or Win9x with DS are site-aware clients.) In NT 4.0, a client chooses a domain controller from the domain that the client's account belongs to. The list of domain controllers that WINS returns influences the domain controller choice, but you can't guarantee that the client will receive the network's closest domain controller. For example, if your domain exists on the US East Coast and in Europe, a server in Frankfurt, Germany, might perform domain authentication for New York clients. Until you reset the New York server's secure channel, the client requests need to traverse the Atlantic Ocean twice to gain access to a New York resource. You can use several utilities (e.g., Setprfdc) to manually force a selection, but a good Win2K site design can make using a utility to continually monitor and fix the problem unnecessary.

In Win2K, site-aware clients that use a DNS server that supports SRV records (i.e., Internet Engineering Task Force—IETF—Request for Comments—RFC—2052) and dynamic update (i.e., RFC 2136) will try to establish a session with an available domain controller in the client's site before searching for other domain controllers. If the client can't find a domain controller in its site and you don't have domain controllers in other sites that you flagged for site coverage, the client will search the entire domain, as NT 4.0 does.

For the Texas company, users will authenticate on their local networks, regardless of network traffic conditions and domain controller speeds. A Dallas client will always choose a Dallas domain controller for its network authentication, and Austin users won't accidentally use the congested Dallas-Austin circuit. The Win2K client's domain controller selection process is complex, so I'll save the details for a future article. (For more information about domain controller selection, see Microsoft's Windows 2000 Advanced Server Help Files at http://www.microsoft.com/windows2000/downloads/otherdownloads/helpfiles/adserver.asp?lang=en.)

Localizing Client/Server Resource Selection
Site designs also influence local resource selection of AD-enabled client/server applications. Dfs demonstrates this site feature well because Dfs understands sites. Dfs lets administrators create a logical folder hierarchy of easy-to-remember names that map to physical Uniform Naming Convention (UNC) names (i.e., \servershare) across the network. The Dfs replica sets feature lets one logical folder map to several UNC names across your network; each UNC name hosts identical data. If the servers hosting the UNC names (i.e., replica servers) are Win2K servers that registered in the same site as the site-aware client, the client will favor a replica server in its site.

For example, an Austin user in the fictional Texas company wants to download software from a network share named \bigtexsoftware. This server's software share is a Dfs replica set, with replicas in Fort Worth, Dallas, and Austin. The Austin Win2K Pro user who connects to \bigtexsoftware will set up a session with \aus01software, as Figure 3 shows. This example demonstrates how a site-aware client can incorporate AD sites into its client/server application design to connect to a generic UNC name. Win2K directs the client to an application server at the client's site.

Plan Your Site Design
A well-planned site design will provide immediate benefits to your Win2K deployment, especially when you have a congested network. When you plan your site design, work closely with your WAN network engineering group to minimize Win2K's impact on the network. Site design is a series of compromises and decisions that you must make, so before you start creating your sites, you need to dig deeper into this subject. Next month, I'll cover advanced topics in site topology and design, so stay tuned.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.