Active Directory Subnets
A single, physical network can be broken into smaller segments called subnets in a process called subnetting. Each subnet on a network is connected by routers. Every device in a network, whether it’s a domain controller (DC), a server, or a client, must belong to a particular subnet. By using subnets, an organization won’t need to acquire a new network number through its ISP.
When an organization deploys Active Directory (AD), it needs to create subnet objects for each subnet that exists in its overall network infrastructure. Each subnet object is then associated with a single site object within AD.
Active Directory Sites
A site object is made up of one subnet or a group of subnets connected by high-speed links. When promoting DCs, they are placed within a site (called Default-First-Site-Name) which gets created automatically. If additional sites are created, DCs can then be moved between sites.
An organization with offices in different geographical locations may find it beneficial to create sites for the following reasons:
- Authenticating and authorizing users can be managed locally as much as possible.
- Replication traffic can be streamlined and unnecessary network traffic can be avoided during business hours.
Client computers will always attempt to get their AD services from DCs that are within their same site before contacting DCs in other sites. This enables more efficient use of network bandwidth. Learn more about Active Directory Sites and how to configure them in this article.
How to create a new site
The following steps illustrate how to create an AD site:
- Go to Start → Administrative Tools → Active Directory Sites and Services. The Active Directory Sites and Services Window opens.
- In the left pane, right click Sites and click on New Site.
- Give the new site a suitable name. Select DEFAULTIPSITELINK, and click OK.
You now have created a new AD site.
Site links, site link bridges, and site link bridgeheads
Site links: Site links determine the AD replication paths between sites to help control the path of replication traffic. By creating a site link, two or more sites are enabled to connect to each other. Each site link has the three following attributes:
- Cost: The cost represents the preference to use a particular site link as compared to other site links; it has nothing to do with the actual cost of setting up that link, and is a notional value. Cost values can range anywhere from 1 – 32,767. The default cost value is always 100. This attribute becomes critical when multiple site link paths are available between two sites. The site link with the lowest cost is always preferred in such a scenario.In the scenario depicted above, the cost of site link AC is 100, the cost of site link AB is 50, and the cost of site link BC is 60. Therefore, the most cost-effective way for replication between sites A and C is through site link AC (the cost is 100). The site links AB and BC (with a total cost of 110) would only be used if the connection between A and C goes down.
- Frequency: The frequency, also known as the interval or replication latency, is the time period between each replication on a particular site link. The frequency can be set anywhere from a minimum of 15 minutes to a maximum of 10,080 minutes (one week). The default is set at 180 minutes.
- Schedule: The schedule determines the times when the site link is available for replication between sites. The schedule can be set so that replication only occurs at specific times in a given day, or only on specific days. The default is set to 24 hours a day, on all days.
Site link bridge: All site links are transitive by default since the Bridge all site links value is automatically enabled. This means that if a site link is created between sites A and B, and another site link between sites B and C, an automatic site link bridge is created between sites A and C.
There are some scenarios where the Bridge all site links value needs to be disabled. For example, this might happen if the company’s network is not fully routed and the administrator needs to model the actual routing behavior. It could also happen when the administrator wants to exert more control over the replication process.
Site link bridgehead: When two sites are connected by a site link, one DC is randomly selected in each site as the site link bridgehead server. When replication happens between two sites (intersite replication), data is first sent from one bridgehead server to the other bridgehead server.
For example, when replication needs to happen between site A and site B, site A’s bridgehead server will replicate the data to site B’s bridgehead server. Site B’s bridgehead server will then replicate the data to the other DCs within site B. If the bridgehead is down, another DC is automatically selected as the bridgehead.
Preferred bridgehead server: The site link bridgehead server is automatically selected at random. However, an administrator can override this and specify a particular DC as the preferred bridgehead server. If the preferred bridgehead server goes down, there will be no replication until the link comes back up again. Therefore, administrators usually configure more than one preferred bridgehead server for fault tolerance.
Active Directory Sites: An example
Suppose that an organization has three offices. The headquarters is located in Chennai, and two other remote offices are located in Bengaluru and Delhi. Let’s assume that 5,000 employees work out of the Chennai office, and there are 1,000 employees in both the Bengaluru and Delhi offices.
The company has decided to have four DCs in the Chennai office, three DCs in the Bengaluru office, and two DCs in the Delhi office. The company has also decided to divide its network into five subnets in its main office in Chennai. It has two subnets at its Bengaluru office, and one subnet at its Delhi office. The company has assigned the five subnets in Chennai to one site. Similarly, it has assigned the two subnets in the Bengaluru office to one site, and the single subnet in the Delhi office to one site.
By creating sites, the company can ensure that users from a particular site (Chennai, Bengaluru, or Delhi) always get authenticated by a local DC. It can also ensure that intersite replication only takes place during non-business hours if it so desires. This could help the company reduce the strain on its network during business hours. In this way, traffic could be contained to local networks powered by high-speed LANs as much as possible. The figure below depicts our discussion in the example.
What if sites were not created?
If this company hadn’t created sites, replication between all nine domain controllers in the three different geographical locations would happen in the default manner. The company would only have one site, with all nine DCs associated with that site. Intrasite replication would take place so that each DC gets updated with the most recent data. And when this happens, replication traffic would be sent over the slow WAN links that usually exist between geographic locations.
Furthermore, authentication could happen through any DC. When a user wants to join the office network, they would need to send a request to all nine DCs. The first DC to respond would establish a connection and authenticate the user. This means there could be a situation where an employee from the Bengaluru office wants to log in to the network, but they reach the DC at the Chennai office. This may not seem like it would use much data because it’s only for a single user. However, if thousands of users try logging in and each of them reaches DCs at the Chennai site, it could lead to bandwidth issues, reduced connection speeds, and decreased employee productivity.
