If you would like to read the other parts in this article series please go to:
- Windows 7 Compatibility Testing (Part 1)
- Windows 7 Compatibility Testing (Part 3)
- Windows 7 Compatibility Testing (Part 4)
- Windows 7 Compatibility Testing (Part 5)
- Windows 7 Compatibility Testing (Part 6)
- Windows 7 Compatibility Testing (Part 7)
- Windows 7 Compatibility Testing (Part 8)
In my first article in this series, I demonstrated a tool called the Windows 7 Upgrade Advisor. As I pointed out though, the Windows 7 Upgrade Advisor is a light weight tool that is designed for quick and dirty compatibility testing on a single PC. Although this tool can be helpful for getting an idea of what you can expect during an upgrade, it is far from being an enterprise class utility. In this article, I want to turn my attention to application compatibility testing for larger organizations.
Collect an Application Inventory
Although it may seem like an obvious step, the first step in enterprise application compatibility testing is to compile an inventory of the applications that are installed on your network. Only then can you begin to determine which, if any applications might cause problems with your upgrade to Windows 7.
My experience has shown that most larger organizations already have a comprehensive inventory of desktop applications. After all, just about everyone uses desktop management software these days, and almost all of the desktop management applications on the market include a built in tool for compiling software inventory information.
Even if you already have an up to date software inventory, it is probably only going to be minimally useful in determining which applications are going to be compatible with Windows 7. The reason why this is the case is because Microsoft offers a set of utilities known as the Application Compatibility Toolkit. The Application Compatibility Toolkit can help you to determine which applications will work with Windows 7, but to do so, it needs to know what applications are on your network. The easiest way to provide the toolkit with the information that it needs is to let it take its own software inventory, even if you already have an up to date inventory of the applications on your network.
Acquiring the Application Compatibility Toolkit
As mentioned in the previous section, Microsoft’s primary tool for application compatibility testing is the Application Compatibility Toolkit. At the time that this article was written (January 2010), the current version of the toolkit was 5.5. It is available for download here.
There isn’t anything special that you have to do to deploy the Application Compatibility Toolkit. The deployment process consists of answering a few basic questions in a standard Setup wizard.
Preparing for the Inventory Collection
The Application Compatibility Toolkit is capable of compiling an inventory of the applications running on your network, but the process for doing so may be a little bit different from what you might be used to. Given the importance of the inventory collection process, I want to walk you through the process.
Creating a Data Collection Package
The first step in the inventory collection process is to create what is known as a Data Collection Package. The Data Collection Package is a package containing an inventory collector and one or more compatibility evaluators.
The compatibility evaluators are modules which are each designed to look for a specific type of compatibility problem. There are three different compatibility evaluators.
The User Account Control Compatibility Evaluator is designed to look for compatibility issues that may occur as a result of running an application as a standard user (as opposed to an administrator with free reign over the system) or as a protected administrator. This compatibility evaluator actually monitors the way that applications interact with the operating system as they run, and looks for potential problems that may occur when the application is run in a more restrictive environment.
The second compatibility evaluator is the Windows Compatibility Evaluator. This compatibility evaluator monitors applications as they run and looks for problems related to applications interacting with operating system components that have been deprecated in Windows 7.
Finally, the third compatibility evaluator is the Update Compatibility Evaluator. This compatibility evaluator is designed more for testing the impact of operating system updates than new operating system versions. Essentially, this compatibility evaluator analyzes update impact data, and helps you to spot issues that may occur when you deploy various Windows updates. This particular compatibility evaluator is beyond the scope of this article series, but I wanted to at least mention it so that you would know what this evaluator was when you see it.
Potential Compatibility Issues
Before I go on, I want to point out that the compatibility evaluators that I have just discussed have some of their own compatibility problems. According to Microsoft, the compatibility evaluators are not compatible with older versions of Windows. More importantly though, they cannot be used on any 64-bit operating system.
Setting Up the Application Compatibility Toolkit
Before you can begin creating a data collector package, you must configure the Application Compatibility Toolkit. To do so, open the Application Compatibility Manager. In case you are wondering, the Application Compatibility Manager is the utility that you will eventually use to create a data collector package.
When you open the Application Compatibility Toolkit for the first time, Windows will launch the Application Compatibility Toolkit Configuration Wizard. Click Next to clear the wizard’s welcome screen, and you will be taken to a screen that asks you if you want to perform an enterprise configuration, or if you only want to view and manage reports. Since our goal is to actually collect inventory and compatibility data, you must choose the Enterprise Configuration option.
Click Next, and you will be taken to a screen that asks you to supply the name of a SQL Server that can be used to store all of the compatibility data that you will be collecting. Enter the name of your SQL Server, and click the Connect button. Now, enter the name for the database that will store your compatibility data, as shown in Figure A, and click the Create button. When the wizard finishes creating the necessary database, click Next to continue.
Figure A: The Application Compatibility Toolkit is dependent upon a SQL Server database
At this point, you will see a screen asking for a location in which log files can be stored, as shown in Figure B. You can store your log files anywhere you want, but the location must be accessible through a UNC share. A further requirement is that every computer that you plan on testing must have write permissions to the log file directory. You will need to enable these permissions at both the share and the NTFS levels.
Figure B: Enter the UNC path to the location in which log files should be stored.
Click Next, and you will be prompted to enter a set of administrative credentials for the log processing service. In most cases you can get away with using the local system account, but whatever account you use, it must have access to the SQL database and to the log files. After entering your credentials, click Next followed by Finish to complete the configuration process.
In this article, I have introduced you to Microsoft’s Application Compatibility Toolkit, and I have talked about the importance of collecting a software inventory as the first step in the compatibility testing process. In Part 3, I will continue the discussion by showing you how to collect a software inventory.
If you would like to read the other parts in this article series please go to: