Active Directory Domain Services Sites and Topology
Start course

Windows Active Directory Domain Services (AD DS) is a leading identity management solution for organizations of all sizes. An AD DS deployment can be as simple as a single domain controller or as complex as a multi-domain forest spread across the globe. Managing sites, domains, and forests in an AD DS environment is critical to a healthy and reliable Active Directory infrastructure. This course is intended to provide the information needed to successfully manage Windows AD sites, domains, forests, trust relationships, and replication.

In this course, we start by reviewing AD DS forest and domain trusts. Then we examine forest design considerations to create a scalable environment that can meet future demands. Next, we investigate Active Directory sites, site links, and how they relate to the organization's network configuration.  Finally, we evaluate AD DS replication and how site links can optimize replication in an AD DS environment.

Learning Objectives

  • Windows AD domains, forests, and trust relationships
  • Windows AD forests and domain design considerations
  • Creating a two-way forest trust
  • Active Directory sites and site topology
  • Creating an Active Directory site
  • Windows AD sites and replication
  • Creating Active Directory site links

Intended Audience 

  • System administrators with responsibilities for managing hybrid identities
  • Subject matter experts in configuring and managing Active Directory workload on-premises and in Azure
  • Anyone preparing for the Azure AZ-800: Administering Windows Server Hybrid Core Infrastructure exam



Welcome to the lecture where we review Active Directory Site Topology. As a point of reference, let's recap Active Directory domain service's logical configuration. We have a forest and in that forest are domains. All the domains hold a partition of the directory and our administrative boundaries. All domains in the forest are connected with transitive trust relationships. This is the logical layout of domains in a forest, but the actual physical layout of domains in the forest could look significantly different. For example, while it may be possible that each domain is associated with a physical location, that is not always the case. It's possible instead to have a forest structure that maps to different business units, all in the same building. 

Or we could have domains that map to multiple locations. These locations could be in the same campus or spread across the globe. When a domain user logs in at a location, the local domain controller is the most efficient option for processing the login request, but without any information about the physical location, a domain controller across the globe may process the login instead. This could lead to delays due to latency and excessive land traffic. To overcome this issue, Active Directory introduced the concept of sites. 

A site represents a well connected physical location. Generally, 10 milliseconds or less of latency is considered well connected. When we deploy the first domain controller in a forest, a default site called Default-First-Site-Name is created and all domain controllers are added to that site. This is fine for a single location, but for a multiple site deployment, additional sites are required. For example, let's say we have one Active Directory domain and the company has three locations. Each location could be a single floor in an office or a campus connected by high speed fiber optic cables. All the locations are connected by a wide area network connection. This layout will use three sites, one for each physical location. 

But that leads us to the question, how do we identify what location the servers and clients are located at? The solution is found with the organization's network. Each site maps to one or more subnets on the organization's internal network. A subnet is a block of IP addresses allocated for computing resources. Subnets and IP addresses are unique to the network. The most common practice is to use private non-routable IP addresses for the internal network. These are blocks of IP addresses that cannot be used on the public Internet. There are three private non-routable IP address spaces. The network, the 1/ network, and the network. 

These private IP address ranges can be subnetted or split into smaller blocks of IP addresses. Each site has one or more well connected subnet. All servers and clients at that site will get an IP address that's part of one of those subnets. By associating each subject with a site, Active Directory gains awareness of the site clients and servers are on. This awareness and Active Directory provides client affinity. Client affinity provides a way for domain controllers to pass information to clients about the closest domain controllers to the client. For example, let's say a user from site 2 travels to site 3. When they initially log into site 3, the client may try to authenticate to its last known domain controller at site 2. 

The domain controller will see that the client is on site 3 based on their IP address and direct the client to a domain controller at site 3. Sometimes there may be a reason not to put a domain controller at a specific site. Maybe it's a small location with a reliable connection to a domain controller at another location, or there are security reasons not to deploy a domain controller at that location. In this case, it's best to include the subnet with a site that has the best connectivity to the location. 

This will set client affinity to the best connected site. Successfully creating and managing Active Directory sites requires knowledge of the organization's networking topology. It requires an understanding of the Local Area Network or LAN and the Wide Area Network or WAN, including performance characteristics of each. Also, the user must have rights to create sites, add subnets, and move items in Active Directory. Networks don't stay static. An Active Directory site administrator must also monitor and update sites to correspond with network changes. Coming up next, we'll create site objects in a Windows Active Directory Domain.


About the Author

Travis Roberts is a Cloud Infrastructure Architect at a Minneapolis consulting firm, a Microsoft MVP, MCT, and author. Travis has 20 years of IT experience in the legal, pharmaceutical, and marketing industries and has worked with IT hardware manufacturers and managed service providers. In addition, Travis has held numerous technical certifications throughout his career from Microsoft, VMware, Citrix, and Cisco.