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

Advanced Connection Groups – The Sanity Check

Since the release of App-V 5.0, connection groups have been a highly rated feature of the release, it is something that brought about a whole new level of flexibility and manageability compared to dynamic suite composition in 4.x. However connection groups have evolved overtime and there are many nuances to behaviours depending on how they are used. This set of statements reflects the current state of play with the latest version (App-V 5.0 SP3) and I will update it should things change. I hope it serves as a quick sanity check and a guide when planning your connection group strategy…

The Sanity Check

1. Connection groups use two key files

Connection groups work off a template and effective .xml. The PackageGroupDescriptorTemplate.xml provides a structure to compose (template) and the PackageGroupDescriptor.xml is the current composed connection group (effective)

There is also a third file called UserPackageGroupDescriptor.xml which is generated when a connection group is published to the user and acts the same as the effective connection group descriptor but for the user

2. Connection groups can be published either globally or to user

This is achieved by using the -Global switch when running the Enable-AppvClientConnectionGroup cmdlet

3. Connection groups can contain a mixture of both user and globally targeted packages

This is done on a package level by adding the -Global switch when running the Publish-AppvClientPackage cmdlet

4. Connection groups targeted globally cannot contain any user targeted packages

If attempting to deliver a mixed scope connection group to the computer you will get the following event 1048 error:


5. Connection groups targeted at the user can contain both user and computer targeted packages

Mixed scope connection groups always need to be targeted at the user

6. Connection groups must have at least one mandatory package

There must be at least one mandatory package per connection group otherwise delivery will fail with the following event 8004 error:


7. Connection groups will fail to publish if a mandatory package is not published

Mandatory packages are required to be present in cache for a connection group to be published otherwise delivery will fail with the following event 8012 error:

8. Packages will fail to unpublish if they are a mandatory member of a published connection group

Packages must be detached from any connection groups for which they are mandatory members before they can be published otherwise the action will fail with the following event 1016 error:


9. Packages in a connection group set to use any version or set as optional will always use the latest version in cache when initially delivered

Regardless of whether a package is published, aslong as it is present in cache it will be generated into the effective connection group when the connection group is delivered. For regeneration behaviour after delivery of connection groups read the following:

10. Connection groups added or targeted globally will automatically be re-generated on add/remove of an eligible optional package

This can be found in %PROGRAMDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

11. Connection groups added or targeted globally will automatically be re-generated on add/remove of an eligible use any version package

This can be found in %PROGRAMDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

12. Connection groups enabled to the user will automatically be re-generated on publish/unpublish or remove of an eligible optional package

This can be found in %APPDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

13. Connection groups enabled to the user will automatically be re-generated on publish/unpublish or remove of an eligible use any version package

This can be found in %APPDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\

14. Connection groups can hold priorities which dictate how overlap conflicts are resolved at launch

This is handled by the Priority=”_” value within the effective .xml. More details on connection group conflicts can be read here

15. Packages within a connection group have priority over each other

This is dictated by the order in which the packages are listed in the connection group (highest priority first). Merged roots in SP3 now mean that conflicting paths will be merged however file conflicts will still be handled via the priority handler I.e file will be read from package with most priority where it can

16. Connection group priority, optional and use any version is not supported within SCCM 2012 native functionality

This applies when using the native ‘Virtual Environments’ functionality for connection groups within SCCM 2012 at this point in time

17. Connection groups can be enabled or disabled to a specific user by an administrator using PowerShell

This is achieved by using the -UserSID parameter when using the Enable-AppVClientConnectionGroup or Disable-AppVClientConnectionGroup cmdlet

18. Connection group members should all have the same settings for COM isolation/integration

By default all COM integration is set to isolated however if you have changed this in any of your member packages then it must be set consistently the same across all others. If not you will receive the following 20001 error and the connection group will not publish.


February 3, 2015

Issue with RequirePublishAsAdmin with SCCM 2012 and User Targeting

SP3 for App-V 5.0 introduced a new feature called RequirePublishAsAdmin which allows Administrators to restrict non-admins publishing packages to themselves if they are already added to the machine. For a full run down of this feature read here, it was on this post a commenter brought up the question of whether or not this feature would work with SCCM delivery (Thanks IV!), assuming it would work I thought I would test just to confirm however what I found is the commenters concerns were indeed justified….

The Error

Once RequirePublishAsAdmin is enabled and a non-admin user tries to take delivery of a user targeted App-V application the delivery fails and the following error occurs:



The Cause

The cause of this error is exactly as suspected by the commenter on my previous post, the PowerShell process running the publish command runs as th user and therefore is automatically blocked from running.

If we dig into the AppEnforce.log we find evidence of this:



Above you can see the first App-V command which is the Add operation runs with a PID 2916 and completes successfully with a return code of 0.

However the second command which is the Publish operation runs with a PID of 1572 and fails with a return code of 1.


A quick ProcMon shows us that as suspected PID 2916 (Add) runs as system and PID 1572 (Publish) runs as the user and therefore fails.


In summary the RequirePublishAsAdmin feature is not fully compatible with SCCM 2012 user targeted deliveries. I have tested the same scenario with App-V Server with no issues.

January 13, 2015

Running App-V 5.0 Commands on a Remote Machine with or without PSRemoting

Since the introduction of App-V 5.0 and the PowerShell commands which we have come to know and love there has always been the question around ways we can execute these commands remotely. As more and more organisations start to look at how they go about supporting their App-V environments and build up their own tooling, whether it be for desktop support activities or cache maintenance, the question about remote management arises.

