Configuring and Managing Forest and Domain Trusts
Configuring and Managing AD DS Sites and Replication
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.
- 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
- 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
- A basic understanding of deploying and managing Microsoft Windows servers
- Windows Server installation media and an environment to run Windows Server (trial available at https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2022)
Now that we have our Active Directory sites in place, let's review Active Directory replication. Active Directory replication leverages the Knowledge Consistency Checker service. The Knowledge Consistency Checker service is a process that runs on all domain controllers to generate a replication topology. The Knowledge Consistency Checker keeps the topology up to date as new domain controllers are added, removed, or moved to different sites. It also adjusts replication if a domain controller is temporarily unavailable. The Knowledge Consistency Checker creates a connection object. A connection object represents replication connections from source domain controllers to destination domain controllers.
They represent an incoming connection from another domain controller. The Knowledge Consistency Checker updates these connection objects as changes are made to the environment. Connection objects are stored in the NTDS settings for each server in an Active Directory site. Connection objects created by the Knowledge Consistency Checker are named automatically generated, surrounded by the less than greater than sign. The automatically generated connection objects are sufficient under most circumstances. It is possible to create new connection objects or modify connection objects created by the Knowledge Consistency Checker. Manually created connection objects will have the name given to them when they are created.
If an automatically generated connection is modified, the name is converted to a GUID and it's no longer managed by the Knowledge Consistency Checker. We can see an example of how the Knowledge Consistency Checker works by looking at Azure AD sites and services from the previous demo. We moved each server into its own site. The Knowledge Consistency Checker created two connection objects for the server in site 1. Replication is coming from domain controllers on site 2 and site 3. Site 2 and site 3 have replication connection objects coming from site 1. We didn't have to update any of these connection objects when we moved the domain controller.
The Knowledge Consistency Checker updated them for us. When we talk about Active Directory replication, there are two types of replication to be aware of, intrasite and intersite. Intrasite replication takes place between domain controllers within an Active Directory site. Domain controllers in a site are well connected with less than 10 milliseconds of latency. The Knowledge Consistency Checker creates a bidirectional ring of domain controllers in a site. By default, a domain controller will notify its replication partner of a change 15 seconds after the change is made. Replication every 15 seconds over a bidirectional ring works fine for domain controllers on a well connected network. However, this configuration could be taxing over a LAN connection.
Intersite replication defines how Active Directory data is replicated between sites. In addition to providing client affinity, sites also specify a boundary of well connected computers. Logical connections between the sites are used to manage replication between them. These logical connections are called site links. Each Active Directory site is connected by a site link. There are two types of site links available. An IP-based site link and an SMTP site link. The IP site link uses Remote Procedure Call or RPC over IP for a synchronous point-to-point connection between sites. This is intended for low speed connections, connections above 10 milliseconds of latency. WAN connections for example.
The SMTP site link is used for low speed asynchronous SMTP-based replication between sites. SMTP site links are only supported for domain controllers from different domains in a forest. Because of that, only schema configuration and global catalog replicate over SMTP. Domain controllers in the same domain require IP site links. As stated previously, intersite replication takes place between sites. Intersite replication does not happen as frequently as intrasite replication. And there's an emphasis on efficiency to better utilize WAN connections. The default replication interval is 180 minutes or three hours with a minimum setting of 15 minutes. A site link called DEFAULTIPSITELINK is created by default in Active Directory. In the previous demo, we added all three sites to the Default IP Site Link. This is an acceptable configuration if connectivity between all three sites is the same, but that's not always the case.
Sometimes the physical connection may have multiple routes between sites with different performance characteristics, or we could have a hub and spoke design where all traffic is routed through a central location before reaching a different site. Site links are used in Active Directory to tune the replication path between sites. A site link reflects the physical connectivity between sites. For example, if we have three sites with one site link, the Knowledge Consistency Checker will treat each path between the sites as equal. In this example, the physical connectivity may not be the same. There may be no connectivity between sites 1 and 3. All traffic between sites 1 and 3 route through site 2.
The replication traffic between site 1 and site 3 flow through site 2. It would be more efficient for the domain controller in site 3 to replicate directly with the domain controller in site 2 instead of 1. We can accomplish that by creating two site links, one linking site 1 to site 2, and a second linking site 2 to site 3. The Knowledge Consistency Checker uses the site link information to calculate the best replication path. In addition to replication frequency, we can also assign a cost to the site link. A cost is used to calculate the best route with a preference for the lowest number. The Default IP Site Link has a cost of 100. Let's look at the previous example. This time we have a slower connection between site 1 and 3. We could create a site link with a higher cost between those two sites. This configuration will replicate over the connection with the lowest cost. If that link becomes unavailable, the next highest site link is used.
This way, replication can still take place over a less optimal connection until the lower cost connection becomes available. When two sites are connected with a site link, the Knowledge Consistency Checker creates a connection between domain controllers at each site. These domain controllers are called bridgehead servers. All domain controllers in a site are candidates to become bridgehead servers. Bridgehead servers are selected randomly by the Knowledge Consistency Checker. Putting it all together, we have well connected sites with intersite replication taking place 15 seconds after changes are made. The sites are connected by relatively slow WAN connections, relatively slow compared to the fast LAN connection.
These connections are represented in Active Directory as site links. The site links are assigned a replication interval and the cost that represents the underlying network characteristics. The Knowledge Consistency Checker uses this cost to calculate replication paths. Intersite replication takes place between bridgehead servers. These servers are randomly selected from each site to facilitate replication between sites. That's an overview of intrasite and intersite replication in Windows Active Directory domain services. Please join me in the next demo to create site links in Active Directory.
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.