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 information 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 environment, you
should create separate lists that note whether a server is a domain
controller 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
typically 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 is whether the server is
physical or virtual. Table 1 shows a sample
system device inventory sheet.
Table
1. System Device Inventory Table
| Server Name | Member of Domain (Y/N) | Domain Controller (Y/N) | Virtual Server (Y/N) | General Functions | Operating System |
|---|
| SERVER-A | Y | Y | Y | DC, DNS, DHCP | Windows 2003 R2 |
| SERVER-B | Y | N | N | Exchange Server | Windows 2000 SP3 |
| SERVER-C | Y | N | Y | File/Print Server | Windows NT 4.0 |
| SERVER-D | N | N | N | WWW Web Server | Windows 2003 SP1 |
Taking Inventory of
Applications on Existing Servers
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
services such as data backup and antivirus software. However, in most
organizations, additional 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
simply 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 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 incompatibilities 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
information 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
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 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-protection software. In organizations that perform network and
systems management, management tools and agents are also essential.
