App-V 5.0 Sequencing Advanced Techniques and Troubleshooting 20th-21st October 2015 London – East Central
App-V 5.0 Infrastructure Deployment, Administration and Management 22nd-23rd October 2015 London – East Central
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.
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.
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.
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
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.
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.
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.
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:
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:
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.
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
When you come to updating on the App-V Sequencer you have three different options:
Here’s a breakdown of the difference:
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).
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.
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:
– 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.
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:
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.
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 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:
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…
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
This is achieved by using the -Global switch when running the Enable-AppvClientConnectionGroup cmdlet
This is done on a package level by adding the -Global switch when running the Publish-AppvClientPackage cmdlet
If attempting to deliver a mixed scope connection group to the computer you will get the following event 1048 error:
Mixed scope connection groups always need to be targeted at the user
There must be at least one mandatory package per connection group otherwise delivery will fail with the following event 8004 error:
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:
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:
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:
This can be found in %PROGRAMDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\
This can be found in %PROGRAMDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\
This can be found in %APPDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\
This can be found in %APPDATA%\Microsoft\AppV\Client\Catalog\PackageGroups\
This is handled by the Priority=”_” value within the effective .xml. More details on connection group conflicts can be read here
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
This applies when using the native ‘Virtual Environments’ functionality for connection groups within SCCM 2012 at this point in time
This is achieved by using the -UserSID parameter when using the Enable-AppVClientConnectionGroup or Disable-AppVClientConnectionGroup cmdlet
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.
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….
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 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.