Windows Server 2008 R2 Unleashed (109 page)

requires more preparation to understand the configuration and more involvement from

testing resources, and should include end users. Some training should take place

during the process, and documentation is created to record the server configurations

and details of the testing process. Although this level of testing greatly reduces the

risks of problems during the production migration or upgrade, the migration process of

moving data between servers and training the resources on this process hasn’t been

covered, so some uncertainty still exists.

Complete testing adds additional resource training and possibly end-user training during

the process, and should include testing of the actual migration process. Complete

training requires more documentation to record the processes required to build or

image servers and perform the migration steps. Complete testing is what is typically

defined as a prototype phase.

Training Requirements During Testing

This goal can be defined with the statement: “Company IT resources will/will not receive

training during the application testing process.”

Although the IT resources performing the testing will learn a great deal by going through

the testing process, the organization might want to provide additional training to these

Preparing for Compatibility Testing

533

individuals, especially if new functionality and applications are being tested. If external

consultants are brought in, it is important that the organization’s own resources are still

involved in the testing process for training and validation purposes. The application

testing phase might be an excellent time to have help desk personnel or departmental

managers in the user community learn more about new features that will soon be offered

so they can help support the user community and generate excitement for the project.

Documentation Required

This goal can be defined with the statement: “Documentation will/will not be generated

to summarize the process and results.”

Again, the budget and timeline for the testing will affect the answer to this question.

Many organizations require a paper trail for all testing procedures, especially when the

Windows infrastructure will have an impact on the viability of the business itself. For

other organizations, the networking environment is not as critical, so less or no documen-

tation might be required.

The application testing phase is a great opportunity to document the steps required for

application installations or upgrades if time permits, and this level of instruction can

greatly facilitate the production rollout of the upgraded networking components.

ptg

Extent of User Community Involvement

This goal can be defined with the statement: “End users will be included/will not be

included in the testing process.”

If there are applications such as customer relationship management (CRM), document

routing, voicemail or paging add-ons, or connectivity to PDAs and mobile devices, a

17

higher level of user testing (at least from the power users and executives) should be

considered.

Fate of the Testing Lab

This goal can be defined with the statement: “The application testing lab will/will not

remain in place after the testing is complete.”

There are a number of reasons that organizations decide to keep labs in place after their

primary purpose has been served. Whenever a patch or upgrade to Windows Server 2008

R2 or to a third-party application integrates with Windows Server 2008 R2, it is advisable

to test it in a nonproduction environment. Even seemingly innocent patches to antivirus

products can crash a production server. Other items might require user testing to see

whether they should be rolled out to the production servers.

Documenting the Compatibility Testing Plan

The information discussed and gathered through the previous exercises needs to be gath-

ered and distributed to the stakeholders to ensure that the members of the team are

working toward the same goals. These components are the scope and the goals of the

application testing process, and should include the timeline, budget, extent of the testing

(basic, midlevel, complete), training requirements, documentation requirements, and fate

534

CHAPTER 17

Compatibility Testing

of the testing lab. This step is even more important if a formal discovery and design phase

was not completed.

By taking the time to document these constraints, the testing process will be more struc-

tured and less likely to miss a key step or get bogged down on one application. The indi-

viduals performing the testing will essentially have a checklist of the exact testing process,

and are less likely to spend an inordinate amount of time on one application, or “get

creative” and try products that are not within the scope of work. After the testing is

complete, the stakeholders will also have made it clear what is expected in terms of docu-

mentation so the results of the testing can be presented and reviewed efficiently.

This summary document should be presented to the stakeholders of the project for review

and approval. The organization will then be ready to proceed with the research and

testing process for Windows Server 2008 R2 compatibility.

Researching Products and Applications

The next step in the compatibility testing process is to actually begin research on the

products and applications being tested. With the documented goals and expectations of

the necessary compatibility testing process, the organization can proceed with informa-

ptg

tion gathering.

Taking Inventory of Network Systems

The first step of the information-gathering process is to take inventory of the network

systems that will be part of the Windows Server 2008 R2 environment. These systems

include domain controllers, application servers, gateway systems, and utility servers.

NOTE

When you’re identifying the systems that are part of the Windows Server 2008 R2 envi-

ronment, you should create separate lists that note whether a server is a domain con-

troller or member server of the environment, or whether the server is standalone and

does not directly interact with the domain. Usually, standalone servers that are not

integrated into the domain are significantly less likely to require a parallel upgrade to

Windows Server 2008 R2. Because the system is operating as a standalone, it will typ-

ically continue to operate in that manner and can be removed from the scope of testing

and migration during the initial migration phase. Removing this server can also greatly

minimize the scope of the project by limiting the number of servers that need to be

