Windows Server 2008 R2 Unleashed (79 page)

caching.

.
Sites with 50–100 users—
Use two DCs configured for universal group caching.

.
Sites with 100–200 users—
Use a single GC server and single DC server.

.
Sites with 200+ users—
Alternate adding additional DCs and GC/DCs for every 100

users.

The recommendations listed here are generalized and should not be construed as relevant

to every environment. Some scenarios might call for variations to these approaches, such

as when using Microsoft Exchange Server in a site where Exchange requires close connec-

tion to a global catalog server (not a caching controller) or in single domain/single forest

environments with limited sites where all domain controllers can be global catalog servers.

However, these general guidelines can help to size an Active Directory environment for

domain controller placement.

372

CHAPTER 11

DHCP/WINS/Domain Controllers

Examining Read-Only Domain Controllers

A concept similar to universal group caching, one of the new features for Active Directory

Domain Services in Windows Server 2008 and Windows Server 2008 R2 is the Read-Only

Domain Controller (RODC). An RODC server is a new type of domain controller that

contains read-only replicas of the domain Active Directory database. As shown in Figure

11.22, this is well suited for branch offices or other locations where physical security of

the domain controller can be compromised, where excessive wide area networking activity

might have a negative impact on productivity, or where other applications must run on a

domain controller and be maintained by an understaffed technical department or an IT

department with little technical knowledge. The benefits of RODCs are a read-only Active

Directory Domain Services database, inbound-only replication, credential caching, admin-

istrator role separation, and read-only DNS.

Central Office

Physically Secure

ptg

Windows Server 2008 R2

Writable Domain Controller

Windows Server 2008 R2 RODC

Windows Server 2008 R2 RODC

Branch Site #1

Windows Server 2008 R2 RODC

Branch Site #3

Branch Site #2

FIGURE 11.22

Sample deployment of a Read-Only Domain Controller in a Windows Server

2008 R2 environment.

Although an RODC can replicate data from domain controllers running Windows Server

2003, it can only replicate updates of the domain partition from a Windows Server 2008

Exploring Global Catalog Domain Controller Placement

373

or Windows Server 2008 R2 domain controller running within the same domain. Because

RODCs cannot perform outbound replication, they cannot be a source domain controller

11

for any other domain controller. In contrast, writable Windows Server 2008 R2 domain

controllers and Windows Server 2008 domain controllers can perform inbound and

outbound replication of all available partitions. Thus, they do not require the same place-

ment considerations required by RODCs.

Because an RODC can replicate the domain partition only from a writable Windows Server

2008 R2 or Windows Server 2008 domain controller, careful planning is required. The

placement of an RODC and writable Windows Server 2008 R2 domain controllers is impor-

tant as their deployment might be affected by the site topology and network constraints;

each RODC requires a writable Windows Server 2008 R2 domain controller for the same

domain from which the RODC directly replicates. This requires a writable Windows Server

2008 R2 domain controller be placed in the nearest site that contains a direct site link to

the site in the topology that includes the RODC, as illustrated in Figure 11.22.

An RODC server contains the same objects and attributes as a writable domain controller

with the exception of user passwords. The difference between an RODC server and the

writable domain controller is that changes that originate locally are not made to the

RODC replica itself but are forwarded to a writable domain controller and then replicated

back to the RODC server. Also, the Active Directory administrator can determine or limit

ptg

which user account password or credentials can be cached on a remote RODC. This

improves security by reducing the risk or exposure of the read-only Active Directory data-

base on the RODC.

Active Directory administrators might also specifically configure an RODC to cache user

credentials. The first time a user attempts to authenticate to an RODC, the RODC forwards

the request to a writable domain controller. When authentication is successful, the RODC

requests a copy of the user credentials. By default, the RODC does not cache the pass-

words of any domain users so administrators must modify the default password replica-

tion policy for the RODC to allow the RODC to authenticate users and their computers

when the WAN link to the hub site is unavailable. The active Password Replication Policy

determines if the credentials are allowed to be replicated and cached on the RODC. The

next time that user attempts to log on, the request is directly serviced by the RODC. This

occurs until the RODC is informed by the writable domain controller that a user creden-

tial change has occurred. In the scenario, end-user productivity is vastly improved because

of the efficient logon process. Connectivity issues commonly experienced by branch

offices such as poor network bandwidth or WAN latency are mitigated because the user is

authenticated on the locally deployed RODC. Because the RODC only performs inbound

replication, network traffic is also reduced. To allow a user account’s password to be

cached on a Read-Only Domain Controller, the user will need to be added to the default

“Allowed RODC Password Replication Group” or the user can be added specifically to the

Password Replication Policy on the specific Read-Only Domain Controllers.

RODCs also help reduce security risks and administration tasks associated with branch

office servers. Because Active Directory Domain Services also manages a list of all creden-

tials stored on RODCs, if an RODC is compromised, administrators can force a password

reset for all user credentials stored on that RODC. To further mitigate security risks,

374

CHAPTER 11

DHCP/WINS/Domain Controllers

RODCs cannot operate as an operation role holder (Flexible Single Master Operations

[FSMO]) because this role requires writing of information to the Active Directory database.

