Windows Server 2008 R2 Unleashed (112 page)

configurations can be created; they will ensure that the servers built in the production

ptg

environment will have the same fundamental configuration as was tested in the lab.

A more detailed build document can be created that walks the technician through the

exact steps required to build the Windows Server 2008 R2 system, in cases where many

network servers need to be created in a short period of time.

The level of effort or the amount of time to actually perform the upgrade or the migration

of a sample subdirectory can be recorded as part of the documentation, and this informa-

tion can be very helpful in planning the total amount of time that will be required to

perform the upgrade or migration.

Determining Whether a Prototype Phase Is Required

The issue of whether a more complete prototype phase is needed or if a more limited

application compatibility testing phase is sufficient has come up several times in this

chapter. The essential difference between the two is that the prototype phase duplicates as

exactly as possible the actual end state of the upgrade, from server hardware to peripherals

and software, so that the entire upgrade process can be tested to reduce the chance of

surprises during the production upgrade. The application testing phase can be less exten-

sive, involve a single server or virtual servers, and be designed to verify that the applica-

tions required will work reliably on the Windows Server 2008 R2 configuration.

Compatibility testing can take as little time as a week—from goal definition, to research,

to actual testing. A prototype phase takes considerably longer because of the additional

steps required.

Summary

547

The following is a checklist that will help your organization make the decision:

. Is sufficient budget available for a subset of the actual hardware that will be used in

the upgrade?

. Is sufficient time available for the configuration of the prototype lab and testing of

the software?

. Are the internal resources available for a period of time long enough to finish the

prototype testing? Is the budget available to pay for external consulting resources to

complete the work?

. Is the Windows networking environment mission-critical to the business’ capability

to go about its daily activities and generate revenues, and will interruption of

Windows services cost the company an unacceptable amount of money?

. Does the actual migration process need to be tested and documented to ensure the

success of the upgrade?

. Do resources need to be trained on the upgrade process (building the servers, and

configuring the network operating system and related applications)?

. Do the applications that will be tested need to be compatible with 64-bit processor

ptg

architecture?

If you find that the answer to more than half of these questions is yes, it’s likely that a

prototype phase will be required.

17

Summary

Windows Server 2008 R2 compatibility testing should be performed before any upgrade or

migration. The process can be completed very quickly for smaller networks (basic testing)

or for larger networks with fairly simple networking environments.

The first steps include identifying the scope and goals of the project to make sure that the

stakeholders are involved in determining the success factors for the project. Then research

needs to be performed, internal to the company, on which in-place applications are

network-related. This includes not only Windows Server, but tape backup software,

antivirus software, network management and monitoring tools, add-ons, and inventory

sheets created summarizing this information. Decisions as to which applications are criti-

cal, near-critical, or just nice to have should also be made. Research should then be

performed with the vendors of the products, tracking sheets should be created to record

this information, and the application should be categorized in one of six states of compat-

ibility. Next, the testing begins, with the configuration of the lab environment that is

isolated from the production network, and the applications are loaded and tested by both

administrative and end user or help desk staff. The results are then documented, and the

final decisions of whether to proceed are made.

548

CHAPTER 17

Compatibility Testing

With this process, the production upgrade or migration is smoother, and the likelihood of

technical problems that can harm the business’ ability to transact or provide its services is

greatly reduced. The problems are identified beforehand and resolved, and the resources

who will perform the work gain familiarity with all the products and processes involved.

Best Practices

The following are best practices from this chapter:

. Take the time to understand the goals of the project (What will the organization

gain by doing the upgrade?), as well as the scope of the project (What is included

and what is excluded from the project?).

. Understand all the applications that connect with Windows Server 2008 R2 and

whether they are critical, near-critical, or simply nice to have.

. Accelerate a migration to Windows Server 2008 R2 by using the MAP toolkit.

. Document the research process for each application because this will prove to be

very valuable if problems are encountered during the testing process.

. Create a lab environment that is as close to the final end state of the upgrade as possi-

ptg

ble. This reduces the variables that can cause problems at the least opportune time.

. Test applications for compatibility with both typical end users of the application and

application administrators who support, maintain, and manage the application.

. Leverage Virtual Server technology to minimize the cost associated with procuring

hardware for a test lab.

. Ensure that applications have been tested for compatibility with a 64-bit operating

system, such as Windows Server 2008 R2.

CHAPTER 18

IN THIS CHAPTER

Windows Server 2008 R2
. Defining the Administrative

Model

Administration
. Examining Active Directory Site

Administration

. Configuring Sites

. Examining Windows Server

