App-V 5 Versions: The Release Timeline

We have had a fairly constant flow of updates to App-V 5 ever since the release in November 2012. From service packs to hotfixes, we have seen the product grow and mature. However even I sometimes get confused or forget exactly what features or fixes came with which release.

Of course it is desirable to always be on the latest version however I have found that sometimes organisations will still be on previous releases. This can be due to many reasons such as political, procedural or even technical.

So below I have drawn up an easy way to see where you are with your current implementation and what key benefits you might gain by moving forward.


Last updated: Dec 2016

I have intentionally only outlined what I deem as ‘key’ features or fixes of a particular release, I have also not listed releases which have been deprecated.

If you want more detailed information about App-V releases take a look at this well maintained list by Tim Mangan here. Also check out the official Microsoft list of release KB articles here.

August 24, 2015

App-V 5.1 | The Feature Run Down

Great news, App-V 5.1 has finally been released! It has been a little while since the announcements at Ignite but now it is here at last. Overall this release goes a long way to consolidate all the work that has been put into App-V 5.0 since its original release and sends a strong message to anyone still on 4.6 that it’s time to migrate.

Here’s the official announcement and below is an overview of all the new features! Keep scrolling for a full run down…


Improved package conversion for 4.6 to 5.x

Added support for multiple scripts per event

Added enhanced Package Editor abilities


Modernised App-V Server Console


Windows 10 support

Reduced Copy-on-Write extensions exclusions list

Merged Environment Variables for Connection Groups

Consolidated and simplified client event logs


Improved package conversion for 4.6 to 5.x

App-V 5.1 brings about some marked improvements with the conversion tool, a feature which has had focus in releases previous to this one in an effort to improve the success rate that users can achieve when converting their legacy 4.6 packages over to the new format. 5.1 brings a range of improvements, the main two being the ability to carry across scripts from legacy packages over to the new format and the support for root drive hardcoded paths.

Script Conversion

App-V 5.1 will convert any legacy HREF 4.6 scripts over to the new format as shown below:


The 5.1 Sequencer will try and correlate events and triggers accordingly and give pretty decent feedback when it makes assumptions. For example here we are advised that the LAUNCH event as been translated into a StartVirtualEnvironment event, it also gives information about how it will treat the WAIT=TRUE in my legacy package script:


You may also notice the new switch available called -OSDsToIncludeInPackage which allows us to specify which .OSD files should be consumed into the package and User/Deployment Config XMLs, before 5.1 this granularity wasn’t available and all OSDs got pulled in.

As mentioned only HREF conversion is supported along with environment variables and registry, SCRIPTBODY is not supported:


Hardcoded Path Translation

The Q:\ drive (or whatever letter you used as a mount drive in 4.x) was an integral part of how we packaged in the legacy version of App-V, this means there is a strong possibility your 4.x packages have hardcoded paths tucked away inside its files (commonly in .ini, .conf and .xml), this is partly the reason why Microsoft always insisted the same drive letter was used as a mount across Sequencer and all clients.

Previous to 5.1 the converter never really dealt with this and would warn you after conversion:


Now with the improvements made in App-V 5.1 we will find that no warnings are given. That is because the Sequencer will pick up on the presence of these hardcoded paths and create a legacy mount drive mapping within the FilesystemMetadata.xml


By injecting the Q:\ Drive location into the root level translation, the client will know to map any requests from package processes to the mount drive into the relevant VFS location. Previously you would have something similar to this in the same file which likely would have meant your package would fail if it tried to refer to files in its own root via a hardcoded path:


Added support for multiple scripts per event

Bringing back a long awaited parity point with 4.6, 5.1 now supports multiple scripts per event. This basically works by calling a “scriptrunner.exe” as the path for your script handler. You will notice this .exe is included as part of your App-V Client install. You then simply pass -appvscript parameters in the section of your script to list out all the scripts you wish to run.


For example we might have something similar to below if we wanted run multiple scripts upon publish of our package. Notice we not only have the ability to call scripts but to also pass arguments against them and specify App-V related parameters too.

-appvscript checkregistry.ps1
-appvscript checkprereqs.vbs –appvscriptrunnerparameters –wait –timeout=15 –rollbackonerror
-appvscript checkerrors.bat "error.log"
<Wait timeout="75" RollbackOnError="true"/>
Added enhanced Package Editor abilities

