Armed with the full list of
applications that need to be tested for compatibility, the application
testing team can now start hitting the phones and delving into the
vendors’ websites for the compatibility information.
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:
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 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
application 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
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.
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 environment. 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.
If
a number of applications are being installed on one Windows Server 2008
R2 system, 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.
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.