Deploying Windows XP, Application Migration

Deploying Windows XP, Application Migration


March 3, 2005

The first two articles in this series discussed the caveats involved in migrating user state. While such migration tends to be time consuming and complex (due to a high degree of required customization and a significant volume of data and settings to be considered), it pales in comparison to challenges faced when migrating user applications. Although user state migration eliminates some of these challenges, a number of them will likely require separate consideration.

This article looks are the more common ones.

Applications refuse to work properly for a variety of reasons when installed on the Windows XP platform. Differences in registry structures, user profile location and settings, and some of the operating system components are common culprits. Applications written for legacy Microsoft operating systems might depend on file system or registry entries that no longer exist or have been moved. They might also rely on elevated privileges or increased permissions to function properly.

By default, standard user accounts on Windows XP have write access to only the HKEY_CURRENT_USER hive (with exception of Software\Policies and Software\Microsoft\Windows\CurrentVersion\Policies subkeys), the user's profile folder, Shared Documents folder, and any folders created in the root directory of local drive that have been created by that user. One way to determine whether a lack of permissions or privileges is causing a problem is to place the user who is testing the failing application in one of privileged Windows groups (such as local Administrators or Power Users). To pinpoint an exact cause, try using Filemon and Regmon from the Sysinternals Freeware Web site, which lists file system and registry locations that are being currently accessed as well as the status of each operation.

Once the location has been identified, you can manually modify permissions to accommodate application requirements or use pre-defined (such as COMPATWS.INF, stored in Windows\Security\Templates folder) or custom security templates in combination with the Security Configuration and Analysis tool (SECEDIT.EXE). Active Directory group policies are more appropriate for larger scale deployments, but they should be used with incremental templates only (such as SECUREWS.INF or HISECWS.INF). Applying default security templates (COMPATWS.INF or SETUP SECURITY.INF) this way is not recommended due to their significant impact on network bandwidth and CPU utilization.

Another cause of these problems is a check of the operating system version performed during an application installation. Ways to get around such limitations include using the Program Compatibility Wizard or Application Compatibility Toolkit (to designate the version of operating system that Windows XP will emulate). Similarly, issues resulting from a lack of support for long filenames can be resolved relatively easily.

In general, you should look for the "Designed for Windows" logo when checking application documentation to ensure no compatibility issues will surface.

However, other dependencies may force you to look for either updated versions of applications or their replacements providing equivalent functionality. Among those are reliance on direct hardware access or kernel-mode drivers, and bypassing the standard method of calling operating system APIs (which are common for disk defragmenting and partitioning software, antivirus programs, and backup and CD burning utilities).

Some applications might install older versions of files included with Windows XP. Frequently, such files are part of the earlier versions of Microsoft Data Access Components (MDAC) or DirectX (Windows XP SP1 supports MDAC version 2.7 and DirectX version 9.0). Although there is no real threat of having these files overwritten (since their safety is ensured by the Windows File Protection mechanism), they might not be suitable replacements due to backward compatibility issues. In such cases, implementing a DLL redirection mechanism may offer resolution.

Specific versions of DLL files needed by the application must be copied to the folder where the main executable resides. Prior to Windows XP SP1, you also had to create a redirection file. This was typically an empty file (its content was ignored), whose name was the same as the executable but was followed with the extension .local (e.g., the redirection file for MyApp.exe would be MyApp.exe.local). Starting with Windows XP SP1, the default behavior changed, forcing applications to first check their local directory in search for DLL files. Creating redirection files in such cases is no longer necessary.

Note, however, that some DLLs cannot be redirected — you can find a list of these at the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs registry location. To address this issue, software developers can create XML-based manifest files, which list the DLLs that their application needs. When such applications are launched on Windows XP or Windows 2003 systems, the manifest ensures that the explicitly specified version is used. Unfortunately, this solution is based on placing the manifest in the resource section of an executable, which requires recompiling it (and, therefore, necessitates access to the source code).