included in the testing and migration process.

For systems that are part of the network domain, the devices should be identified by

which network operating system they are running. Another item that should be captured

Researching Products and Applications

535

is whether the server is physical or virtual. Table 17.2 shows a sample system device inven-

tory sheet.

TABLE 17.2

System Device Inventory Table

Server Name

Member of

Domain

Virtual Server

General

Operating

Domain (Y/N)

Controller (Y/N)

(Y/N)

Functions

System

SERVER-A

Y

Y

Y

DC, DNS,

Windows

DHCP

2003 R2

SERVER-B

Y

N

N

Exchange

Windows

Server

2000 SP3

SERVER-C

Y

N

Y

File/Print

Windows NT

Server

4.0

SERVER-D

N

N

N

WWW Web

Windows

Server

2003 SP1

Taking Inventory of Applications on Existing Servers

ptg

Now that you have a list of the server systems on your network, the next step is to take

inventory of the applications running on the systems. Care should be taken to identify all

applications running on a system, including tape software, antivirus software, and

network monitoring and management utilities.

The primary applications that need to be upgraded will be obvious, as well as the standard

17

services such as data backup and antivirus software. However, in most organizations, addi-

tional applications hiding on the network need to be identified. If System Center

Configuration Manager 2007 (ConfigMgr) is in use, or another network management tool

with inventory capabilities, it should also be able to provide this basic information.

NOTE

Another angle to validating that all applications are tested before a migration is to sim-

ply ask all departmental managers to provide a list of applications that are essential

for them and their employees. This takes the opposite angle of looking not at the

servers and the applications, but looking at what the managers or employees in the

organization say they use as part of their job responsibilities. From these lists, you can

put together a master list.

Understanding the Differences Between Applications and Windows

Services

We need to make a distinction as it pertains to the Windows Server 2008 R2 operating

environment. Applications are programs that run on top of Windows Server 2008 R2, such

as application tools or front-end services, and services are programs that integrate with the

536

CHAPTER 17

Compatibility Testing

operating system, such as SQL, Exchange, antivirus applications, and so on. As discussed

previously, in the .NET Framework, applications are designed to sit on top of the Windows

platform, so the more embedded the legacy application is in the NOS, the greater the

potential for problems.

It is also helpful to separate the Microsoft and non-Microsoft applications and services.

The Microsoft applications that are to be upgraded to the new Windows Server 2008 R2

environment are likely to have been thoroughly tested by Microsoft. Possible incompati-

bilities should have been identified, and a great deal of information will be available on

Microsoft TechNet or on the Microsoft product page of its website. On the other hand, for

non-Microsoft applications and services, weeks could pass after a product’s release before

information regarding any compatibility problems with the Microsoft operating system

surfaces. This is also true for service packs and product updates where problems might be

made public weeks or months after the release of the update.

Furthermore, many organizations that create custom applications will find that little infor-

mation is available on Windows Server 2008 R2 compatibility, so they could require more

complex lab tests to validate compatibility.

Completing an Inventory Sheet per Application

ptg

An organization should create an inventory sheet for each application being validated.

Having an inventory sheet per application can result in dozens, if not hundreds, of sheets

of paper. However, each application needs to go through extensive verification for

compatibility, so the information gathered will be helpful.

A sample product inventory sheet includes the following categories:

. Vendor name

. Product name

. Version number

. Application or service?

. Mission-critical?

. Compatible with Windows Server 2008 R2 (Y/N)?

. Vendor-stated requirements to make compatible

. Decision to migrate (update, upgrade, replace, remain on existing OS, stop using,

proceed without vendor support)

Additional items that might be relevant could include which offices or departments use

the application, how many users need it, and so on.

Any notes from the vendor, such as whitepapers for migration, tip/trick migration steps,

upgrade utilities, and any other documentation should be printed, downloaded, and kept

on file. Although a vendor might state that a product is compatible on its website today,

you might find that by the time an upgrade occurs, the vendor has changed its statement

Verifying Compatibility with Vendors

537

on compatibility. Any backup information that led to the decision to proceed with the

migration might also be useful in the future.

Prioritizing the Applications on the List

After you complete and review the list, you will have specific information showing the

consensus of which applications are critical and which are not.

There is no need to treat all applications and utilities with equal importance because a

simple utility that does not work and is not identified as a critical application can be

easily upgraded or replaced later and should not hold up the migration. On the other

hand, problems with a mission-critical business application should be reviewed in detail

because they might affect the whole upgrade process.

Remember that certain utility applications should be considered critical to any network

environment. These include tape backup (with the appropriate agents) and virus-protec-

tion software. In organizations that perform network and systems management, manage-