This content is part of the Essential Guide: Compare top tools for deploying virtualized applications
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

What you need to know before using Microsoft App-V Sequencer

Microsoft’s App-V Sequencer tool quickly packages most applications, but there are a few limitations to be aware of before using it.

Microsoft’s App-V Sequencer packages most applications for virtualization and although this component is fairly straightforward, there are some pitfalls that you need to be aware of before using it.

This article covers some  considerations and issues that you are most likely to encounter when using the Sequencer, including support, application paths, updates and OS compatibility.

Operating System Compatibility
As a best practice, you should always perform sequencing on a machine that runs the same operating system and the same service pack level as your users.

Using consistent operating systems isn’t an absolute requirement. If you sequence an application on a machine that’s running Windows 7, it may still work on desktops that are running older operating systems. Even so, there are architectural differences in every version of Windows and you can improve the odds that your application package will work if you ensure operating system consistency.

Application Updates
App-V streams applications to end users instead of installing apps directly on desktops. Therefore, the App-V Sequencer creates application packages which contain everything that the application needs to run. It sounds convenient, but this approach to application deployment can make it difficult to update your apps.

Microsoft makes some provisions for updating its own applications. The Advanced Options portion of the App-V Sequencer contains an option to allow Microsoft Update to run during the monitoring phase of the sequencing process.  Doing so provides the opportunity to include any currently available updates in the package that you are creating.

Many non-Microsoft applications have a built-in auto update mechanism, but you should only sequence an application if you can disable its update mechanism.

The problem with automatic updates done in App-V is that any changes are applied to a delta file.  Because these delta files are user specific, you could end up in a situation in which the client folders grow to an excessively large size and performance may begin to suffer. You could also end up in a situation in which users are running different versions of the same application because some users have applied updates while others have not. 

That isn’t to say that virtualized applications can’t be updated. Applications should be updated centrally through the Application Virtualization Management Console. The console provides a function whereby you can right click on a package and choose the Add Version command from a shortcut menu. This allows you to add an updated application package that will seamlessly be made available to the users.

Hard Coded Paths
One of the biggest issues that you are likely to encounter when sequencing an application has to do with the application’s path.

Before you sequence an application, the sequencing machine must have a Q: drive to which the application can be installed. If Q: is already in use, you can use a different drive letter. Remember that the drive letter needs to be available on both the sequencer machine and on the client machines. The drive letter that you choose should be mapped to a volume on your sequencer machine.

After you choose a drive letter to use, you can begin the sequencing process by installing applications to your chosen drive (Microsoft recommends using Q:). The installation path should partially mimic the path that would be used in a normal installation. The difference is that you should create a package root directory that is unique to that application. The package root directory that you create takes the place of C:\Program Files.

For example, suppose I want to create a package for Adobe Acrobat Reader 10.0. This application is installed by default to C:\Program Files\Adobe\Reader 10.0. If I were to package this application, I might create a package root directory named Q:\PDFRead and then install the application to Q:\PDFRead\Adobe\Reader 10.0.( In case you are wondering why I used PDFRead as the name of my package root directory, it is because Microsoft recommends using package root directory names that conform to 8.3 naming conventions whenever possible).

Although it is generally easy to choose an installation path, the fact remains that some applications cannot be installed to a custom path. You may also run into applications that use batch files with hard coded paths. Occasionally it may be possible to modify such applications to force them to install to the Q: drive, but generally you are going to be better off not sequencing such applications.

Lack of manufacturer support
One last thing worth mentioning is that some applications are documented as not being supported with App-V. Most application publishers do not even address the issue of virtualizing the application, but occasionally you will find a publisher who will not support virtualized instances of their applications. For example, Microsoft does not support virtualizing Internet Explorer.

Overall, the App-V Sequencer tool seems to work pretty well for most applications, but some applications are a bit stubborn. Determining which applications you can package comes down to trial and error.

Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies.

Dig Deeper on Application virtualization and streaming

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.