Old applications can present problems when you try to run them on newer operating systems such as Windows XP. Here's how Microsoft's Windows Application Compatibility Toolkit can help solve the problem.
As Microsoft releases new operating systems, it tries very hard to ensure backward compatibility with older applications. However, sometimes old applications just don’t work. To help address the problem, Microsoft created the Windows Application Compatibility Toolkit.
Acquiring the Application Compatibility Toolkit
The Application Compatibility Toolkit (ACT) is available as a free download from Microsoft. You can download it from Microsoft's Web site. The file that you'll download is a 23.3-MB self-extracting executable file named ACT30PKG.EXE. Simply create a new folder and download this file into it.
Installing the ACT
To install the ACT, double-click on the ACT30PKG.EXE file that you downloaded. When you do, Windows will take a moment to extract the necessary files, and then launch the Setup wizard. Click Next to bypass the wizard’s welcome screen.
You'll see the end user license agreement. Accept the license agreement, click Next, and you'll be asked to confirm your name and organization. After doing so, click Next, verify the installation path, and click Next again. At this point, you'll be asked to choose which components you wish to install. Select all of the components and click Next, followed by Install to begin the installation process. The wizard will now copy all of the necessary files to your computer. When the file copy process completes, click Finish.
When the installation process completes, ACT will be available through the machine’s All Programs menu as Microsoft Windows Application Compatibility Toolkit. There are three primary components to ACT: Windows Application Verifier 2.50, Compatibility Administration Tool 3.0, and Microsoft Application Compatibility Analyzer 1.0. I'll discuss each of these tools in detail in the following sections.
Microsoft Application Compatibility Analyzer 1.0
In most cases, the Application Compatibility Analyzer is the first component of ACT that you'll want to run. Its main purpose is to spot potential compatibility problems. In a real-world scenario, you'd want to run the Application Compatibility Analyzer on each machine that you plan to upgrade to a new operating system. The exact method that you would use really just depends on your situation.
For example, if you had a server that you plan to install Windows Server 2003 onto, you'd probably just copy the Application Compatibility Analyzer to the machine and run it locally. On the other hand, if you have 1,000 workstations that all need to be upgraded to Windows XP, then it would be way too time-consuming to run the utility individually on each machine. A better solution would be to copy the Application Compatibility Analyzer to a network share and then run it from a login script. You could then have each machine create its own application compatibility report, and you could merge the results together into one large database.
Before I show you how to do this, you need to understand that there are two main components to the Application Compatibility Analyzer: the collector and the analyzer. The collector (collector.exe) is the utility that actually runs on the machine being tested and gathers compatibility information related to that machine. The analyzer component (analyzer.exe) has two purposes. First, it allows you to merge all of the collected data into a single database. The analyzer’s other purpose is to act as a front-end database analysis tool for the collected data.
As I stated earlier, ACT is designed to help you with migrations to Windows 2000, XP, and 2003. This doesn’t mean, however, that these are the only supported operating systems. The collector component will run on Windows 95, 98, Me, NT 4.0, 2000, XP, and 2003.
In order to effectively run the collector against numerous machines, you'll need to take advantage of the various command line switches. Normally, if you're scanning machines through login scripts, you would call the collector.exe file from the login script and specify the appropriate command line switches. The collector.exe file is located at \Program Files\Microsoft Windows Application Compatibility Toolkit\Applications\Microsoft Application Compatibility Analyzer\Collector. The command line switches are as follows:
- /F “path”: The path for gathering data. If no path is specified, data will be gathered from all local hard drives.
- /I: Gather data from the entire directory (used only with the /F switch).
- /S: Use the file system APIs rather than the shell APIs (used only with the /F switch).
- /N: Collect information from mapped network drives (used only with the /F switch).
- /A: Combine collected information from installed programs and from drives / paths (used only with the /F switch).
- /O: Saves the log file to a designated location. By default the log file is saved as a CAB file and placed on the user’s desktop.
- /X: Do not compress the output file. By default, the collected data is saved as a CAB file.
- /D [days]: Collects data only if the collector has not run in a specified number of days.
- /E[name]: This switch allows you to add the name of the user’s department to the database. Although this switch is by no means required, it can be helpful when sorting data.
- /P[file name]: Allows you to specify a collector profile file to use.
- /Y: This switch is called privacy mode. It will not include information such as a computer name, user name, or IP address in reports.
- /K: This switch causes the collector to scan applications, but to not collect privacy information.
- /CE: Do not enumerate installed programs or services.
- /CN: Do not detect the computer’s role as a server.
- /CS: Do not include additional system information.
- /CG: Include global entries in an .SDB file.
- /CW: Do not start collecting data until five minutes have passed.
Now that you're familiar with the various switches, let’s look at the best way to launch collection data from within a login script. The actual command that you'd use would vary depending on what you wanted to accomplish. For the purposes of this example, though, I'll assume that you have a bunch of machines running Windows 98 that you're planning on upgrading to Windows XP, and that the contents of those machines' hard drives aren’t going to be changing any time soon.
Since there are a lot of machines to be scanned, the first problem that you must overcome is centrally collecting the data. This isn’t as tough as it sounds because the /O switch allows you to specify the output path. You don’t even have to worry about assigning a unique name to the data file because the collector automatically generates a unique file name based on the computer’s name and then on some sort of hash value.
One thing that you probably will want to do, though, is set the check so that it doesn’t run every single time the users log on. The test usually only takes a couple of minutes, but it can be rather annoying to have to sit through the check every single time you log in. Since I said that our fictitious organization does not expect the contents of the workstation’s hard drives to change often, you can use the /D switch to scan only once a month.
Based on these criteria, the command line that you'd use would look something like this:
Collector.exe /O ”Q:\Compatibility Data” /D 30
If you really want to get fancy, you can even design your login script to take advantage of exit codes. When the collector exits, it generates an exit code of either 0 or 1. The 0 exit code means that no errors were encountered; 1 means that the collector aborted as a result of some error. You could use these exit codes to integrate error trapping into your login script. The syntax would look something like this:If errorlevel 1 [command] [else command]
Now that I've shown you how to collect the compatibility data, the next trick is to merge it together and analyze the results. This is where the analyzer.exe tool comes in. You can find this tool in the Program Files\Microsoft Windows Application Compatibility Toolkit\Microsoft Application Compatibility Analyzer folder.
When you double-click on the analyzer.exe file, the analyzer will open within a Web interface. The initial screen gives you a choice of analyzing only the local computer or of analyzing collected data from across your organization. Click the Start Using The Analyzer link, and you'll see a screen asking you whether you want to create a new database or open an existing database. This screen is referring to the database that all of the collected data will be merged into. Since this database does not yet exist, click the Create New Database link.
The Create New Database screen gives you the choice of creating a Microsoft Access database or of creating a SQL database. Either type of database will work, but SQL databases offer higher performance, especially in large organizations with a lot of computers to analyze. Even so, the Microsoft Access option offers a nice, easy, idiot-proof way of creating a database if you don’t have a SQL Server or aren’t familiar with the tasks necessary for setting up a SQL database. For demonstration purposes, select the Microsoft Access Database option with the default database name and path, and click Continue.
The next screen that you'll see, shown in Figure A, needs a little explaining. The screen is asking for the location of the collector log files. By default, collector logs are placed on each machine’s desktop.
|You must specify the path to the collector log files.|
In the figure, notice that the folder paths option is set to the local desktop. This is fine if you're analyzing a single machine, but it won’t work for analyzing an entire organization. As you may recall, in my discussion of setting up the collector in the logon script, I pointed the collector to an output path of Q:\Compatibility Data. This is the path that will contain all of the log files. You must therefore click the Add button and point the analyzer to this location. You'll also want to remove any other entries that might already exist, such as the path to the local desktop.
Click Continue, and you'll be asked whether you want to connect to the online compatibility database at Microsoft now, or if you'd prefer to manually connect later. Assuming that you have a persistent Internet connection, I recommend connecting now.
The next screen will display the number of log files that are to be processed and the total amount of data that is to be merged into the database. There’s really nothing to do on this screen aside from clicking Start, but it's worth taking a quick glance at the screen to see how many files will be processed. After all, if you have collected data from a thousand workstations and the Application Compatibility Analyzer is showing that there is only one file to be processed, then you've done something wrong and need to fix the problem before continuing.
When the merge process completes, you'll be presented with a screen similar to the one shown in Figure B. As you can see in the figure, this screen provides you with a listing of all of the applications that were detected in your organization. You can also tell how many machines each application is running on (this is great for software license compliance by the way).
The database also allows you to drill down further into the data. If you click on the number of machines that are running a specific application, the utility will present you with a list of the machines running the application. Click on an individual machine, and you'll see a machine summary, as shown in Figure C.
|The Application Compatibility Analyzer can provide you with a machine summary.|
Windows Application Verifier 2.50
The second component in the Application Compatibility Toolkit is the Application Verifier. I’m not going to go into a whole lot of detail on this tool because it's intended primarily for developers rather than administrators. The basic idea behind this tool is that it monitors the way an application interacts with the Windows operating system. As it does, it looks at the application’s use of the registry, the file system, kernel objects, and other Windows components. It then uses this information to provide developers with information on potential compatibility and/or security problems with the application.
Compatibility Administrator Tool 3.0
The last component in the ACT is the Compatibility Administrator. This utility allows you to enable or disable various compatibility fixes as well as browse for fixed applications.
One of my favorite things about this utility is that it contains a database of applications that simply don’t want to run correctly under newer versions of Windows. When you select an application, you can see the various fixes that need to be applied in order to make the application run, as shown in Figure D.
|The Compatibility Administrator contains a list of patched applications.|
You can also test-run applications to see if proposed fixes will work. To do so, select the database that you're working with and click the Fix button found on the toolbar. This will open the Create New Application Fix dialog box. Now, fill in the dialog box with the name and path to the application and click Next. You're now prompted to select a compatibility mode to apply to the application. You can use the Test Run button to try different compatibility options until you find one that works. After finding a working compatibility fix, click Next, followed by the Finish button to add the fix to the database of fixed applications.