Migrating to Windows Server 2008 R2 : Verifying Compatibility with Vendors

For early adopters of certain application software programs, more research might be necessary 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.

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

• 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:

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 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 , these applications 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.

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.

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 operating 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 software 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, additional 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 evaluation copies that expire after 30–120 days.

Handling an Incompatible Application That Will Remain “As Is”

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 legitimate 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 configurations 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 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 necessary after clustering is implemented.

Care should be taken during the testing process to note the differences that the administrative staff, help desk, and end users will notice in the day-to-day interactions with the 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 application 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 valuable function, it is probably time to look for or create a replacement, or at least to allocate time for this process at a later time.

If the organization chooses to keep the application, it might be kept in place on an older version of Windows or moved to the new Windows Server 2008 R2 environment. In either case, the administrative staff, help desk, and end users should be warned that the application is not officially supported or officially compatible and might behave erratically.

Creating an Upgrade Decision Matrix

Although each application will have its own inventory sheet, it is helpful to put together a brief summary document outlining the final results of the vendor research process and the ramifications to the network upgrade project. As with all documents that affect the scope and end state of the network infrastructure, this document should be reviewed and approved by the project stakeholders.

This document can be expanded to summarize which applications will be installed on which network server if there are going to be multiple Windows Server 2008 R2 servers in the final configuration. In this way, the document can serve as a checklist to follow during the actual testing process.

Assessing the Effects of the Compatibility Results on the Compatibility Testing Plan

After all the data has been collected on the compatibility, lack of compatibility, or lack of information, the compatibility testing plan should be revisited to see whether changes need to be made. The components of the compatibility testing plan are the scope of the application testing process and the goals of the process (timeline, budget, extent of the testing, training requirements, documentation requirements, and fate of the testing lab).

Some of the goals might now be more difficult to meet, and require additional budget, time, and resources. If essential network applications need to be replaced with version upgrades or a solution from a different vendor, additional time for testing and training might also be required. Certain key end users might also need to roll up their sleeves and perform hands-on testing to make sure that the new products perform to their expectations.

This might be the point in the application testing process at which a decision is made that a more complete prototype testing phase is needed, and the lab would be expanded to more closely, or exactly, resemble the end state of the migration.