Windows Server 2008 R2 Unleashed (113 page)

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

Configuring Sites

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.