Now the obvious answer for running PowerShell commands on a remote endpoint is enabling and leveraging PSRemoting however I have found certain organisations tend not to allow this feature to be enabled over security concerns. Lets take a look at the options either way:

With PSRemoting

PSRemoting is very powerful allowing us to run PowerShell commands on a remote machine as if it was being run locally. First thing to do is enable PSRemoting:

1. Enable PSRemoting

There are various ways to enable PSRemoting which basically needs the WinRM service, the easiest way to do it across multiple machines is via Group Policy:

Just open: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service 

Enable the Allow Remote Server management through WinRM policy setting.


Alternatively if you are just testing you can enable it on a particular machine using the Enable-PSRemoting cmdlet.


Click here to read more on TechNet about the Enable-PSRemoting cmdlet.

You can test connectivity from a remote machine using Test-WsMan COMPUTERNAME


Now all you need to do is run your commands!

2. Use PSRemoting

There are two main ways you can run your commands, either by issuing a single command or via an interactive PowerShell session.

To issue a command use the following syntax:

Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { COMMAND} -credential — USERNAME

For example here I have remotely removed a package from cache:


We can do the same thing from an interactive console if we wanted to run more than one command:

Enter-PSSession -ComputerName COMPUTERNAME -Credential — USERNAME


Above you can see how I am using an interactive session to interact with my remote client by querying a package and then removing it. To be honest this is just the tip of the iceberg, there is so much more you can do. I have seen some organisations write their own custom tools which use PSRemoting to enable them to support and maintain their environment. If your in the same position hopefully you can leverage the same techniques, better yet why not check out some of the toolsets already out there, my favourite is Bram Wolfs App-V Scheduler – which amongst other features includes much more user friendly way to query remote endpoints using its Central View console.

Without PSRemoting

So what if PSRemoting is disabled in your environment and restricted due to organisational policies? Well all is not lost! Recently someone from a large insurance company contacted me about this scenario and was kind of enough to share how they worked around not having PSRemoting enabled (Thanks Gyan!).

The workaround involves invoking PowerShell via WMI using the Create method of Win32_Process:

1. Assign to Variable

First thing we need to do is assign the WMI Class Win32_Process of the remote machine to a variable from our local machine:

$Process = [WMICLASS]”\\COMPUTERNAME\root\cimv2:Win32_Process”


2. Invoke Process

So now all we need to do is utilise the Create method of Win32_Process to invoke whatever we want. In this case we want to use PowerShell to remove a package from cache on a remote machine:

$Process.Create(“PowerShell.exe Remove-AppvClientPackage PACKAGENAME”)


What the above will go and do is go invoke PowerShell on the remote machine and run my specified command, so one minute I have my package and next minute it’s gone! The great thing about all this is it doesn’t need PSRemoting enabled as its all done over WMI. The not so great thing is the feedback, as you can see from above the returned information once issuing the command isn’t that meaningful.

We can however query WMI to find out if the package is there:

Get-Wmiobject -ComputerName COMPUTERNAME -NameSpace Root\APPV -Class AppvClientPackage | where-object {$_.Name -eq “PACKAGENAME”}


Above is the output you can expect when the package is present, you will get a null return if the package isn’t there. There is a lot more you can do with the WMI provider for App-V to query and execute commands however it probably just needs a bit more investment of time compared to using remote PowerShell.

So in summary if PSRemoting is enabled in your environment you can very easily begin to put together your remote support solutions or even look at some of the third party tools out there already. If PSRemoting is restricted in your environment then WMI is your answer, it may be a little harder to get familiar with but it does offer a lot of potential to act remotely.

January 8, 2015

Everything you need to know about App-V 5.0 SP3

App-V 5.0 SP3 is now available on MSDN as part of MDOP 2014 R2, there are some great features that you need to check out! Here are detailed posts detailing the key features of this release:

Connection Groups 2.0 – More Manageable & More Flexible

User RunVirtual Key

Merged Roots and PVAD changes

Require Admin for Publishing

– Advanced Connection Groups – The Sanity Check

You can download it as separate .ISO files or as part of MDOP 2014 R2:


Don’t get thrown off by the “Application Virtualization Hosting” – its just the desktop client, server and sequencer!

Check out Microsoft’s TechNet documentation on the release here.

Also check out Tim’s great breakdown of all the new features here.


December 4, 2014

RequirePublishAsAdmin in App-V 5.0 SP3

Right so pre SP3 for App-V 5.0, aslong as a package was added into the client cache, any user (admin or non admin) could go ahead and publish the application to themselves with a quick and easy line or PowerShell. There weren’t really many ways to negate this apart from custom ACLs on the package store or using a feature called PackageStoreAccessControl, a feature which has now been deprecated and is no longer supported.

Enter RequirePublishAsAdmin…

You might notice this new setting available on the App-V 5.0 SP3 client when running a Get-AppvClientConfiguration


You enable this setting with a simple Set-AppvClientConfiguration -RequirePublishAsAdmin 1

Once enabled exactly what you expect takes effect, the next time a non admin user logs on, even if a package has already been added to the client they lose the ability to publish packages to themselves. To understand more about the difference between adding and publishing read here.

Here we can see a standard user has visibility of the fact a package is in cache but not currently published to them:


If this non-admin user tries to publish this package they will get the following message warning them they need admin rights:


This is well welcomed feature, however there is no thing to note, unlike PackageStoreAccessControl, RequirePublishAsAdmin does not prevent a non admin user browsing the package store cache and reading the contents or even copying contents out. It does however stop a non admin gaining access to a package that has not been authorised to them.

December 4, 2014