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.
Actually, it's kind of simple. Here's a quick list of suggested steps:
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
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.
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
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
In Microsoft Application Compatibility Manager, switch to Analyze. Your screen should look something like this:
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:
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."
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
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:
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
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.
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
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.