So the familiar package editor has also had a bit of a revamp with a few key improvements:

Ability to import and export the manifest.xml

This allows you to make changes that become permanent and default within the .appv itself rather than rely on the dynamic configuration files. For example if you had a script that is required to allow your package to run and this script was required for all deployments then you could put this script into the manifest.xml and import it into the .appv. This feature is on the Advanced tab of the Package Editor.


Luckily the boys over at Virtual Engine have already updated ACE (my go to dynamic config .xml editor) to now support manifest.xml files! Check it out here.

Ability to disable Brower Helper Objects (BHOs)

This new checkbox allows you to choose not to have BHOs enabled in your package, previous to 5.1 BHOs where enabled by default with no way to change this in the package. Now for example if you want to publish a package globally but don’t want BHO integration to occur you can untick the box shown below. It will then comment out the BHO references in the manifest so they no longer apply, notice it doesn’t use a true/false switch like other integrations. If you’re wondering what BHOs actually are, then scroll half way down this post here.



File and registry management improvements

There has been a range of small improvements made to the Package Editor in terms of the way we work with files and registry. Some improvements are less noticeable like the current path being displayed as you navigate the registry, others are more noteworthy such as the addition of “find and replace” and the options to import entire registry locations or file directories. All of these features increase the usability of the package editor and should make life that little bit easier.




Modernised App-V Server Console

App-V 5.0 brought forth a new web based management console built on Silverlight. In 5.1 this console has now been re-written in HTML 5. This should allow much easier development of the console going forward and also hopefully get rid of some of those annoying window scaling issues seen in the previous console.


Other improvements to the console include specific URLs per page which mean it is easy to bookmark or share links to specific pages or packages:


Auto resizing of console for those of you eager to use the console on smaller screens such as mobile devices is also accommodated:


Also a new notification centre that is less distracting and less tedious than the last with its overlapping notifications that needed to be individually dismissed. The console allows you to just click anywhere on the screen to ignore or dismiss all notifications in a single action if you want to clean up:



Windows 10 support

As you would expect with the recent release of Windows 10, it is now also supported with this new release of App-V.

Reduced Copy-on-Write extensions exclusions list

As some of you will remember App-V 5.0 had a long list of CoW exclusions (file types that cannot be written into the VE while it is running), you can refer to this here. 5.1 has now shrunk this list of 59 file types down to the following:

  1. .exe
  2. .dll
  3. .ocx
  4. .com
Merged Environment Variables for Connection Groups

Probably one of the more ‘under the hood’ and less visible changes, packages in a connection group will now merge their respective environment variables. In previous releases only the top level package of a connection group registered environment variables.

Consolidated and simplified client event logs

A great step forward to troubleshooting, anyone who has had to do beyond basic troubleshooting of the App-V Client will be familiar with the App-V Debug logs, a long list of an additional 32 nodes containing logs which could be enabled. The problem was knowing which log to enable. Microsoft have now rolled up these logs in a more simplified model which retains the three Admin, Operational and Virtual Applications nodes but has consolidated the debug logs into five additional logs.



5.1 training banner 3

August 17, 2015

MVP 2015: The romance continues!

2015-07-16 16.10.24

A few weeks ago I was informed that I have been selected to join an exclusive group of Microsoft community leaders and industry experts known as Microsoft Most Valuable Professionals (MVPs). The programme looks to highlight and recognise people outside of Microsoft who have made significant contributions to their software and the communities built around it. I have to say it is a massive honour to be in the company of these great people and I just hope I continue to do my bit for App-V. I also want to say a massive thanks to everyone who has supported me on my journey so far, that includes everyone that reads this blog!

What romance?!

Well I’ve always had a soft spot for Microsoft ever since I installed Windows 95 (Yes that was my first OS, shout out to the GUI generation!) and I have been courting the company ever since I graduated back in 2008. I remember failing to make it onto their graduate programme and feeling pretty disappointed, so I dusted myself off and spent some good years as a system admin, grabbed myself some MCPs and MCITPs and worked my way up through three different organisations learning like never before. I quickly got labelled as the “Microsoft guy” and revelled in the title.

Things were going cool until the IT Consultancy I was working for got acquired, my job as a sys admin looked increasingly redundant as I helped migrate all our systems into our acquirers infrastructure, all the time while being promised there would a be different role for me once the merge had completed. My immediate reaction to the acquisition was to update my CV and pick up the phone to recruiters so I had a plan B if this promise wasn’t kept or if the new role offered wasn’t right for me.

