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
operates 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 their 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 provided within that site. Some of the components, such as the
servers and workstations, are dynamically configured to a site based on
their network configuration. Domain controller services and Distributed
File System (DFS) targets are also located within sites by the network
configuration of the server on which the resources are hosted.
AD sites can be
configured to match a single or many locations that have high-bandwidth
connectivity between them. They can be optimized for replication and,
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 changes are made to network addressing, domain
controllers are added to or removed from a site, or new sites are added
and old ones are decommissioned.
Examples of sites 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 a 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) 2007. 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 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 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) and the frequency and schedule of replication is 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 don’t need a
site defined.
Just like with subnet
design, this is also shortsighted, as 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 2007.
Thus, 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, a single site link
can be used. This can be done for just a subset of 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 and/or 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 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 a Site Group Policy Object. 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.