Also, RODCs cannot act as a bridgehead server because bridgehead servers are designed to

replicate changes from other sites.

Another feature of RODCs is delegation of installation and management task to non-

administrative personnel at a branch office. Nontechnical branch office personnel can

perform an installation by attaching a server to the RODC account that a domain admin-

istrator has previously created. This eliminates the need to use a home office staging site

for branch office domain controllers. This feature also eliminates the need to send installa-

tion media and a domain administrator to branch locations, which reduces the cost of

server setup and improves setup time at branch locations.

For more information on domain controller and Active Directory, see Chapter 7, “Active

Directory Infrastructure.”

Summary

Although often overlooked, the services of DHCP and WINS are some of the most critical

components of a functional Windows Server 2008 R2 environment. In addition, global

ptg

catalog domain controller placement and related issues are integral to the functionality of

an Active Directory environment. A new feature, the Read-Only Domain Controller,

provides a secure and effective way to set up branch locations. Because end-user creden-

tials can be cached locally on the RODC and inbound-only replication occurs, end users

experience improvements in productivity. As a result, it is important to have a strong

understanding of these components and their related design, migration, and mainte-

nance procedures to ensure the high availability, reliability, and resilience of a network

infrastructure.

Best Practices

The following are best practices from this chapter:

. Perform all tests with DHCP, WINS, and RODC in a lab environment.

. Implement redundancy in a DHCP using split scopes or clustered DHCP services.

. Manually perform a backup of the DHCP database before making any configuration

changes to the server.

. Before enabling link layer filters, first add all of the approved clients to the Allowed

list on all DHCP servers that may service the clients.

. When deploying DHCP in a split-scope configuration, split the scope in an 80/20

split and configure the delay setting on the secondary server scope.

. Before running the DHCP Split-Scope Configuration Wizard, create all of the neces-

sary reservations on the primary DHCP server scope so these can be copied over to

the secondary server by the wizard.

Best Practices

375

. Implement redundant WINS servers by configuring servers as push/pull partners.

11

. Limit the number of WINS servers on the network to reduce WINS server replication

and administration and to simplify WINS troubleshooting.

. When migrating DHCP services from one server to another, use the Windows Server

Migration Tools to assist in transferring DHCP scopes and leases.

. Properly plan the most efficient placement of DCs and GC/DCs in an environment.

. Use a single DC configured with universal group caching for Active Directory sites

with fewer than 50 users that do not need a local GC for services such as Exchange.

. Use at least two DCs in Active Directory sites with between 50 and 100 users.

. Deploy RODCs in branch offices to reduce security risks, reduce network traffic, and

improve end-user logon times.

. When RODCs are deployed, create a new security group and add this group to the

Password Replication Policy of that specific RODC, and add members to this group

as necessary to reduce security exposure.

ptg

This page intentionally left blank

ptg

CHAPTER 12

IN THIS CHAPTER

Internet Information
. Understanding Internet

Information Services (IIS) 7.5

Services
. Planning and Designing Internet

Information Services 7.5

. Installing and Upgrading IIS 7.5

. Installing and Configuring

Websites

Internet Information Services (IIS) has been going through

. Installing and Configuring FTP

continuous change for years, so it isn’t surprising that the

Services

most current version of IIS is Microsoft’s most powerful,

. Securing Internet Information

most reliable, and most secure web server. Without a doubt,

Services 7.5

the fundamental capabilities of IIS 7.5 are exhilarating. The

new web server includes a plethora of new features and

functionality that provide numerous benefits to organiza-

tions hosting applications and developers creating web

applications with the latest .NET Framework. Among other

ptg

things, organizations can also simplify management, reduce

surface area attacks, benefit from improved diagnostic and

troubleshooting capabilities, and enjoy greater scalability.

To reap the full benefits of IIS 7.5, this chapter gives web

administrators the knowledge base necessary to understand

the improvements and new management user interface in

IIS 7.5. The first sections of the chapter focus on planning

an IIS 7.5 infrastructure and installing or upgrading to IIS

7.5. The second sections focus on creating both web and

File Transfer Protocol (FTP) sites, and discuss how to config-

ure the new settings. The final sections of the chapter

discuss how to secure IIS 7.5.

Understanding Internet

Information Services (IIS) 7.5

Organizations and web administrators must fully under-

stand IIS 7.5 before installing, upgrading, or creating sites

with the product. Specifically, they should be familiar with

the new improvements, the new look and feel of the

management tools and user interface, and be comfortable

378

CHAPTER 12

Internet Information Services

with the new working panes associated with administration. The next few sections

examine these areas of interest.

Improvements in Internet Information Services (IIS) 7.5

Several key enhancements and structural changes have been made to the new IIS 7.5 web

and application platform. These enhancements are designed not only to build upon the

latest version of .NET, but also to increase overall reliability, performance, security, and

administration. Some of the major IIS 7.5 improvements that IT professionals, web

hosters, and developers will take pleasure in having include the following:

.
Modular-based installation—
Unlike previous versions, IIS 7.5 is no longer mono-

lithic. The installation process offers more than 40 different features/components.

Although some of these features are installed by default, they can be selectively