- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Deploying Windows XP, Application Migration
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. The complexity of user state migration pales in comparison to application migration. We look at some of the more common challenges and solutions sys admins face when moving applications written for legacy Microsoft operating systems to XP.
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).
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).