Sites can be different things, depending on whom you ask. If you ask an
operations manager, she might describe a site as any physical location
from which the organization conducts business. Within the scope of
Active Directory, a site defines the internal and external replication
boundaries and helps users locate the closest servers for
authentication and network resource access. It can also serve as a
boundary of administrative control, such as delegating authority to a
local administrator to his or her AD site. This section discusses
Active Directory site administration.
Sites
A site is made up of a site name; subnets
within that site; links and bridges to other sites; site-based
policies; and, of course, the servers, workstations, and services
residing within that site. Some of the components, such as the servers
and workstations, are dynamically assigned to a site based on their
network configuration and the site’s definition. Domain controller
services and Distributed File System (DFS) targets are also assigned to
sites based on the network configuration of the server on which the
resources are hosted.
Each AD site is
typically configured to contain resources that have high-bandwidth
connectivity between them. The sites can contain one more physical
location depending on the network architecture. Sites can be optimized
for replication which, during regular daily operations, require very
little network bandwidth. After an AD site is defined, servers and
client workstations use the information stored in the site
configuration to locate the closest domain controllers, Global Catalog
servers, and distributed file shares. Configuring a site can be a
simple task, but if the site topology is not defined correctly, network
access speed might suffer because servers and users might connect to
resources across the WAN instead of using local resources.
As mentioned previously, configuring a site
should take only a short time because there are very few components to
manipulate. In most cases, defining and setting up an Active Directory
site configuration might take only a few hours of work. After initial
setup, AD sites rarely need to be modified unless significant changes
are made to the network topology, including IP addressing changes,
domain controllers added or removed from a site, or new sites added or
old ones decommissioned.
Examples of site topologies and
names might include the name of the city where the company locations
are, airport codes for the cities, or the office identifier if the
company already has one.
Subnets
Subnets define the network boundaries of a
site and limit WAN traffic by allowing clients to find local services
before searching across a WAN link. Many administrators do not define
subnets for locations that do not have local servers; instead, they
relate site subnets only to Active Directory domain controller
replication.
If a user workstation subnet is not defined
within Active Directory, the workstation picks another domain
controller essentially at random. The domain controller could be one
from the same physical location or it could be one on another continent
across multiple WAN links. The user workstation might authenticate and
download policies or run services from a domain controller that is not
directly connected to the same LAN. This authentication and download
across a WAN could create excessive traffic and unacceptable response
times.
In looking at the Active Directory
infrastructure, it might seem that branch offices with no domain
controller could simply be lumped with their central office site by
adding the branch office subnets to the main office site. This would
save a lot of configuration time needed to create those branch office
sites.
This is somewhat shortsighted, as many other
applications are Active Directory aware and leverage the Active
Directory site architecture to control the behavior of their
application. This includes the Distributed File System (DFS) and System
Center Configuration Manager (SCCM) 2012. Thus, it is important to
fully define the Active Directory site architecture, including the
subnets to mirror the WAN architecture of the organization.
All subnets should be defined in
Active Directory Sites and Services to ensure that the proper domain
controller and application server assignments are made to workstations.
And all locations should have their own sites and
subnets defined, even if there is no domain controller currently in the
location. This ensures that resources are allocated correctly by the
Active Directory infrastructure not only for domain services, but for
other services as well.
Site Links
Site links control Active Directory
replication and connect individual sites directly together. A site link
is configured for a particular type of protocol (namely, IP or SMTP)
with the frequency and schedule of replication configured within the
link. Site links are used by the Active Directory Knowledge Consistency
Checker (KCC) to build the proper connections to ensure that
replication occurs in the most efficient manner.
Once again, some administrators do not fully
define the site architecture and don’t create sites for locations that
do not have a domain controller. The reasoning is that the sites are
used by Active Directory for replication, and so domain
controller-challenged locations do not need a site defined.
Just like with subnet design, this is also
shortsighted, because many other applications are Active Directory
aware and leverage the Active Directory site architecture to control
the behavior of their application. Site links are also used by Active
Directory-aware applications to understand the physical topology to
optimize WAN communications. This includes DFS and SCCM 2012.
Therefore, it is important to fully define
the Active Directory site architecture, including both subnets and site
links to mirror the WAN architecture of the organization.
Examples of site links include a
site link for every WAN link, such as from the main office to each of
the branch offices. For fully meshed offices, such as those connected
via meshed Multiprotocol Label Switching (MPLS), a single site link can
be used. This can be done for all offices or just for a subset of
offices (for example, North America offices) if needed.
Site Group Policies
Site group policies allow computer and user
configurations and permissions to be defined in one location and
applied to all the computers/users within the site. Because the scope
of a site can span all the domains and domain controllers in a forest,
site policies should be used with caution. Therefore, site policies are
not commonly used except to define custom network security settings for
sites with higher requirements or to delegate administrative rights
when administration is performed on a mostly geographic basis.
Note
Because sites are usually defined according
to high-bandwidth connectivity, some design best practices should be
followed when you’re defining the requirements for a site. If possible,
sites should contain local network services, such as domain
controllers, Global Catalog servers, DNS servers, DHCP servers, and, if
necessary, Windows Internet Naming Service (WINS) servers. This way, if
network connectivity between sites is disrupted, the local
site network will remain functional for authentication, Group Policy,
name resolution, and resource lookup. Placing file servers at each site
might also make sense unless files are housed centrally for security or
backup considerations.
That said, there are some specific
applications where site group policies can prove to be very useful. For
example, it is a best practice to have virtual private network (VPN)
users assigned to a site in Active Directory. This is accomplished by
creating a VPN site in Active Directory Sites and Services and
assigning the VPN subnet to that site. Then, group policies that add
additional controls can be assigned to the VPN site using the Site
Group Policy object (GPO). That way, when users use their laptop to
connect in the office, they receive the standard set of group policies.
However, when they use the same laptop to connect to the office via the
VPN, they get the additional policies needed for VPN access.