2008 R2 Active Directory

Groups

Administrators can administer a Windows Server 2008 R2

infrastructure by learning only a few simple tasks and

. Creating Groups

applying them at different levels and to different objects.

. Managing Users with Local

This enables the administrator to easily scale the adminis-

Security and Group Policies

tration of the infrastructure without proportionally increas-

ing the work. However, this requires defining and enforcing

. Managing Printers with the

Print Management Console

an administrative model.

The overall management of an environment is composed of

ptg

administrative tasks that touch almost every aspect of the

network, including user administration, server and worksta-

tion administration, and network administration. For

example, in a single day, an administrator might check for a

successful server backup, reset a user’s password, add users to

or remove them from existing groups, or manage local area

network (LAN) and wide area network (WAN) hardware.

Although each of these tasks can independently be very

simple or difficult in nature, administrators should at least

understand their portion of the overall enterprise network

and understand how the different components that make

up the network communicate and rely on one another.

Active Directory forms the basis for the administrative

model in Windows Server 2008 R2. The Active Directory

structure is used to control the authorization and access to

other technologies such as Microsoft Exchange 2007,

System Center Operations Manager 2007, and SharePoint

2007. This chapter focuses on the common Windows Server

2008 R2 Active Directory (AD) user and group administra-

tive tasks and touches on the management of Active

Directory sites to optimize user access and replication

performance.

550

CHAPTER 18

Windows Server 2008 R2 Administration

Defining the Administrative Model

Before the computer and networking environment can be managed effectively, an organi-

zation and its IT group must first define how the tasks will be assigned and managed. The

job of delegating responsibility for the network defines the organization’s administrative

model. Three different types of administrative models can be used to logically break up

the management of the enterprise network between several IT specialists or departments

within the organization’s IT division. These models are as follows:

. Centralized

. Distributed

. Mixed

When there is no administrative model, the environment is managed chaotically, and the

bulk of work is usually made up of firefighting. Server updates and modifications must

more frequently be performed on the spot without proper testing. Also, when administra-

tive or maintenance tasks are not performed correctly or consistently, securing the envi-

ronment and auditing administrative events are nearly impossible. Environments that do

not follow an administrative model are administered reactively rather than proactively.

To choose or define the correct administrative model, the organization must discover what

ptg

services are needed in each location and where the administrators with the skills to

manage these services are located. Placing administrators in remote offices that require

very little IT administration might be a waste of money, but when the small group is

composed of VIPs in the company, it might be a good idea to give these elite users the

highest level of service available.

The Centralized Administration Model

The centralized administration model is simple in concept: All the IT-related administra-

tion is controlled by one group, usually located at one physical location. In the centralized

model, all the critical servers are housed in one or a few locations instead of distributed at

each location. This arrangement allows for a central backup and always having the correct

IT staff member available when a server fails. For example, if an organization uses the

Microsoft Exchange 2010 messaging server and a server is located at each site, a qualified

staff member might not be available at each location if data or the entire server must be

recovered from backup. In such a scenario, administration would need to be handled

remotely if possible, but in a centralized administration model, both the Exchange Server

2010 administrator and the servers would be located in the same location, enabling recov-

ery and administration to be handled as efficiently and effectively as possible.

The Distributed Administration Model

The distributed administration model is the opposite of the centralized model in that tasks

can be divided among IT and non-IT staff members in various locations. The rights to

perform administrative tasks can be granted based on geography, department, or job func-

tion. Also, administrative control can be granted for a specific network service such as

Examining Active Directory Site Administration

551

domain name system (DNS) or Dynamic Host Configuration Protocol (DHCP). This allows

separation of server and workstation administration without giving unqualified adminis-

trators the rights to modify network settings or security.

Windows Server 2008 R2 systems allow for granular administrative rights and permissions,

giving enterprise administrators more flexibility when assigning tasks to staff members.

Distributed administration based only on geographical proximity is commonly found

among organizations. After all, if a physical visit to the server, workstation, or network

device is needed, having the closest qualified administrator responsible for it might prove

more effective.

The Mixed Administration Model

The mixed administration model is a mix of administrative responsibilities, using both

centralized and distributed administration. One example could be that all security policies

and standard server configurations are defined from a central site or headquarters, but the

implementation and management of servers are defined by physical location, limiting

administrators from changing configurations on servers in other locations. Also, the rights

to manage only specified user accounts can be granted to provide even more distributed

administration on a per-site or per-department basis.

ptg

Examining Active Directory Site Administration

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 authentica-

tion and network resource access. It can also serve as a boundary of administrative