Windows Server 2008 R2 Unleashed (110 page)

ment tools and agents are also essential.

ptg

Verifying Compatibility with Vendors

Armed with the full list of applications that need to be tested for compatibility, the appli-

cation testing team can now start hitting the phones and delving into the vendors’

websites for the compatibility information.

17

For early adopters of certain application software programs, more research might be neces-

sary because vendors tend to lag behind in publishing statements of compatibility with

new products. Past experience has shown that simply using the search feature on the

vendor’s site can be a frustrating process, so having an actual contact who has a vested

interest in providing the latest and greatest information (such as the company’s sales

representative) can be a great time-saver.

Each vendor tends to use its own terminology when discussing Windows Server 2008 R2

compatibility (especially when it isn’t 100% tested); a functional way to define the level of

compatibility is with the following four areas:

. Compatible

. Compatible with patches or updates

. Not compatible (requires version upgrade)

. Not compatible and no compatible version available (requires new product)

When possible, it is also a good practice to gather information about the specifics of the

testing environment, such as the version and SP level of the Windows operating system

the application was tested with, along with the hardware devices (if applicable, such as

tape drives, specific PDAs and mobile devices, and so forth) tested.

538

CHAPTER 17

Compatibility Testing

Tracking Sheets for Application Compatibility Research

For organizational purposes, a tracking sheet should be created for each application to

record the information discovered from the vendors. A sample product inventory sheet

includes the following categories:

. Vendor name

. Product name and version number

. Vendor contact name and contact information

. Level of criticality: Critical, near-critical, or nice to have

. Compatible with Windows Server 2008 R2: Yes/no/did not say

. Vendor-stated requirements to upgrade or make application compatible

. Recommended action: None, patch/fix/update, version upgrade, replace with new

product, stop using product, continue using product without vendor support

. Operating system compatibility: Windows Server 2008 R2, Windows Server 2008,

Windows Server 2003 R2, Windows Server 2003, Windows 2000 Server, Windows NT

Server, other

ptg

. Processor architecture compatibility: 64-bit compatible?

. Notes: Conversation notes, URLs used, copies of printed compatibility statements, or

hard copy provided by vendor

It is a matter of judgment as to the extent of the notes from discussions with the vendors

and materials printed from websites that are retained and included with the inventory

sheet and kept on file. Remember that URLs change frequently, so it makes sense to print

the information when it is located.

In cases where product upgrades are required, information can be recorded on the part

numbers, cost, and other pertinent information.

Six States of Compatibility

There are essentially six possible states of compatibility that can be defined, based on the

input from the vendors, and that need to be verified during the testing process. These

levels of compatibility roughly equate to levels of risk of unanticipated behavior and

issues during the upgrade process:

1. The application version currently in use is compatible with Windows Server 2008 R2.

2. The application version currently in use is compatible with Windows Server 2008

R2, with a minor update or service patch.

3. The application currently in use is compatible with Windows Server 2008 R2, with a

version upgrade of the application.

4. The application currently in use is not compatible with Windows Server 2008 R2

and no upgrade is available, but it will be kept running as is on an older version of

Verifying Compatibility with Vendors

539

Windows Server (or other network operating system) in the upgraded Windows

Server 2008 R2 networking environment.

5. The application currently in use is not compatible with Windows Server 2008 R2,

and will be phased out and not used after the upgrade is complete.

6. The application currently in use is not compatible with Windows Server 2008 R2

per the vendor, or no information on compatibility was available, but it apparently

runs on Windows Server 2008 R2 so the organization needs to determine if it will

run the application on an operating system potentially not supported by the appli-

cation vendor.

Each of these states is discussed in more detail in the following sections.

Using a Windows Server 2008 R2–Compatible Application

Although most applications require some sort of upgrade, the vendor might simply state

that the version currently in use will work properly with Windows Server 2008 R2 and

provide supporting documentation or specify a URL with more information on the topic.

This is more likely to be the case with applications that don’t integrate with the Windows

Server components, but instead interface with certain components, and might even be

installed on separate servers.

It is up to the organization to determine whether testing is necessary to verify the

ptg

vendor’s compatibility statement. If the application in question is critical to the integrity

or security of the Windows Server 2008 R2 operating system, or provides the users with

features and capabilities that enhance their business activities and transactions, testing is

definitely recommended. For upgrades that have short time frames and limited budgets

available for testing (basic testing as defined earlier in the chapter), these applications

17

might be demoted to the bottom of the list of priorities and would be tested only after the

applications requiring updates or upgrades had been tested.

A clear benefit of the applications that the vendor verifies as being Windows Server 2008

R2–compatible is that the administrative staff will already know how to install and

support the product and how it interfaces with Windows Server 2008 R2 and the help

desk; end users won’t need to be trained or endure the learning curves required by new

versions of the products.

NOTE

As mentioned previously, make sure to clarify what NOS and which specific version of

Windows operating system was used in the testing process, including the processor

architecture version, because seemingly insignificant changes, such as security