My manager who was my strongest supporter at the time pulled me aside one afternoon and said “Tham, don’t do nothing hasty, I’m going to make sure you find your place in this new world we find ourselves in, I’ve got your back”. My manager went off work for a few weeks to have an operation to remove a lump that had formed on his cheek but before he left he said “Tham! Make sure you are still here when I get back!”, I reassured him I would be and not to worry. I cooled it off with the recruiters while my manager was away.

Sadly, my manager never made it back to work, he passed away due to an infection picked up after the operation.

A few days after the funeral while at work I spotted a visitor from Microsoft in one of the meeting rooms training our support team on performance analysis. As he was leaving, I took a long shot and approached him asking whether he knew if Microsoft were recruiting much in the area, he was surprisingly positive and gave me his details. Long story short it ended up with me sitting at Microsoft HQ interviewing over a whole day. I got the job! Literally a dream come true!

I remember on my first day at Microsoft they said I’m going to specialise in App-V, I said “App what?! Never heard of it!”. I spent my first 6 months learning from two of the best people in country for App-V, its only somewhere like Microsoft where you can work with people who never hold back in sharing knowledge and open doors for you without a concern for themselves. I recall always regarding the MVPs of App-V like celebrities, the same for the products groups who were developing the product itself, they were these ultra smart people on top of their game.

I travelled all across the world with my new App-V skills, carving out a space for myself and building a brand amongst my peers and customers alike. Microsoft was the first place I’ve worked where I felt I could bring my personality to work and didn’t have to hold back, I even found myself rapping on stage at corporate events! However rapping wasn’t the only stage time I got, as my confidence grew with App-V I found myself speaking at conferences and presentations all over the place, from internal events such as the MVP summit and TechReady through to public appearances at TechEd and App-V User Groups.

At the same time my mentor had pushed me to follow in his footsteps and start my own blog – I named it Virtual Vibes. The blog grew in popularity over time to the point that customers knew bout my blog before I reached their site. Over time I slowly started to find my self engaging more and more with those product group members and MVPs that I never thought I would end up interacting with.

Working at Microsoft was the highlight of my career to date and deciding to leave was such a hard thing to do. There’s no juicy gossip to share on incidents that incited my move only the desire to explore life outside of MS under my Virtual Vibes banner. Microsoft gave me just as much as I gave it, I just hope I done the name proud, I left only with positive memories.

Since leaving I kept on blogging, was invited to speak at Microsoft Ignite in Chicago and kept good contact with the team back in MS. I somehow managed to maintain much of the contacts and presence I thought I would lose by leaving MS. Also as I essentially started working for myself, I found new freedom in engaging with partners, customers and organisations in the tight knit space called application virtualisation. I also took the initiative to run quarterly App-V training courses where I have had attendees from so many different backgrounds and countries, it’s a great feeling sharing knowledge, meeting new people and presenting, this has to be the best combo! All the while however there is always a part of me that misses Microsoft and everything that came with having that association…

And then here am I a year later as an MVP, I guess the romance continues…

August 5, 2015

PublishingSource with App-V 5

In this brief post I am going to explain the purpose of the PublishingSource registry value in App-V 5.0 and how it works.

PublishingSource can be found in either of the following locations depending on whether the package has been published to the user or published globally:

HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages\{PACKAGE GUID}\Versions\{VERSION GUID}\Catalog



This value in registry is used primarily by App-V Publishing Servers to register ownership of delivery of a package. If the App-V Server delivers an App-V package you should see something similar to this in registry:


It is via this PublishingSource value that the App-V Publishing Server comes to know whether it has authority over a package or not. A Publishing Server will never unpublish a package if it is not listed in PublishingSource. A simple way to observe this behaviour is to remove the data from the value and try and unpublish the package, the package will essentially become orphaned and remain on the machine. The publishing server however will retake ownership should you ever re-publish the package.

Both Standalone mode and SCCM leave the PublishingSource value empty upon publish of an App-V Package.

Standalone mode negates ownership of delivery in its nature. This also means packages that are delivered in standalone mode will not be removed by a publishing refresh with App-V full infrastructure.

SCCM 2012 has its own way of tracking ownership of App-V packages and it holds record of this in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\VirtualAppPackages

