A. Sites are defined in terms of IP subnets, and when you have multiple physical sites, you need to associate all existing IP subnets at each location with the correct AD site. Doing so ensures that clients at those sites will use resources at their local site when possible. If for some reason (usually by mistake) a subnet hasn't been defined, a client that has an IP address within that subnet range doesn't belong to a site and therefore will use any domain controller (DC) in the organization instead of a DC that's local to the client's site.
To ensure that all clients within your organization are associated with a local site, you can create a catch-all subnet and link it to your main corporate or hub site. For example, if all my subnets were within the Class B range of 10.1.x.x, I could define a 10.1.0.0/16 subnet and link it to the corporate site. Any subnet that wasn't specifically defined and linked to other sites will cause clients that have IP addresses in those missed ranges to "think" they're in the corporate site. Although not ideal, this approach is better than having a client that doesn't belong to a site and possibly using DCs in remote, slowly linked locations.
Creating a catch-all subnet doesn't typically present a problem because the client's site is based on the most specific match, not the first match. For example, if the following site definitions exist:
- Corporate: 10.1.1.0/24, 10.1.2.0/24 and 10.1.0.0/16
- London: 10.1.3.0/24
- Dallas: 10.1.4.0/24
and a client has an address of 10.1.3.25, although that address is within the 10.1.0.0/16 range, it actually belongs to the London site (10.1.3.0/24), which is a more specific match (more bits used for the subnet). This catch-all subnet can also be a savior if your network team decides to add new subnets. The catch-all provides you some safety, although you should still keep your site definitions as accurate as possible to ensure that clients use local resources when they can.
