Part 3: Application Management and Preparing for a Windows 7 Deployment

Part 3: Application Management and Preparing for a Windows 7 Deployment

  • Comments 2
  • Likes

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 out there where “Standard User” or “Least-Privileged User” accounts aren’t the norm and users can just install whatever applications they want. If this sounds familiar, then you probably have a bit to do in terms of detecting, rationalizing, and testing the applications your users have to prepare for Windows 7. For any compatibility issues, you can address them using a variety of approaches and we’ll discuss all of those 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’ Windows 7 desktops. 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 installs to include only applications specific to user roles. That along with other factors means there are a lot of organizations out there having 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 any of those applications tend to launch at startup. I’ll talk a little bit about the application packaging process after we dig a bit deeper into application compatibility.

Application Compatibility

The application compatibility process contrary to popular belief doesn’t begin with testing. The first thing you’ll probably want to do is 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”). 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 just applications?”

Yes, it’s true. ACT finds the applications wherever they may reside and also reports on hardware and devices detected as well. One thing to point out here is that while most inventory tools relegate themselves to just data found in Add/Remove Programs, ACT also looks in multiple locations of the registry (run, run once, file extension handlers, app paths, etc.), and in services. ACT tends to find any application on the system or otherwise launched by the user while we’re performing an inventory. Once you deploy ACT’s lightweight Data Collection Package agent, 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 the ACT video about Data Collection Packages here.


Many IT shops have an inventory they are confident in and don’t necessarily want to deploy agents out to their users – it’s completely understandable. Is there anything better in this case than using the consumer compatibility site to search applications and devices one-by-one? Yes, if you have more than about 20 applications, using that site probably isn’t your best option and for that we also publish a list of known compatible applications that you can query against using your own application inventory database.

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 PCs. 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 even use filtering in ACT to help reduce the list.


This is important, because it is much easier to test 100 applications compared to 1000 applications and reducing your inventory list can often be done in a couple of hours. I’d personally rather test 100 applications than 1000, and I’m guessing that most would agree.

See the video for working with ACT inventories here

Now that we have the rationalized list of applications and static data from ISVs as to whether they are compatible or not, the fun starts with testing those applications without 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 2-3 years. The in-house developed applications that you’ve had for 5 or more years may require special attention. The major things to look for are applications that like to run under administrative context and have free reign of the computer they run on, or if they are locked to a specific Windows version number, or Web applications that require Internet Explorer 6. If you have Internet Explorer 8 already deployed and your users generally have Standard User accounts, then you won’t have as much work to do. You can find more information on why applications may experience issues running on Windows 7 in the “Understanding Application Compatibility” guide on TechNet.

Once 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.

· 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. More information about shims can be found in the TechNet Library.

Check out the video on commonly-used application shims here.

If you just can’t make it 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 that is has been over the years. With Virtual PC, we can now publish shortcuts on the physical machine’s desktop or start menu to applications 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 do 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.

Once 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 blog I’ll talk about approaches to get to a thinner image, but if you’ve been packing applications into your base OS image and doing sector-based captures of your reference computers’ disks, then you may want to look at ways to get your image count down 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 installation of your applications will be as easy as finding the silent install commands from the vendor. Usually these are in installation guides, Internet forums, or found using the ever-handy “/help” or “/?” switches in command line.

For in-house developed applications, there is a decent chance that silent install 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 64-bit OS or OS version checks in packages looking for Windows version 5.1). There are a couple of tools out there like Flexera Software’s AdminStudio to help you create MSI packages as easily as possible. These are handy; as they tend to follow normal msiexec.exe silent install commands. Microsoft Application Virtualization also provides what is essentially a packaging mechanism with the application sequencing it uses to create virtual applications.

For some things you can avoid packaging by not including those applications in the standard OS build process and pre-staging 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 next time though.

That’s all for today and thanks for reading.

Jeremy Chapman

Windows 7 Deployment

You must be logged in to comment. Sign in or Join Now
  • I love Windows 7! I think you had a great deployment and I look forward to future operating systems from Windows. I think you really improved compared to the Vista release.

  • Thank You ! I am looking forward to installing Windows 7 Enterprise Today after I get back From The Veterian's Day Parade! ><>