Here you find a maintained list of all App-V packages and their relevant properties.


One of the key values in here is the App Delivery Type Id which contains unique GUIDs identifying the scope and deployment type, SCCM uses these to understand whether or not a deployment is present and what it’s status is.


You can find reference for this check in the AppDiscovery.log when a deployment is being assessed for delivery:


Its for this reason you should not use stand alone mode to remove an App-V package that has been delivered via SCCM 2012 as it will not clean up these references and SCCM will believe the package is still present on the machine.

August 5, 2015

Planning for App-V Virtual Environments with SCCM 2012

When I first took a look at how SCCM manages App-V connection groups I have to say I was really impressed with the flexibility of the rule based approach of Virtual Environments. Since then App-V connection groups have developed and moved forward, most notably with the recent SP3 release.

I have taken the opportunity while working with my banking client in London to revisit this feature in SCCM to understand how we could actually use this feature in our rollout and to understand if it can really fulfil our requirements. As I stressed in my recent session at Ignite, connection groups should be given adequate planning and consideration in any App-V rollout, after the packages themselves, this feature is second inline as far as management overhead and shouldn’t be an after thought.

So how do Virtual Environments stack up when we actually want to use them in large scale deployment?


Timing is always a sore subject when it comes to SCCM and a common gripe is that application delivery takes too long. We have been told that the latest service pack brings “improved performance that reduces the time required for apps to display after the first logon for non-persistent VDI environment” but from what I understand this is still no way near instant or close to App-V Server.

So what about connection groups? Well the good news they are not slower, virtual environments are assessed and delivered during standard refresh. This means the gap between application delivery and connection group delivery is minimal, in my testing this was approx. 3 seconds between delivery of two applications and the relevant connection group. You will see something similar to this in your AppEnforce.log:

Installing App-V 5.X virtual environment VirtualEnvironment ID : ScopeId_B69B2597-FF21-4C62-8E63-7390B5BD354F/VirtualEnvironment_73491fa0-ecbc-441d-b75a-1fe175b6862a, Revision: 1, with specified package list:AppvClientPackage.PackageId=”a1d329c8-09d2-4215-91a8-1b5085fa01e2″,VersionId=”95b62102-1931-498e-8376-d688c73a2acf”;AppvClientPackage.PackageId=”f3a60802-d922-4646-88f0-c69c398b45e6″,VersionId=”735ae163-9644-4abb-b35b-eb2539556b02″

This is a big deal as nobody wants applications being delivered without the required connection group, as they will most likely fail until the delivery. This does require that connection groups are defined before or at the same time as application deployment.

If the connection group is generated after application delivery I have found there is an extended wait of > 15mins by default before it is delivered.

Optional Members

The concept of optional members was introduced to the App-V Client and Server in the recent SP3 release however SCCM 2012  had this capability before.


Using the OR operator to connect members within a group means they will be considered optional for the connection group to be delivered. Keeping packages in a single group where possible therefore increases ease of management and overall flexibility. For example above we have included a mix of plugins within the same group which means they will all be non-mandatory for qualification to receive this connection group.


There is no concept of targeting connection groups to collections in SCCM 2012 like how you would applications, Connection Groups are not first class citizens like they are with App-V full infrastructure. Virtual Environments are ruled based definitions and are assessed dynamically client side if and when applicable, they are available globally and you either get them or not.

Also Virtual Environments can only contain deployment types from the application model so anything in the legacy package model cannot be used.

Mixed Member Targeting

SCCM 2012 will only deliver connection groups if all member packages are targeted to either user or machine exclusively. Mixed member targeting is supported with native App-V client and App-V server however this is not a possibility with Virtual Environments in SCCM. This can be a show stopper for some enterprises when planning Connection Group strategy especially when an organisation is moving from machine targeting to user targeting.

Use Any Version

While supersedance can be used to upgrade existing deployment types, the new deployment type must be explicitly specified in the relevant virtual environment, therefore there is no such thing or equivalent feature to “use any version” which the App-V 5.0 SP3 client understands. We can however use the optional OR operator to bring flexibility and accomplish in around about way the same behaviour but this still requires the manual addition of new deployment types.



Updates work as expected, when a connection group is changed in any way, it is reassessed at next policy refresh and updated accordingly.

