Introduction

Article
03/05/2008

Application compatibility is a key factor in the long-term success of a deployment project. Whether the deployment project includes new applications with the new operating system or the organization is using existing applications, the ability of the users to log on after a deployment and continue their normal work is a critical goal.

This document describes strategies for identifying potential problems, creating a mitigation package, and then deploying that mitigation. To accomplish this goal, the Application Compatibility feature team must work with other teams to eliminate extra efforts in testing. It makes sense to share test lab facilities with the Application Management feature team to eliminate overlapping efforts in testing new applications. Sharing the application inventory with other teams can also be a timesaving strategy.

Background

Before moving from its current version of the Windows operating system to Windows XP or Windows Vista, the organization must test its applications to ensure that they are compatible with the new operating system. The organization may have up to several thousand applications installed organization-wide. Compatibility issues with one or many of these applications can prevent information workers from performing their role and affect core business functions.

Although most applications developed for earlier versions of Windows will probably perform well on the new versions, new technologies within the new versions may cause some applications to behave differently. Examples of applications that the Application Compatibility feature team must test to ensure compatibility include:

Core applications that are part of the standard desktop configurations, such as office productivity suites.
Line-of-business (LOB) applications, such as Enterprise Resource Planning (ERP) suites.
Administrative tools, such as antivirus, compression, backup, and remote-control applications.
Custom tools, such as logon scripts.

Low-level applications, such as antivirus applications, kernel-mode drivers, and filter drivers, are especially likely to pose problems. The organization must also ensure that its server applications are compatible with clients running Windows XP or Windows Vista.

Note This guide does not describe how to test applications that will run on the 64-bit versions of Windows XP, Windows Vista, or Microsoft Windows Server® 2003. The 64-bit versions of the operating systems do not support 16-bit applications, but users can run 32-bit applications on these versions by using the x86 emulator, known as WOW64 (Windows 32-bit on Windows 64-bit).

Prerequisites

This guide requires use of the ACT version 5.

Assumptions

Application Compatibility feature team members should be familiar with the concepts of how application compatibility fits into the overall Windows management and migration strategies. This guide assumes that development and test work will be performed in a non-production lab environment, although some testing (such as collecting application inventory and limited application compatibility evaluation) is best conducted in the production environment.

This guide assumes that Application Compatibility team members have:

An understanding of the navigation and hierarchy of the Windows registry.
An understanding of the files or file types that applications use.
The ability to extract application and setting information manually from internal development groups and software vendors besides Microsoft.

Education and References

Microsoft TechNet and the Microsoft Web site (https://www.microsoft.com) offer white papers and articles that can provide additional information and background on application compatibility. For more information about application compatibility in Windows Vista, see Windows Vista Application Compatibility at https://go.microsoft.com/fwlink/?LinkId=78122.

ACT is available for download from Application Compatibility Tools at https://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971&DisplayLang=en.

Lab Requirements

If one does not already exist, establish a dedicated and isolated lab environment for use in developing and testing the solution. The lab should mirror the production environment within reason. In some cases, it is better to open the test network to existing production services rather than replicating the production environment in detail—for example, permitting Dynamic Host Configuration Protocol (DHCP) packets to pass through routers into the test network.

Note Some operations can be safely conducted in the production environment, such as application inventory collection.

At a minimum, the lab should include:

Sufficient computers to provide services infrastructure:
- A Microsoft Active Directory® directory service domain (Windows Server 2003 or Microsoft Windows 2000 Server)
- Windows Server 2003 with Service Pack 1 (SP1—Windows Server 2003 R2 is preferred, because it provides a useful replication mechanism)
Microsoft Virtual Server 2005 (optional).
DHCP services.
Domain Name System (DNS) services.
Windows Internet Naming Service (WINS) services (optional).
Microsoft SMS 2003 with SP1 and the SMS Operating System Deployment (OSD) Feature Pack.
Microsoft SQL Server™ 2000 or Microsoft SQL Server 2005.
Lab test accounts with both normal user and administrative privileges.
Network hardware to provide connectivity.
Internet access (for downloading updates, files, and so on).
Test computers that accurately reflect production computers.
Software library representing all the applications to be tested.