For more information on this subject, refer to the MSDN Web site. If your applications use Visual Basic 6.0 Active X controls, be sure to also review Microsoft Knowledge Base article 828629.

In general, you should look for the "Designed for Windows" logo when checking application documentation to ensure no compatibility issues will surface. Such labeling implies automatic stability when running on Windows XP Desktop, as well as the capability to install and remove all of its components cleanly and provide the same or better performance when compared with legacy Windows operating systems. The quick way to determine if the application you are reviewing fits in this category is to check whether it is listed on the Microsoft Windows Catalog Web site.

Microsoft incorporated some of the functionality that helps resolve application compatibility issues in Windows XP. This functionality is accessible via the graphical interface of the Program Compatibility Wizard and Compatibility Shell Extensions. The first one can be launched from the Start->All Programs->Accessories menu (or On-Line help), the other is implemented as a Compatibility tab on the Properties dialog box of executables and their shortcuts. The Wizard presents three options: 1) choose a program for which you want to adjust compatibility settings from a list created by scanning local drives for existing shortcuts, 2) select a program from its installation CD, or 3) locate the program manually. Once the program or its shortcut is identified, you are prompted for the operating system version that should be emulated by Windows during its execution (available choices include Windows 95, NT 4.0 SP5, 98/Me, and 2000).

Next, you are given the option to select recommended or supported display settings, such as the number of colors (256), screen resolution (640x480), and disabling of visual themes. At this point, you can also test the application to determine whether the selected settings resolve issues you experienced. After it's been confirmed, instruct the wizard to save its settings. This way, every time the executable is invoked, the same configuration is applied. The changes can be reviewed from the Compatibility tab on the Properties dialog box of the executable (or its shortcut — depending on which option you selected when running the Wizard). Note that instead of using the Wizard, it is possible to manipulate compatibility settings directly through this interface (which tends to be a bit faster).

>> Bigger and Better: The Three Main components of the Windows Application Compatibility Toolkit

The Program Compatibility Wizard and Shell Extensions facilitate remediation of minor compatibility issues; however, their functionality and applicability in an enterprise environment is rather limited. Fortunately, Microsoft provides another, more advanced and powerful, technology in the form of Windows Application Compatibility Toolkit (currently at version 3.0). The toolkit, which can be installed on Windows 2000 SP3 or later, Windows XP, and Windows 2003 Server, consists of documentation and tools to assist with designing, deploying, and supporting applications.