patches to the OS, can influence the product’s performance in your upgraded environ-

ment. Tape backup software is notorious for being very sensitive to minor changes in

the version of Windows, and tape backups can appear to be working when they aren’t.

If devices such as text pagers or mobile devices are involved in the process, the

specific operating systems tested and the details of the hardware models should be

verified if possible to make sure that the vendor testing included the models in use by

the organization.

540

CHAPTER 17

Compatibility Testing

If a number of applications are being installed on one Windows Server 2008 R2 sys-

tem, unpredictable conflicts are possible. Therefore, testing is still recommended for

mission-critical Windows Server 2008 R2 applications, even for applications the vendor

asserts are fully compatible with Windows Server 2008 R2.

Requiring a Minor Update or Service Patch for Compatibility

When upgrading from Windows Server 2008 or Windows Server 2003, many applications

simply need a relatively minor service update or patch for compatibility with Windows

Server 2008 R2. This is less likely to be the case when migrating from Windows NT 4.0 or

Windows 2000 Server or a completely different operating system, such as Novell NetWare

or Linux. This is also evident when running web applications because IIS 7.5 has evolved

and been completely rewritten.

During the testing process, the service updates and patches are typically quick and easy to

install, are available over the Internet, and are often free of charge. It is important to read

any notes or readme files that come with the update because specific settings in the

Windows Server 2008 R2 configuration might need to be modified for them to work. These

updates and patches tend to change and be updated themselves after they are released, so

it is worth checking periodically to see whether new revisions have become available.

ptg

These types of updates generally do not affect the core features or functionality of the

products in most cases, although some new features might be introduced; so they have

little training and support ramifications because the help desk and support staff will

already be experienced in supporting the products.

Applications That Require a Version Upgrade for Compatibility

In other cases, especially when migrating from Windows NT 4.0 or another network oper-

ating system, a complete migration strategy is required, and this tends to be a more

complex process than downloading a patch or installing a minor update to the product.

The process will vary by product, with some allowing an in-place upgrade, where the soft-

ware is not on the Windows Server 2008 R2 server itself, and others simply installing

from scratch.

The amount of time required to install and test these upgrades is greater and the learning

curve steeper, and the danger of technical complexities and issues increases. Thus, addi-

tional time should be allowed for testing the installation process of the new products,

configuring them for optimal Windows connectivity, and fine-tuning for performance

factors. Training for the IT resources and help desk staff will be important because of the

probability of significant differences between the new and old versions.

Compatibility with all hardware devices should not be taken for granted, whether it’s the

server itself, tape backup devices, or SAN hardware.

If a new version of the product is required, it can be difficult to avoid paying for the

upgrade, so budget can become a factor. Some vendors can be persuaded to provide evalu-

ation copies that expire after 30–120 days.

Verifying Compatibility with Vendors

541

Handling an Incompatible Application That Will Remain “As Is”

As discussed earlier in this chapter, Windows Server 2008 R2 can coexist with previous

versions of the Windows operating system, so a Windows Server 2008 R2 migration does

not require that every server be upgraded. In larger organizations, for example, smaller

offices might choose to remain on legacy versions for a period of time, if there are legiti-

mate business reasons or cost concerns with upgrading expensive applications. If custom

scripts or applications have been written that integrate and add functionality to Windows

NT 4.0, Windows 2000, or Windows Server 2003, it might make more sense to simply

keep those servers intact on the network.

Although it might sound like an opportunity to skip any testing because the server config-

urations aren’t changing, connectivity to the new Windows Server 2008 R2 configurations

still needs to be tested, to ensure that the functionality between the servers is stable.

Again, in this scenario, the application itself is not upgraded, modified, or changed, so

there won’t be a requirement for administrative or end-user training.

Incompatible Applications That Won’t Be Used

An organization might decide that because an application is incompatible with Windows

Server 2008 R2, no upgrade is available, or the cost is prohibitive, so it will simply retire it.

Windows Server 2008 R2 includes a variety of new features, as discussed throughout the

ptg

book, which might make certain utilities and management tools unnecessary. For

example, a disaster recovery module for a tape backup product might no longer be neces-

sary after clustering is implemented.

Care should be taken during the testing process to note the differences that the adminis-

trative staff, help desk, and end users will notice in the day-to-day interactions with the

17

networking system. If features are disappearing, a survey to assess the impact can be very

helpful. Many users will raise a fuss if a feature suddenly goes away, even if it was rarely

used, whereas the complaints could be avoided if they had been informed in advance.

Officially Incompatible Applications That Seem to Work Fine

The final category applies to situations in which no information can be found about

compatibility. Some vendors choose to provide no information and take no stance on

compatibility with Windows Server 2008 R2. This puts the organization in a precarious

situation, as it has to rely on internal testing results to make a decision. Even if the appli-

cation seems to work properly, the decision might be made to phase out or retire the

product if its failure could harm the business process. If the application performs a valu-

able function, it is probably time to look for or create a replacement, or at least to allocate