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 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 2003 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 2003 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 2003. 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. A sample system device inventory sheet is shown in Table 18.2.

Table 18.2. System Device Inventory Table

Server Name	Member of Domain (Y/N)	Domain Controller (Y/N)	General Functions	Operating System
SERVER-A	Y	Y	DC, DNS, DHCP	Windows 2000 SP3
SERVER-B	Y	N	Exchange Server	Windows 2000 SP3
SERVER-C	Y	N	File/Print Server	Windows NT4
SERVER-D	N	N	WWW Web Server	Windows 2000 SP3

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 the Systems Management Server (SMS) is in use, or another network management tool with inventorying 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 2003 operating environment. Applications are programs that run on top of Windows Server 2003, 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 the like. 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 2003 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 Web site. 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 may 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 2003 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 may 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 2003 (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 Web site 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.