It is divided into three main components:

  1. Application Compatibility Analyzer is geared toward system administrators. It assists with inventorying applications and verifying their compatibility against an online database. The command-line Collector (COLLECTOR.EXE) handles the actual inventory part, and the GUI-based Analyzer (ANALYZER.EXE) takes care of the verification. COLLECTOR.EXE offers an extensive range of switches, which can be used to customize its behavior, allowing the targeting of specific files, directories, or drives (including network mapped ones), modifying logging options, and including or excluding machine specific information. For a complete list, refer to the "Planning and Testing for Application Deployment" document available as part of the Toolkit, or check the output of COLLECTOR.EXE /? command. Alternatively, it is possible to control the behavior of the Collector tool with INI files. Users can interactively invoke COLLECTOR.EXE. The least intrusive approach involves calling it from the login script, where it might be useful to apply the /d switch followed by an integer, indicating the minimum number of days that must pass between two consecutive runs of the tool. The Application Compatibility Analyzer can also be launched in unattended fashion using Systems Management Server or another software deployment method.

    Analyzer accepts Collector-generated logs as input. It stores them in a compressed format as .CAB files, processes them, and dumps the results in an Access or SQL Server database. When launching the tool, you must provide the location of the logs and designate a target database. To check compatibility status, Analyzer connects to the online database maintained by Microsoft. There is also an option to perform this step at a later stage. Information is merged with the database contents, and results are listed in the form of a table, with Application Name, Status (compatible, compatible with issues, incompatible, or unknown), Version, Company Name, and Machines columns.

  2. Application Verifier is geared toward software developers. It helps identify compatibility and stability issues via a graphical interface from which you specify which executable you intend to test. For each, select what is to be tested (e.g., detecting an invalid handle, registry, or filesystem use; calls made to obsolete APIs; and potential security issues) and click on the Run command button. The corresponding application is then loaded, and its behavior recorded in a log, which can be reviewed by clicking on the View Logs button. Errors and warnings are displayed with corresponding icons (to filter out non-relevant entries, select the "Show errors and warnings" option).

  3. Application Compatibility Admnistrator is geared toward system administrators. It uses legacy applications to resolve problem in a more flexible manner using built-in Windows XP features. It also makes it possible to deploy fixes to multiple computers. Like Application Verifier, Application Compatibility Admnistrator has a fairly intuitive graphical interface. Three top-level nodes in the left pane of the main window display the content of System Database, Installed Databases, and Custom Databases (initially empty). System Database lists a large number of applications that Microsoft has already fixed (you can locate them in the Application subnode) along with the compatibility fixes and modes (in the Compatibility Fixes and Compatibility Modes subnodes) available by default. The contents of the Installed and Custom Databases nodes reflect any custom changes that have or will be applied to the local system.

    Windows XP and Windows 2003 deal with compatibility issues by storing information about legacy applications and associated fixes in compatibility databases residing in the AppPatch subfolder of the Windows installation directory. This subfolder contains several already prepackaged databases, such as Apphelp.sdb (which links applications and associated help messages), Sysmain.sdb (which links applications and associated compatibility modes and fixes), Drvmain.sdb (which links drivers and associated help messages), and Msimain.sdb (which links Windows Installer .MSI files and associated help messages). In addition to these prepackaged databases, you can create custom ones (residing in the AppPatch\Custom subfolder).

    To create a custom database, launch the Application Compatibility Administrator. You should see a New Database listed under the Custom Databases subnode. Its context-sensitive menu (as well as the Database menu of the main menu) gives you the option of creating a new Application Fix, writing an Apphelp Message, or defining the Compatibility Mode.

    After selecting the first option, you will be prompted for the application name and the location of its executable, followed by the compatibility mode, compatibility fix, and matching information (used to identify the same program on other computers). The second option, after prompting for the application name, the location of its executable, and matching information, will ask you to specify the help text message, URL reference with more detailed description of the problem, and the help behavior (determining whether the application will be allowed to run after the message gets displayed). Note that you can also add a help message to an existing Application Fix. The third option enables you to define your own compatibility mode, which will encompass all compatibility fixes selected from the list included with the Administrator. This simplifies future configurations (since you can select a single custom compatibility mode instead of a number of corresponding compatibility fixes). After you've finished customizing, save the database to an arbitrary location. At this point, you are ready to install it and, potentially, deploy it to other computers.

    Installation can be performed directly from the Application Compatibility Administrator menu (using the Install option from the context sensitive or File menu) or with SDBINST.EXE executable, which is included as part of the Windows XP (and Windows 2003) operating system files. The first option comes in handy during testing, but its graphical interface and local scope of operations are limiting factors when considering larger deployments. SDBINST.EXE on the other hand, is much more versatile, since it functions as a comand-line utility and can be incorporated into various deployment scenarios. It takes one input parameter, specifying target database and a number of switches, which determine the mode of operation (installation or uninstallation, quiet or non-quiet).

If none of these methods resolve your application issues (especially when dealing with Windows 2000 applications not supported on the Windows XP platform), consider setting up a virtual instance of the operating system on a Windows XP desktop (such as a VMWare virtual server or Microsoft Virtual PC). Another possibility would be to use a thin-client solution, such as Microsoft Terminal Services or a Citrix Metaframe-based product.