Skip to main content

Assess and mitigate compatibility issues with ACT

Applies to: Windows 7

One of the challenges around deployment of a new operating system has always been application compatibility. There are other concerns, but application compatibility can make any IT professional shudder with fear. So, the questions you might ask are: How do I deal with compatibility issues? Are there any tools that can help? Should I apply for a new job? If you continue reading this article, maybe it will help alleviate your concerns, since application compatibility is what we are going to talk about here.

What do I need to do?

Actually, it's kind of simple. Here's a quick list of suggested steps:

Install the Microsoft Application Compatibility Toolkit

Set up or use an existing server running the Windows Server operating system and install the ACT. The server needs to be online and available while the computers send back the inventory data. Sometimes I have used my own laptop, sometimes we use the server with Microsoft System Center Configuration Manager, and sometimes we use Windows Deployment Services in Windows Server or the Microsoft Deployment Toolkit (MDT).

The installation is very simple, just click Next until you have the option to click Finish. However, it's important to note that in addition to Windows Server, downloading and running the ACT also requires Microsoft SQL Server or Microsoft SQL Server 2008 Express Edition, as well as the Microsoft .NET Framework. After you install ACT, you will need to configure it.

Back to top

Configure Application Compatibility Manager in the ACT

  1. Through the Start menu, open Application Compatibility Manager. You will need to connect to a database, you need a File Share, and you need an account. After you click Next, select Enterprise Configuration, and then click Next again.

  2. ACT Configuration Wizard Screenshot

  3. This is the point at which you specify your database configuration. Select your database and click Create, and then click Next.

  4. ACT Database Configuration Screenshot

  5. Share the folder in which the returning data will be collected. You may need to modify permissions on the share, as well as the NTFS permissions, especially if computers that are not a part of the domain are going to be able to upload their files here.

  6. ACT Log File Configuration Screenshot

  7. At the next screen in the wizard, specify the account to use. I normally select the Local System account.

  8. ACT Log File Screenshot

  9. Click Finish, and you're done with the ACT configuration.

When you create a package, you can use "evaluators." These are really useful because they stay in the client and monitor application behavior, but right now we don't need that; we just want to know what's in the clients. You might ask yourself, why don't we just ask the customer? We always do ask, but I have yet to meet a customer with full insight into what's on the older clients. They might tell you something like, "Well, we are pretty basic. We only have Microsoft Office, some line-of-business applications, and that should be all..."

But, we still don't know for sure. If the customer gives me a number of applications, I typically multiply that number by 10, at least. Guessing is not the way. Knowing is much better, and this is why we use the ACT.

So, let's create the inventory package.

  1. Using the ACT, click Collect then double-click to create a package.

  2. ACT Inventory Package Screenshot

  3. Click Advanced to disable the evaluators we don't need. Ensure that Inventor Collector is selected.

  4. ACT Inventory Collector Screenshot

  5. Save the package and run it on the clients you would like to inventory for applications. Select File - Save and Create a Data Collection Package, and you are done here.

Back to top

Deploy the package

You can use more or less any method to deploy the package, such as script, Active Directory, System Center Configuration Manager, Microsoft System Center Essentials, or you can even run around to client computers.

Since you've created a standard MSI package, you can run it silently using msiexec /I inventorypackage.msi /qn. With some customers, on the same computer where the ACT is installed and we already have the ACTLog folder shared, I've simply created a new folder called ACTPackages and then used that share to deploy the inventorypackage.msi.

Back to top

Wait while information is gathered

Information gathering can take a while, but if you suspect there's a problem, open the ACTlog folder. If the folder is empty, the computer hasn't created the inventory yet. If the folder contains files, but no folders I would guess the log processor has stalled, so you'll need to start that service.

Back to top

Make a report of what you have

In Microsoft Application Compatibility Manager, switch to Analyze. Your screen should look something like this:

ACT Report Screenshot

If you would like a report of this analysis, just go to File in the menu bar, and select Export report. What's most important at this point is to get rid of every application you don't need to worry about. So, the first thing is to Set Priority on each and every one of the applications. You can set:

  • Priority 1 - Business Critical
  • Priority 2 - Important
  • Priority 3 - Nice to Have
  • Priority 4 - Unimportant

Now, we can create a filter and start working on the business-critical "stuff."

Let me give you some advice here: This is a perfect time to eliminate all the old "stuff." Ask customers if they really, really need each and every application. In many cases, older applications are now included in some other application as a feature. The fewer applications we have to work with, the better for everyone.

This is what your screen will look like when you have selected "Toggle Filter" and completed one "Send and Receive."

ACT Report Toggled Screenshot

As you can see, one of the applications has a "Vendor Assessment." That's nice because it means that the vendor says it works. The rest of the applications have "Community Assessment." You'll see that for some of the applications at least 25 people say "it works," for some applications no one has said it works, but at least no one has said the application does not work at all.

In this case, I would test only three applications, but before I do that I would check with the vendors and ask them. At a customer a while back we did an inventory of more than 5,000 applications, and after half day of discussions we were able to pinpoint which applications really were business-critical. After that, we did an assessment in the ACT, worked with filters, did a Send and Receive. Guess what? Once everything was done, we only needed to test approximately 110 applications of the initial 5,000.

Back to top

Test applications

The most important thing when testing applications is to be smart. You cannot possibly know everything about every application, so you need to test basic things. In the first round of testing, the only thing you need to do is to determine if the application works out-of-the-box, if it is unviable, or if it can be fixed. You also need a test pattern. Below is one simple test pattern you can use:

  • Can the application be installed?
  • Does it start?
  • Can I open things?
  • Can I save things?
  • Can I move things?
  • Can I print?

If you can take all of these actions without a problem, it's time to inform the customer that the application has tested correctly and that it can be piloted.

Back to top

Package applications

You need applications to be silently installed in some way. But, if the application was problematic running on Windows XP (for example, no installer, challenging to maintain), you might consider NOT deploying that application the same way. Perhaps, there is another way to solve the same problem. I have struggled with all kinds of applications, and I have to say that some of them should never have been used even though customers love them. But I know that we will need to redeploy this computer later on—whether on the same version of the Windows operating system or a newer iteration.

  • Deploy the application as Published Application in Remote Desktop Services (RDS). The problem still exists, but now it will be local from your perspective.
  • Deploy the application using Microsoft Application Virtualization (App-V). Yes, you heard me. App-V has a really nice packager, and it is virtualized. This is something we do with a lot of LOBs that do not know how to "behave" correctly and I really enjoy when it works.
  • Use Microsoft Enterprise Desktop Virtualization (MED-V) to deploy the application in Windows XP Mode. No, this is not even close to a perfect solution, but if the alternative is to manually install the application on 2,000 computers in 13 different countries, I'll pick MED-V any day of the week

Back to top

Things to consider

One thing you should consider if you haven't already: For each and every application you add, you need to maintain it over time, which means updates, patching, and, if you do create new images, you might need to retest all packages. Overall, I have learned that "less is more" when dealing with deployment. The fewer different types of hardware, fewer operating systems, fewer applications, fewer people involved—all of this makes deployment much easier.

Back to top

Additional resources

About the author

Mikael Nystrom is a Microsoft MVP and Microsoft Certified Trainer (MCT) specializing in deployment, virtualization, and management. He has been involved in Technology Adoption Programs (TAPs) for several Microsoft products and technologies including Windows Server, Hyper-V, and Windows 7. In addition to his work as a speaker, trainer, and consultant, Mikael frequently shares technical news and insights through his blog and on Twitter.