Windows Server 2008 R2 Unleashed (108 page)

companies contract with migration experts or Microsoft partners—such as Convergent

Computing, also known as CCO—to help companies avoid classic mistakes in the upgrade

process. By the end of this planning process, it will be very clear why the project is

happening, which departments need which features and capabilities, and what budget is

available to perform the work. The timeline and key milestones also will be defined.

If a phased discovery and design process hasn’t been followed, this information needs to

be gathered to ensure that the testing process addresses the goals of the project stakehold-

ers, and that the right applications are in fact tested and verified by the appropriate people.

Determining the Scope for Application Testing

At this point in the process, a list should be put together that clarifies which Windows

Server 2008 R2 version is to be used, which version of server software will be used, which

add-in features are required, and which third-party applications are needed. As discussed

previously, Windows Server 2008 R2 comes in Web, Standard, Enterprise, and Datacenter

Editions. New in Windows Server 2008 R2, the server comes in 64-bit version only, elimi-

nating the 32-bit version of the server operating system. Smaller companies might choose

528

CHAPTER 17

Compatibility Testing

to use the Standard Edition of Windows Server 2008 R2 operating system, whereas larger

organizations might require Enterprise Edition on their server systems for more advanced

scalability and fault tolerance.

A key issue to discuss at this point is whether it is acceptable to have multiple versions of

the Windows Server operating system in the final solution. Some organizations want to

control standards on both software and support services, and require just a single network

operating system such as Windows Server 2008 R2 across the board.

NOTE

Although the Standard Edition of Windows Server 2008 R2 is significantly less expen-

sive than the Enterprise Edition of the license, cost should not be the primary reason

for choosing one version over another. It is a daunting task to upgrade from the

Standard to Enterprise Edition, not as simple as just changing a software license key. It

requires either setting up a brand-new server with the Windows Server 2008 R2,

Enterprise Edition and migrating applications from server to server, or a full upgrade of

the Enterprise Edition over an existing Standard Edition license. An organization should

seriously consider whether it needs the functionality of the Enterprise Edition before

choosing to buy and install the Standard Edition and attempting to upgrade later.

ptg

Third-party applications should be identified as well. The applications most often used

include tape-backup software modules or agents, antivirus software, fax software, and

voicemail integration products. Additional third-party add-on products might include

the following:

. Administration

. Antispam

. Backup and storage

. Customer relationship management (CRM)

. Log monitoring

. Line-of-business applications

. Migration

. Reporting

. Security and encryption

The hardware to be used should be listed as well, to ensure that it is available when

needed. Ideally, the exact hardware to be used in the upgrade will be ordered for the appli-

cation testing process, but if that is not possible, hardware with specifications similar to

that of the servers that will eventually be used should be allocated. Although processor

speed and amount of RAM will most likely not make a difference to whether the applica-

tion functions properly on the server platform, certain hardware devices should be as

Preparing for Compatibility Testing

529

similar as possible. Tape drives, for example, should have the same features as the ones to

be used in the production environment because this is one of the most critical compo-

nents. If an autoloader will be used in the production environment, one should be made

available for the application testing process. If faxing from the Outlook Inbox is required,

the same faxing hardware should be allocated as well. Another example is implementing

clustering with a storage area network (SAN) back end. If a SAN will be utilized in produc-

tion and the test criteria of the lab is to validate clustering functionality, the same produc-

tion SAN should be utilized in the test environment. By using the same SAN solution,

clustering test criteria and clustering functionality can be validated and guaranteed.

Some applications require clients to be present for the testing process, so at least one

workstation class system should be available for this purpose. Connectivity to the Internet

might also be necessary for testing the functionality of remote access products and

antivirus software.

Table 17.1 shows a sample checklist of requirements for summarizing the scope of the

application testing phase.

TABLE 17.1

Checklist for Application Testing

Server #1 Details (Include Version Numbers)

ptg

Server specs required:

Processor

RAM

Hard drive configuration

17

Other

Network OS and service packs:

Tape backup software version and agents:

Additional third-party apps required:

Virtualization? Yes/No

Additional hardware required:

SAN device

Tape drive

UPS

Switch/hub

Other

Internet access required? Yes/No

This process should not take a great deal of time if previous planning has taken place. If

the planning phase was skipped, some brainstorming will be required to ensure that the

530

CHAPTER 17

Compatibility Testing

scope includes all the key ingredients required for the application testing. The goals for

the application testing process will also affect the scope, which is covered in the follow-

ing section.

Defining the Goals for Compatibility Testing

As with the previous step of defining the scope of the testing process, defining the goals

might be a very quick process, or could require some discussions with the stakeholders

involved in the project.

One useful way of looking at the goals for the project is to treat them as the checklist for

successful completion of the testing. What conditions need to be met for the organization

to confidently move forward with the next step in the Windows migration? The next step

