Application Management and Preparing for a Windows 7 Deployment
If you are like most desktop service managers, you probably have several applications that you manage; and depending on your users, there may be several applications that you don’t know about. There are a few places where “Standard User” or “Least-Privileged User” accounts aren’t the norm, and users can install whatever applications they want. If this sounds familiar, then you probably have a bit of work to do in terms of detecting, rationalizing, and testing the applications that your users have to prepare for Windows 7. You can address compatibility issues by using a variety of approaches, and we’ll discuss all of these approaches in a minute.
The next major area you’ll need to worry about is how to get those applications or corresponding newer versions onto your users’ desktops that are running Windows 7. There is a fair chance that you’ve been cloning hard drives over the past couple of decades and don’t necessarily have automated installation packages for all the applications that you want to deploy into the new Windows 7 environment. Some applications aren’t packaged for silent installation, making it hard to customize installations to include only applications that are specific to user roles. Along with other factors, this means there are a lot of organizations that have 20 to 50 applications present on every workstation—even if the users only need 5-10 of those applications on average. With the newer deployment tools, you can save your money on these applications and install what is required per user instead of giving them everything. This will save you on licensing and may improve the performance of Windows if some of those applications launch at startup. I’ll talk about the application packaging process after we dig a bit deeper into application compatibility.
Application Compatibility
Contrary to popular belief, the application compatibility process doesn’t begin with testing. The first step you’ll probably want to take is to collect an inventory of your hardware and software assets. Be prepared to discover more applications than you thought you had. One tool you can use is the Application Compatibility Toolkit or “ACT.”
You can download the ACT from the Microsoft Web site: Application Compatibility Toolkit.
The Application Compatibility Toolkit isn’t a magic wand that you wave at applications to “make them work,” but it does provide the tools to inventory your applications, hardware, and devices; evaluate runtime compatibility of applications while collecting data; and compare what you’ve collected to a central database managed by Microsoft with compatibility data from ISVs and the IT pro community.
When I present the toolkit at events, I often get asked, “Hold on, did you just say the Application Compatibility Toolkit discovers hardware and devices, and not only applications?”
Yes, it’s true. ACT finds the applications wherever they may reside and it also reports hardware and devices that are detected. One thing to point out is that while most inventory tools relegate themselves to only data found in Add/Remove Programs, ACT also looks in multiple locations of the registry (Run, Run once, file name extension handlers, application paths, and so on), and in services. ACT tends to find any application on the system or otherwise launched by the user while we’re performing an inventory. After you deploy the lightweight Data Collection Package agent in ACT, ACT detects the information on your users’ Windows XP workstations and sends the information back the network location you specify, then processes the data and reports its findings to you.
Check out a video on TechNet about Data Collection Packages: Creating Data Collection Packages to Generate an Application Inventory
The following graphic shows a sample application inventory in the Application Compatibility Manager:
.jpg)
Many IT shops have an inventory that they are confident in and they don’t necessarily want to deploy agents to their users—it’s completely understandable. In this case, is there anything better than using the consumer compatibility site to search applications and devices one-by-one?
If you have more than about 20 applications, using the consumer compatibility site probably isn’t your best option. We also publish the following list of known compatible applications that you can use to query your application inventory database:
Windows 7 Application Compatibility List for IT Professionals
What’s next? If you have a thorough inventory, it is extremely likely that you won’t want to move all of the applications you find from Windows XP into your new Windows 7 environment. There might be five different media players or eight different applications that read PDF files on your users’ collective computers. In fact, many companies can eliminate 90% or more of the applications they inventory because they are duplicate in nature, hardware-based, or undesired. You can use the filtering provided in ACT to help reduce the list.
The following graphic shows a categorization of applications by using the Toggle Filter in Application Compatibility Manager:
.jpg)
This is important, because it is much easier to test 100 applications compared to 1000 applications and you can often reduce your inventory list in a couple of hours. I’d personally rather test 100 applications than 1000, and I’m guessing that most would agree.
Watch a video on TechNet about working with ACT inventories: Analyzing Compatibility Data Returned by Data Collection Packages
Now that we have the rationalized list of applications and static data from ISVs as to whether they are compatible, the fun starts with testing these applications without ISV information. You should find that most of your applications work in Windows 7 and this is especially true for packaged (ISV) applications that were released in the last three years. The in-house developed applications that you’ve had for five or more years may require special attention. The major issues to look for are applications that like to run under administrative context and have free reign of the computer they run on, applications that are locked to a specific Windows version number, or Web applications that require Internet Explorer 6. If you have already deployed Internet Explorer 8, and your users generally have Standard User accounts, then you won’t have as much work to do. You can find more information about why applications may experience issues running on Windows 7 in the following guide on TechNet: Understanding Application Compatibility.
After we find out what is not working, we have a couple of options to make them work:
For packaged applications from ISVs, the best approach is always to find an application that runs natively on the version of Windows you want to install it on. Sometimes there are free updates for these applications and sometimes not. Using the application as intended and tested by the ISV for Windows 7 ensures that the ISV can support your users and you are running their application in a way that they have tested it.
For in-house developed applications, the best approach is to recode the application to make it run natively. If you don’t have the source code or there is an easy fix, you can use compatibility fixes (or “shims”) to get the application to run without recoding it.
For more information about shims, see the following TechNet site: Managing Shims in an Enterprise.
Also check out the video about commonly used application shims: Mitigating Application Compatibility Issues with Common Compatibility Fixes
If you just can’t make an application work, then it isn’t necessarily “game over.” If you’ve exhausted all other options to make the application run natively, then you can use Virtual PC to run the application in a Windows XP environment. Virtual PC with RemoteApp integration is much more intuitive for end users than it has been over the years. With Virtual PC, we can now publish shortcuts on the physical computer’s desktop or Start menu to applications that are contained in the virtual machine, and applications can be launched individually without exposing the whole Windows XP desktop. The trade-off is that you’ll have two operating systems to manage per user.
If you get to this point and you have a managed environment, I’d recommend that you look into Microsoft Enterprise Desktop Virtualization so you can manage the virtual environment. For more information, see Microsoft Desktop Optimization Pack.
After you’ve worked through all of your applications—inventoried them, rationalized them, and mitigated incompatibilities—you might think the fun is over. Almost. Now that everything is known to be working, you’ll want to figure out how to install your applications in an automated way. In the next section, I’ll talk about approaches to get to a thinner image. But if you’ve been packing applications into your base operating system image and performing sector-based captures of your reference computers’ disks, then you may want to look at ways to reduce your image count and use the hardware and language neutral benefits in Windows 7 to get a single image. Getting to a single image in a larger organization typically means application packaging work is required.
Application Packaging
For some, application packaging and figuring out how to automate the installation of your applications will be as easy as finding the silent installation commands from the vendor. Usually these are found in installation guides, Internet forums, or by using the ever-handy “/help” or “/?” commands in the command line.
For in-house developed applications, there is a decent chance that silent installation commands don’t exist for all of your applications and those applications will need to be packaged for the first time or repackaged if the installer package didn’t work with your new configuration. (Common examples are 16-bit installers when moving to a 64-bit operating system or operating system version checks in packages looking for Windows version 5.1).
There are a couple of tools to help you create Windows Installer packages as easily as possible. These are handy because they tend to follow normal msiexec.exe silent installation commands. Microsoft Application Virtualization also provides what is essentially a packaging mechanism with the application sequencing it uses to create virtual applications. For more information about these tools, see the following Web sites:
You can avoid packaging some applications by not including those applications in the standard operating system build process and by prestaging installation files locally or making them accessible to users on the network. In the cases where everyone in the organization needs the application anyway, you can install those applications on your reference computer and create a custom image using ImageX. We’ll talk about the balance of how many applications to include in the custom image in the next section.