Package Update Options: App-V 5.0 Sequencer

I am frequently asked about the various options available when updating a package using App-V 5.0. In this post I will clarify some of the key decision points and how they will impact the way you deliver your updated package.

Control Updates within the Sequencing Process

A commonly asked question is whether we should allow App-V applications to dynamically update on the client, the answer to this question in most scenarios is NO!

As a general best practice any update functionality in an application should be disabled. Updating of App-V packages should be consumed into the sequencing process for the following reasons:

– To maintain integrity and version control of your packages
– To reduce the payload into App-V state change on the client
– To better manage update delivery
– To reduce update impact to users
– To maintain a consistent experience for users

Edit, Update or Add?

When you come to updating on the App-V Sequencer you have three different options:

Here’s a breakdown of the difference:

Update Application in Existing Package

This option allows the package to re-delivered (de-virtualised) back to the local operating system before monitoring for changes. This option will give you the option to redefine your streaming methodology before arriving at the package editor for final review/changes. Use this option for general updates to a package that involve running updates that expect to see the package natively installed, changing fundamental assets of the package or significant changes to registry and file systems. Also use this option if you want to amend shortcuts and FTAs of your package inside the package editor (annoying).

Edit Package

This option allows you to jump directly to the package editor which allows changing of configuration, file, registry, services and deployment options. Remember the package editor is available at the end of the other two options aswell. Use this option if you want to quickly change something about your package without de-virtualisation, the shortcut/FTA tab however will not appear when choosing edit, you need to use either upgrade or add to see this in the package editor.

Add New Application

This option allows you to go through the same steps as Update however it also gives the option to configure the new application to a golden state, like how you would when you first sequence a package. To be fair you still have the opportunity to do this when choosing the standard update while the monitoring phase is taking place. Use this option if you are not just updating an existing application in the package rather adding a new application which needs to be configured in its own right.

De-virtualisation

De-virtualisation has been around for a while now, stretching back to App-V 4.x. It essentially refers to the redelivery of an App-V package back to a locally installed instance on the machine. This allows the updating and patching of applications in a traditional fashion within the sequencing process as everything gets redelivered to where it should be. It also allows for the efficient running and testing of the application while removing the virtualisation aspect.

All the following components are redelivered back to the OS during de-virtualisation:

– File
– Registry
– Environment Variables
– Extension Points

De-virtualisation happens by default when using the Update or Add workflows however you can also do this manually by using the Expand to Local System feature…

This feature can also be very useful when sequencing add-ons or applications that have dependencies when the dependency has already been packaged. For example rather reinstalling and configuring Java on the Sequencer every time I need to sequence a package that requires it, I can simply redeploy my existing App-V package of Java to the local machine before installing the dependant application. This saves both time and potential for incorrectly installing the dependency on the local machine. Infact, depending on which sequencing workflow you chose when creating a new package, the option for de-virtualisation will be also presented where applicable.

Saving an Update

The process of updating a package will follow the same standards and techniques you would employ with standard sequencing and there shouldn’t be anything unfamiliar about the process compared to creating a new package regardless of which workflow you chose. The final decision point however is how you choose to save your updated package:

Essentially you have a simple question to ask yourself before saving:

Does a single user need to be able to run this updated package alongside previous versions?

If the answer is no, then an in-place upgrade will ensure that when this package is delivered it replaces the previous version available. This is all maintained by a static package GUID and a incremented version GUID. Use this option when you are not interested in running the update side by side with its predecessors and just want to update what is already out in your environment. Do note however, even with this option you can have multiple users on the same machine running different versions of the same package, the restriction is only on a single user running multiple versions. By default when using this option the Sequencer will append a underscore separator and version number to all files saved out, this behaviour can be turned on a off in the Tools -> Options… menu.

Does a single user need to be able to run this updated package alongside previous versions?

If the answer to the question above is yes, then you will need to save as a new package to allow a in parallel upgrade. This is achieved by not only changing the version GUID but also the package GUID itself, all handled at save time by the sequencer. This means there will be no conflict on the client side in terms of GUIDs, do be aware that you need to ensure there isn’t scope for conflicts of integration points such as shortcuts and FTAs by changing these accordingly too. Use this option if you need to allow users to run both the update and a previous version side by side. This can be useful for UAT or testing scenarios whereby you do not wish to remove a previous version of a package but also wish to give users access to a newer version simultaneously. It is also suitable for major upgrades or releases that didn’t need to be sequenced from scratch.

State Change

State change refers to change a user makes to an App-V package after it has been delivered, this typically includes user configurations and customisations, this topic is discussed here at length, this concept does need to be considered when updating too.

An interesting fact about state change is it is only ever stored under the context of the package GUID and never the version GUID. This means aslong as you opt for a in place upgrade, user customisations will carry across to the updated package. If however you opt for a in parallel delivery of the update, no previous state change will apply as the package GUID will have changed. So in short if you need your user settings to carry across versions, always use the standard in place save options for your update!

Check out the following for more resources on updates with App-V 5.0:

Package Upgrades with App-V 5.0

Streaming Differential Upgrades with App-V 5.0

App-V 5.0 Sequencing Guide