1. Understanding Sites
When administrators describe their network infrastructure, they
often mention how many sites make up their enterprise. To most
administrators, a site is a physical location, such as an office or a
city. Sites are connected by links—network links that might be as basic as dial-up
connections or as sophisticated as fiber links. Together, the physical
locations and links make up the network infrastructure.
Active Directory represents the network infrastructure with
objects called sites and site
links, and although the words are similar, these objects
are not identical to the sites and links described by administrators.
It’s important to understand the properties and roles of sites
in Active Directory to understand the subtle distinction between
Active Directory sites and network sites. Active Directory sites are
objects in the directory, specifically in the Configuration container
(CN=Configuration,DC=forest root domain). These
objects are used to achieve two service management tasks:
Replication is the transfer of changes between domain
controllers. When you add a user or change a user’s password, for
example, the change you make is committed to the directory by one
domain controller. That change must be communicated to all other
domain controllers in the domain.
Active Directory assumes there are two types of networks
within your enterprise: highly connected and less highly connected.
Conceptually, a change made to Active Directory should replicate
immediately to other domain controllers within the highly connected
network in which the change was made. However, you
might not want the change to replicate immediately over a slower,
more expensive, or less reliable link to another site. Instead, you might want to manage replication
over less highly connected segments of your enterprise to optimize
performance, reduce costs, or manage bandwidth.
An Active Directory site represents a highly connected portion
of your enterprise. When you define a site, the domain controllers
within the site replicate changes almost instantly. Replication
between sites can be scheduled and managed.
Active Directory is a distributed service; that is, assuming you have at least two
domain controllers, multiple servers (domain controllers) provide
the same services of authentication and directory access. If you
have more than one network site, and if you place a domain
controller in each, you want to encourage clients to authenticate
against the domain controller in their site. This is an example of
service localization.
Active Directory sites help you localize services, including
those provided by domain controllers. During logon, Windows clients
are automatically directed to a domain controller in their site. If
a domain controller is not available in their site, they are
directed to a DC in another site that can authenticate the client
efficiently.
Other services can be localized as well. Distributed File
System Namespaces (DFS Namespaces), for example, is a localized
service. DFS clients obtain replicated resources from the most
efficient server, based on their Active Directory site. In fact,
because clients know what site they are in, any distributed service
could be written to take advantage of the Active Directory site
structure to provide intelligent localization of service
usage.
Because sites are used to optimize replication and to enable
service localization, you must spend time designing your Active
Directory site structure. Active Directory sites might not map one to
one with your network’s sites. Consider two scenarios:
-
You have offices in two distinct locations. You place one
domain controller in each location. The locations are highly
connected, and to improve performance, you decide to configure a
single Active Directory site that includes both locations.
-
You have an enterprise on a large, highly connected campus.
From a replication perspective, the enterprise could be considered
a single site. However, you want to encourage clients to use
distributed services in their location, so you configure multiple
sites to support service localization.
Therefore, an Active Directory site can include more than one
network site or be a subset of a single network site. The key is to
remember that sites serve both replication management and service
localization roles. Several characteristics of your enterprise can be
used to help you determine which sites are necessary:
An Active Directory site represents a unit of the network that
is characterized by fast, reliable, inexpensive connectivity. Much
documentation suggests that the slowest link speed within a site
should be no less than 512 kilobits per second (kbps). However, this
guidance is not immutable. Some organizations have links as slow as
56 or even 28 kbps within a site.
Because Active Directory sites manage Active Directory
replication and service localization, it is not useful to create a
site for a network location that does not host a domain controller
or other Active Directory–aware service such as a replicated DFS
resource.
Note
SITES WHERE THERE ARE NO DOMAIN
CONTROLLERS
Domain controllers are only one distributed service in a
Windows enterprise. Other services, such as replicated DFS
resources, are site-aware as well. You might configure sites to
localize services other than authentication, in which case you
will have sites without domain controllers.
Concentration of users can also influence your site design,
although indirectly. If a network location has a sufficient number
of users for whom the inability to authenticate would be
problematic, place a domain controller in the location to support
authentication within the location. After a domain controller or
other distributed service is placed in the location to support those
users, you might want to manage Active Directory replication to the
location or localize service use by configuring an Active Directory
site to represent the location.
Summarizing Site Planning Criteria
Every Active Directory forest includes at least one site. The
default site created when you instantiate a forest with the first
domain controller is creatively named
Default-First-Site-Name. You should create
additional sites when:
-
A part of the network is separated by a slow link.
-
A part of the network has enough users to warrant hosting
domain controllers or other services in that location.
-
Directory query traffic warrants a local domain
controller.
-
You want to control service localization.
-
You want to control replication between domain
controllers.
Sites and replication are managed using the Active
Directory Sites And Services snap-in. To define an Active Directory
site, you create an object of class site. The
site object is a container that manages replication for
domain controllers in the site. You also create one or more subnet objects. A subnet object defines a range of IP
addresses and is linked to one site. Service localization is attained when a client’s IP
address can be associated with a site through the relationship between
the subnet object and the site object.
To create a site:
-
Right-click the Sites node in Active Directory Sites And
Services, and then click New Site.
-
In the New Object – Site dialog box, shown in Figure 1, enter a site
name and select a site link.
The default site link, DEFAULTIPSITELINK, is the only site
link available to you until you create additional site links.
After creating a site, you can right-click it and click Rename
to rename it. It is recommended that you rename the
Default-First-Site-Name site to reflect a site name that is aligned
with your business and network topology.
Sites are useful only when a client or server knows the
site to which it belongs. This is typically achieved by associating
the system’s IP address with a site, and subnet objects achieve this association.
To create a subnet object:
-
Right-click the Subnets node in the Active Directory
Sites And Services snap-in and click New Subnet. The
New Object – Subnet dialog box shown in Figure 2
appears.
-
Enter the network prefix and subnet mask length.
The subnet object is defined as a range of addresses using
network prefix notation. For example, for a subnet
representing the addresses 10.1.1.1 to 10.1.1.254 with a 24-bit
subnet mask, the prefix would be 10.1.1.0/24. For more information
about entering addresses, click the Learn More About Entering
Address Prefixes link in the New Object – Subnet dialog
box.
-
After entering the network prefix, select the site object with which the subnet is associated. A
subnet can be associated with only one site; however, a site can
have more than one subnet linked to it. The Properties dialog box
of a site, shown in Figure 3, shows the
subnets associated with the site. You cannot change the subnets in
this dialog box, however; instead, you must open the properties of
the subnet, shown in Figure 4, to change the
site to which the subnet is linked.
Note
DEFINING EVERY IP
SUBNET
In your production environment, be certain to define every IP
subnet as an Active Directory subnet object. If a client’s IP
address is not included within a subnet range, the client is unable
to determine which Active Directory site it belongs to, which can
lead to performance and functionality problems. Don’t forget
backbone subnets and subnets used for remote access such as virtual
private network (VPN) address ranges.
