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

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.

ABOUT THE AUTHOR:
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.

This was last published in April 2011

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I use application virtualisation at the Hospital that I work for and it’s one of the best things that ever happened to us, being a Hospital we get stuck with a lot of old and NOT SO GREAT software which is a pain to install and support and while many software venders don’t support this deployment method, we have found they don’t need to because once you get it right in the packaging stage I doesn’t break and any errors that do arise we can generally replicate in a non appV environment.
This tool has made life for our I.T department so much easier, after virtualising our PAS the calls to the Service Desk dropped by about 40%. We have packaged around 45% of our apps and the list is growing every week. It makes keeping track of application versions and change management simpler. Rolling out new apps isn’t the problem that it once was, sending 2 techies off for a few days to locally install software for a department is no longer the case. Once you overcome the hurdle of packaging its very simple. The packaging stage is the most tedious, the worse the software is the worse it is to package. This makes testing a key part of the deployment process however once it’s signed off you give access to relevant end users and then on to the next one. I would definitely recommend this to anyone interested in having a better way of deploying apps.
Cancel

-ADS BY GOOGLE

SearchEnterpriseDesktop

SearchServerVirtualization

SearchCloudComputing

SearchVMware

Close