Dealing with incompatible applications is perhaps one of the most challenging parts of a server OS upgrade. Considering...
the volume of differences that exist between Windows Server 2003 and Windows Server 2008 and R2, organizations considering making the move are sure to find one or two bad apps that just won’t run.
A long time ago, the incompatibility of these applications could be a major sticking point, possibly preventing an upgrade altogether. Not so any more. With a bit of effort and the tools you’ll find in Microsoft’s Application Compatibility Toolkit (ACT), you should be able to whip many (if not all) of your bad apps back into shape.
The ACT is a toolkit primarily designed for verifying application compatibility atop Windows 7. Although its services aren’t directly supported for applications on Windows servers, its assistance can help you with those few Very Bad Apps you’ve got running in the datacenter.
The approach you’ll use is sometimes referred to as shimming. The shimming process inserts one or more fixes into the execution space used by an incompatible application. Each fix is a piece of code that alters that execution space in some way, with the goal of allowing the application to run. Some shims purposely deliver false OS information when an application makes a request. Others reroute file, folder, or registry calls away from Windows Server 2003-style folder paths and towards those used by Windows Server 2008 and R2. Built into the ACT are over 360 compatibility fixes in all, each of which is designed to overcome some hurdle that prevents an incompatible application from running.
If you’re lucky, the ACT also arrives with a database of over 6,500 known applications, along with their accompanying fixes. While 6,500 might seem like a lot, this list is notably short and likely doesn’t include the applications you need fixing. These known applications are primarily intended for Windows 7, although in rare situations you’ll find one you’re using on your servers. Most often this is the case because your bad apps are often home-grown bad apps. While the ACT’s application database might not directly assist these applications, it does provide some handy guidance for your efforts.
Making use of the ACT first requires downloading it from Microsoft’s website and installing it, typically to an available server that you’ve dedicated for IT use. Installing the ACT requires a database, which can be an available SQL instance or it can install a local database atop SQL Server Express.
The ACT exposes many tools for inventorying and dealing with incompatible applications. The tool you’ll use as your workbench for assigning fixes to applications is the ACT’s Compatibility Administrator. Two versions of this tool are available, one each for 32-bit and 64-bit applications. Inside either, you can click the Applications node exposed in the tool’s left pane to expand and view the ACT’s list of known and fixed applications. Selecting an application in the left pane brings up the characteristics used to identify the application as well as the associated fixes in the tool’s right pane.
As mentioned earlier, it is almost assured that some (if not all) of your applications will not be in this list of already-fixed applications. Thus, the task of figuring out which fixes your bad app requires becomes your next effort. This process is admittedly tedious, requiring some sleuthing and no small amount of guess-and-check before you’ll finally get things right.
The tools you’ll need to fix applications are in many ways similar to the tools you would use in packaging applications for automated installation. One important tool is a reference computer, one that runs a bare-bones installation of Windows Server 2008 R2 and can operate as a clean environment for the testing of applications. The use of virtual machines and snapshotting can be very handy for this exercise.
On that reference computer, install the ACT’s Compatibility Administrator as well as your bad app. Then, launch the application and take careful notes about exactly how and why the application is failing. Any error messages the application presents as you attempt to use its functions are also helpful. Making sure to not only launch an application but also interact with it while running is important. This is the case because an incompatible application may launch correctly, only to discover later that some functions don’t work.
Your next task will be to translate the behaviors you’ve logged into potential fixes to apply. This handy list of the ACT’s fixes includes descriptions of the behavior each fix attempts to shim into functionality. You’ll note that with over 360 to test, narrowing down this process to just those that work will involve effort.
Once you’ve got an idea of the fixes you want to try, your next step will be shimming them into the application. To test a fix, click to create a Custom Database in the reference computer’s Compatibility Administrator. Right-click the created database and create a new Application Fix. This will launch the Create new Application Fix wizard.
In that wizard, provide information about the application including its program file location. Then, assign the fixes you’ve identified. This wizard provides a way to tag each bad app with potential fixes until you’ve found the set that works. Built into the wizard is a button titled Test Run… that is used to test an execution of the application with fixes applied. Your goal in using this button is to identify whether the set of fixes you’ve selected actually resolve the incompatibility.
While many applications will require some guess-and-check across the range of fixes, one easy way to start is by setting the application’s Compatibility Mode to Windows XP (which is the equivalent of Windows Server 2003). Doing so configures a range of settings which reconfigure the application’s execution space to behave as if the application were running in Windows XP or Windows Server 2003. These settings are a good start, but if they don’t automatically fix the problem you’ll need to keep sleuthing.
Once you’ve identified the fixes that work, save the database you just created – it will have an .SDB extension – to a location on the computer. Then, right-click the database and select Install to install it to the local computer. Re-launch the application to verify it continues to function correctly. If it doesn’t, you can right-click the database again and select Uninstall to remove the fixes before starting over again.
The last step in this process will be to deploy your fix database to the Windows Server 2008 R2 computers running the problematic application. This deployment can happen via a range of distribution mechanisms, such as including it in a deployed image, distributing it via a software deployment solution, or installing it via a logon script. In any of these situations, use the native command sdbinst.exe to install the database to each user’s desktop or server.
A Windows Server 2008 R2 computer can manage any number of application fix databases, although different use cases will drive the approach you use in provisioning databases in your organization. Microsoft has published some well-written guidance on the alternative methods available.
Even with all the substantial changes between old OS and new, most applications today run perfectly well atop Windows Server 2008 R2. That said, almost every IT shop will find a critical few that stand out as Very Bad Apps. While fixing them with Microsoft’s ACT is indeed a tedious process, this well-written tool gives you the technical assistance you need to eliminate bad applications as your hurdle to a Windows Server 2008 R2 migration.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
About the author:
Greg Shields is a Partner and Principal Technologist with Concentrated Technology, an IT analysis and strategic consulting firm. Contact him at http://www.ConcentratedTech.com.