might be a more complete prototype testing phase. For smaller organizations, it might be

a pilot rollout, where the new networking environment is offered to a select group of

savvy users.

These goals are separate from the business goals the company might have, such as a more

reliable network infrastructure or improved security. A more complete prototype phase

could seek to address these goals, while the application testing process stays focused on

the performance of the specific combinations of the operating system and embedded and

connected applications.

ptg

A convenient way to differentiate the goals of the project is to split them into key areas, as

described in the following sections.

Time Frame for the Testing

This goal can be defined with the statement: “The testing must be completed in X

days/weeks.”

If there is very little time available to perform the testing, this limits how much time can

be spent on each application and how many end users can put each through its paces. It

also necessitates a lesser degree of documentation. Remember to include time for research-

ing the applications’ compatibility with the vendors as part of the timeline. A quick

project plan might be useful in this process as a way of verifying the assumptions and

selling the timeline to the decision makers.

Contingency time should ideally be built in to this goal. Resources assigned to the testing

can get sick or might be pulled back into the office for production support, or applications

might require additional testing when problems are encountered. Vendors might not

provide trial versions of the software as quickly as desired, or new versions of software or

even the hardware itself can be delayed. With many companies seeking to consolidate the

number of servers in use, it is not uncommon to see labs evolve through the testing

process. Different versions of the Windows operating system are used, as are different

versions of various application software programs.

Preparing for Compatibility Testing

531

Estimating the Duration of the Application Testing Process

A good rule of thumb is to allow four hours per application to be tested for basic

testing, and eight hours for a more thorough testing process. This allows time for the

initial research with the vendors, configuration of the Windows Server 2008 R2 operat-

ing system, and testing of the applications. Of course, the total time required will vary

based on the types of applications to be tested.

For example, a Windows Server 2008 R2 system with a line-of-business application,

such as an enterprise resource planning (ERP) program with a front-end web applica-

tion, would take an estimated one or two days to test for basic compatibility and func-

tionality, and potentially a week for more rigorous testing.

Note that if more than one resource is available to perform the testing, these configu-

rations can be tested in parallel, shortening the duration of the process, but not the

work effort.

It’s always better to have some extra time during the testing phase. This time can be

used for more extensive user testing, training, or documentation.

Budget for the Testing

This goal can be defined with the statement: “The testing must be completed within a

ptg

budget of $X.”

Of course, there might be no budget allocated for testing, but it’s better to know this as

soon as possible. A lack of budget means that no new hardware can be ordered, evaluation

copies of the software (both Microsoft and the third-party applications) need to be used,

and no external resources will be brought in. If the budget is available or can be accessed

17

in advance of the production upgrade, a subset of the production hardware should be

ordered for this phase. Testing on the exact hardware that will be used in the actual

upgrade rather than a cast-off server will yield more valuable results.

More and more virtualization technology is being utilized in test labs for reducing costs

associated with hardware procurement. Virtualization is an excellent way to reduce capital

expenditures. Keep in mind that hardware-specific prototype testing cannot be achieved

when using virtualization as the guest operating system. In addition, performance metrics

might get skewed when running more than one guest operating system on a virtual server.

Resources to Be Used

This goal can be defined with the statement: “The testing will be completed by in-house

resources and/or external consultants.”

Often, the internal network administration staff is too busy with daily tasks or tackling

emergencies that spring up (which might be the reason for the upgrade in the first

place), and staff personnel should not be expected to dedicate 100% of their time to the

testing process.

532

CHAPTER 17

Compatibility Testing

If an outside consulting firm with expertise in Windows Server 2008 R2 is going to be

used in the testing process, it can be a good leverage point to have already created and

decided upon an internal budget for the testing process. This cuts down on the time it

takes to debate the approaches from competing firms.

Extent of the Testing

The extent of compatibility testing can be defined with the statement: “Each application

will be tested for basic, midlevel, or complete compatibility and feature sets.”

This goal might be set for different types of applications where some mission-critical appli-

cations would need to have extensive testing, whereas less-critical applications might have

more basic testing performed. A short time frame with a tightly limited budget won’t

allow for extensive testing, so basic compatibility will most likely be the goal.

Defining the Different Levels of Compatibility Testing

Basic compatibility testing, as used in this chapter, essentially means that the mission-

critical applications are tested to verify that they load without errors and perform their

primary functions properly with Windows Server 2008 R2. Often the goal with basic

testing is to simply see whether the application works, without spending a lot of time

or money on hardware and resources, and with a minimum amount of documentation

ptg

and training. Note that this level of testing reduces but does not eliminate the risks

involved in the production rollout.

Midlevel testing is defined as a process whereby Windows Server 2008 R2 is config-

ured with all the applications that will be present in the eventual implementation, so

that the test configuration matches the production configuration as closely as possible

to reduce the chance of surprise behavior during the rollout. This level of testing