Creating/Updating the connection group for Virtual Environment ScopeId_B69B2597-FF21-4C62-8E63-7390B5BD354F/VirtualEnvironment_73491fa0-ecbc-441d-b75a-1fe175b6862a. Context: User


There are two levels of priority and conflict resolution with connection groups, Virtual Environments unfortunately only handle one of these at present.

The first type of priority is between members of a connection group, this is handled purely by the ordering of members in the console itself, so if one package has a file or registry conflict with another then the highest in the chain will take priority.

The second type of priority is between connection groups themselves, a scenario described in detail here. SCCM currently does not give the ability to set the priority of a virtual environment nor does it handle any conflicts dynamically. So if Package A is a member of two separate connection groups and a user launches Package A, it will fail to launch. That is because SCCM delivers all connection groups with the same 4.2 billion priority value.


Due to the above shortfall you should be cautious not to every have a package that would be launched in more than one Virtual Environment.


Deleting a connection group from the SCCM console means it will be removed (eventually) from the client endpoints at next policy refresh.

Successfully disable and delete the connection group 72cb5e40-772b-404a-87ce-19a979633e37, Version Id eaf0c683-8b6d-47f4-a34e-faea27a19741, Context: User

Interestingly uninstalling a package which is a mandatory member of a connection group does not fail as it would in other deployment methods, SCCM client dynamically will create a new connection group which excludes the uninstall package and then go ahead and remove the package. This basically means an uninstall will always win and take place regardless of Connection Groups the package might be a member of. This could be seen as a positive or negative depending on your perspective. This also means you can end up having a connection group with just a single package as a member:


Before we unpublish the package a1d329c8-09d2-4215-91a8-1b5085fa01e2 version Id 95b62102-1931-498e-8376-d688c73a2acf for S-1-5-21-3366449900-1917713875-2491790561-500, check if we need to remove it from connection group


This isn’t something that can be precisely measured and while the sections above detail the behaviour you can expect, predictability can be an issue when working with Virtual Environments in SCCM.

One of the reasons for this is the loose way they are defined which means you might never gain a real grasp on which machines and users might have certain Connection Groups delivered to them. Also timing further expounds this feeling of vague control, for example sometimes after deleting a connection group I have found it is still present on my client the next day.


So to summarise, Virtual Environments have pros and cons in terms of management with SCCM. It has fell behind somewhat as Connection Groups have improved over time with the actual App-V product and some of these limitations might mean it isn’t a viable way to manage these package relationships if you have a complex environment. In other more simple scenarios Virtual Environments present a easy native way to deploy Connection Groups where timing and flexibility may not be as critical.

June 3, 2015

App-V 5.1 Announcement, Project C and App-V at Ignite 2015 – Chicago

**App-V 5.1 has now been released | For the App-V 5.1 Feature Run Down – Click here**

2015-05-04 08.20.36

Wow, what an amazing trip to Chicago that was! Ignite was buzzing with people, technology and some really great sessions. Despite the fact that there was only two App-V focused sessions in the week we still managed to pack in the announcements and some really cool content.

App-V 5.1


The next release of App-V (5.1) scheduled for this summer got a lot of love this Ignite with the official announcements being made in both mine and Briton’s session and Steve and Aaron’s. With improvements to the server console, package conversion, scripting capabilities, package editor, CoW support among other things, do make sure you check out the sessions below for more information.


Now App-V 5.1 has been released you can check out all the new features here.

Project C


Project Centennial is probably one of the most positive announcements in recent times concerning App-V and its wider adoption as a standard. It gives even more confidence to everyone that it is core to Microsoft’s strategy going forward and affirming that anyone who uses App-V already is on the right path for the future of the Windows platform. This particular project focuses on the conversion of classic apps to universal and uses underlying App-V capabilities to achieve this. Check out John Sheehan’s session at the Build conference the week before Ignite for an in-depth look, also be sure to check out the Ignite sessions to hear from Senior PM Manager Briton and Senior PM Aaron on this topic.


Check mine and Briton’s session here where we talk about how to get the most from connection groups in App-V 5.0:

App-V 5.0 SP3: Advanced Connection Groups

Also don’t miss Steve (aka The Gladiator) and Aaron’s session here which covers some great techniques on how to get the most from both App-v and UE-V:

Better Dynamic Application Delivery through UE-V & App-V

May 11, 2015

I’m Speaking at Ignite 2015

April 16, 2015

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

April 7, 2015