Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
control, such as delegating authority to a local administrator to their AD site. This section
discusses Active Directory site administration.
18
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 configu-
ration 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.
552
CHAPTER 18
Windows Server 2008 R2 Administration
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
ptg
services from a domain controller that is not directly connected to a LAN. This authenti-
cation 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.
Examining Active Directory Site Administration
553
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 applica-
tions 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
ptg
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 con-
18
trollers, 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 authentica-
tion, 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 addi-
tional 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.
554
CHAPTER 18
Windows Server 2008 R2 Administration
The job of configuring and creating sites belongs to the administrators who manage Active
Directory, but those who manage the network must be well informed and possibly
involved in the design. Whether Active Directory and the network are handled by the
same or different groups, they affect each other, and undesired network utilization or failed
network connectivity might result. For example, if the Active Directory administrator
defines the entire enterprise as a single site, and several Active Directory changes happen
each day, replication connections would exist across the enterprise, and replication traffic
might be heavy, causing poor network performance for other networking services. On the
other side, if the network administrator allows only specific ports to communicate between
certain subnets, adding Active Directory might require that additional ports be opened or
involve specific network requirements on the servers at each location.
For these examples, the company locations and IP addresses in Table 18.1 will be used.
The company has a hub-and-spoke topology, with each branch office connected to the
main office. The main office has an IPv4 and an IPv6 subnet.
TABLE 18.1
Common Subnet Mask to Prefix Length
Location
Role
Subnets
WAN Link
ptg
Oakland, USA
Main Office
192.168.3.0/24
2001:db8:1234:5678::/64
Boston, USA
Branch Office
192.168.10.0/24
T3
Paris, France
Branch Office
192.168.11.0/24
T1
Tokyo, Japan
Branch Office
192.168.12.0/24
T1
Creating a Site
When creating a site, Active Directory and network administrators must decide how often
AD will replicate between sites. They also must share certain information such as the line
speed between the sites and the IP addresses of the servers that will be replicating.
Knowing the line speed helps determine the correct cost of a site link. For the network
administrator, knowing which IP addresses to expect network traffic from on certain ports
is helpful when troubleshooting or monitoring the network. To create a site, the AD
administrator needs a site name and subnet and also needs to know which other sites will
replicate to the new site.
To create a site, follow these steps:
1. Launch Server Manager on a domain controller.
2. Expand the Roles folder.
Configuring Sites
555
NOTE
The Server Manager console is used extensively throughout this chapter and is often
the central point of administration. See Chapter 20, “Windows Server 2008 R2
Management and Maintenance Practices,” for details on the Server Manager console.
3. Expand the Active Directory Domain Services folder.
4. Expand the Active Directory Sites and Services snap-in.
5. Right-click the Sites container and choose New Site.
6. Type in the name of the site and select any existing site link, as shown in Figure
18.1. Then click OK to create the site.
ptg
18
FIGURE 18.1
Creating a new site.
7. A pop-up window might appear, stating what tasks still need to be completed to
properly create a site. Read the information, take notes if necessary, and click OK.
Repeat this for each site that needs to be created. For the sample company, Table 18.2 lists
the sites that will be created.
TABLE 18.2
Company ABC Sites
Location
Site Name
Oakland, USA
Oakland
Boston, USA
Boston
556
CHAPTER 18
Windows Server 2008 R2 Administration
TABLE 18.2
Company ABC Sites
Location
Site Name
Paris, France
Paris
Tokyo, Japan
Tokyo
Creating Site Subnets
After you create a site, it should be listed in the console window. To complete the site
creation process, follow these steps:
1. Within the Active Directory Sites and Services snap-in, right-click the Subnets
container, and choose New Subnet.
2. Type in the address prefix in the Prefix field—for example, 192.168.3.0/24 for the
Oakland site IPv4 subnet.
NOTE
The address prefix is the IP address and the mask entered in network prefix notation.
This is the format “IP network address/prefix length.” This is very similar to the IP
address and subnet mask format. Table 18.3 lists some common subnet masks and
ptg
their prefix length values.