Appv Low Level Design

App-V 5
Low Level Design
Reference Architecture Specification
Version: 1.0
Date: 25th July 2014
Author(s): Mark Charles
Document Status: Draft
For further information please contact:

Name: Mark Charles
Email: mark.charles@db.com
Deutsche Bank
Deutsche Bank
This document is confidential and for internal use only. The information contained herein is the property of Deutsche Bank. This
document may not be copied, used or disclosed on whole or in part, stored in a retrieval system or transmitted in any form or by any
means (electronic, mechanical, reprographic, recording or otherwise) without the prior written permission of Deutsche Bank.
1
For internal use only
Document Control
Version Control
Version Number Author(s) Date Summary of Changes
1.0 Mark Charles Initial Draft
Change History
Version Number Author(s) Date Change Description
Circulation List
Name Title Section(s) Purpose Complete

Mark Homer Remote Desktop Engineering Head All Sign off
Nigel Montague Remote Desktop Engineering All Review
Tim Dixon Remote Desktop Engineering All Review
Document Sign Off
Name Title Date Signature
2
Table of Contents
1 Introduction .................................................................................................................................... 6
1.1 Background ............................................................................................................................. 7
1.2 Objective ................................................................................................................................. 7
1.3 High Level Requirements ........................................................................................................ 7
1.4 Scope ....................................................................................................................................... 7
2 Target Platforms ............................................................................................................................. 8
2.1 PCMODELTYPE ........................................................................................................................ 8
3 App-V 5 SP2 Client Configurations per Platform Type .................................................................... 9
3.1 App-V 5 SP2 Client Configuration Settings differences per platform. .................................... 9
3.2 Common App-V 5 SP2 Client Configuration Settings ............................................................ 10
3.3 AutoLoad Setting................................................................................................................... 11
3.4 PackageStoreAccessControl Setting...................................................................................... 11
4 App-V 5 SP2 Client Configuration - Group Policy Setting.............................................................. 12
4.1 MDOP ADMX Template......................................................................................................... 12
4.2 App-V 5 Client Configuration Group Policy Settings per PCMODELTYPE ............................. 13
5 ROFS Configuration for App-V 5.................................................................................................... 14
5.1 Package Streaming ................................................................................................................ 14
5.2 SMB Streaming Configuration............................................................................................... 14
5.3 HTTP Streaming Configuration.............................................................................................. 15
6 App-V 5 Sequencing ...................................................................................................................... 16
7 App-V 5 Powershell Modules and Cmdlets................................................................................... 17
7.1 The App-V AppVPkgConverter Module ................................................................................ 17
7.2 The App-V Client Module ...................................................................................................... 17
7.3 The App-V 5 Event Logging ................................................................................................... 18
8 App-V 5 – New Features ............................................................................................................... 19
3
8.1 App-V 5 OS Integration ......................................................................................................... 19
8.2 Dynamic Deployment Configuration..................................................................................... 23
9 App-V 5 – Connection Groups....................................................................................................... 31
9.1 Connection Group Descriptor XML ....................................................................................... 31
9.2 App-V 5 Connection Group Powershell Cmdlets .................................................................. 32
9.3 Areas to Consider .................................................................................................................. 33
10 App-V 5 – Roaming User Environments ........................................................................................ 36
10.1 Registry Based Data .............................................................................................................. 36
10.2 File Based Data ...................................................................................................................... 37
10.3 Package Catalogs................................................................................................................... 38
10.3.1 Machine Catalog ........................................................................................................... 38

10.3.2 User Catalog .................................................................................................................. 38
10.4 Windows 7 Platform Configuration ...................................................................................... 39
10.5 RDS Platform Configuration (AOD2 & DOD Lite) .................................................................. 40
11 App-V 5 – MC7 Delivery ................................................................................................................ 41
11.1 App-V 5 Package types .......................................................................................................... 41
12 MC7 Manifest Schema for App-V 5............................................................................................... 42
12.1 <appv> Section ...................................................................................................................... 42
12.3 Standard App-V 5 Package Artefacts .................................................................................... 44
12.4 <actions> Section .................................................................................................................. 45
12.5 <unlocktargets> and <locktargets> Sections ...................................................................... 49
13 Manifest Powershell Scripts for App-V 5 ...................................................................................... 50
13.1 DB_MC_Install_Action.ps1.................................................................................................... 50
13.2 DB_MC_Update_Action.ps1 ................................................................................................. 58
13.3 DB_MC_Unlock_Action.ps1 .................................................................................................. 66
13.4 DB_MC_Lock_Action.ps1 ...................................................................................................... 72
13.5 DB_MC_Repair_Action.ps1 ................................................................................................... 75
13.6 DB_MC_Uninstall_Action.ps1 ............................................................................................... 79
4
14 Managed Client Action flow diagrams .......................................................................................... 86
5
1 Introduction
The purpose of this document is to detail the design at a low level, of Microsoft’s latest Application
Virtualisation technology App-V 5 SP2 and its and implementation on Deutsche Bank platforms. We
currently use App-V 4.6 as an Application Packaging solution within Deutsche Bank. App-V 5 is a
major overhaul of this technology and as a result requires a newly engineered design.
6
1.1 Background
Microsoft released App-V 5 in November 2012. App-V releases via Microsoft Desktop Optimization
Pack (MDOP) for the desktop Operating Systems but also supports Remote Desktop Servers where
the client license is bundled in with the RDS CAL.
App-V 5 is a complete overhaul of the App-V product and has been written from the ground up.
There is a new format for the virtualised packages and a new client. As a result App-V 4 and app-V 5
do not understand each other therefore in essence we are dealing with more a migration rather
than an upgrade.
1.2 Objective
The objective of this design is to detail the required App-V 5 client & server configurations, engineer
installation scripts to integrate with the Managed Client (MC7) and to inform and detail how App-V 5
feature sets can be used from a Packaging/Sequencing perspective for use within Deutsche Bank.
1.3 High Level Requirements

At a high level this design must address the following requirements:
 Provide configurations for the App-V 5 SP2 Clients across all Deutsche Bank
platforms detailed later.
 Provide Server side (ROFS) configurations for optimized streaming of App-V 5
packages to the clients.
 Provide Group Policy Settings to enforce App-V Client configurations.
 Engineer Installation scripts written in Powershell to integrate with the Managed
Client in order to manage the delivery of packaged applications.
 Detail the App-V 5 feature sets and their usage from an Application Packaging
perspective.
1.4 Scope
The scope of this project applies to Prod, UAT and Dev environments across the following platforms.
 Desktops
 Laptops
 DesktopOnDemand (DOD)
 DOD Lite
 ApplicationsOnDemand 2 (AOD2)
 Blade Workstations
It applies to App-V 5 SP2 onwards and does not encompass the App-V 5 Application Packaging
Standards.
7
2 Target Platforms
2.1 PCMODELTYPE
As mentioned above, App-V 5 Clients and packages will have the following platforms in scope.
 Desktops
 Laptops
 DesktopOnDemand (DOD)
 DOD Lite
 ApplicationsOnDemand (AOD2)
 Blade Workstations
In order for the App-V 5 Client Installation and App-V 5 packages to identify these platforms the
PCMODELTYPE registry key will be interrogated.
HKEY_LOCAL_MACHINE\Software\Deutsche Bank\PCMODELTYPE
The following are the platforms that the various PCMODELTYPE values represent.
Platform PCMODELTYPE Value

Laptop NOTEBOOK
Physical Desktop DESKTOP
DOD VIRTUALDESKTOP
DOD Lite RDSDESKTOPS
AOD 2 RDSAPPLICATIONS
Blade Workstations BLADEWORKSTATION
The PCMODELTYPE Registry key will be written at build time and re-enforced by Group Policy.
It is vital that this key exists and is accurate as all installations are dependent on its existence.
8
3 App-V 5 SP2 Client Configurations per Platform Type
There are two released versions of the App-V 5 SP2 Client x64, one for desktops and one for RDS
platforms (AOD2 & DOD Lite). These are the client installations this design will be based on.
Each App-V 5 client installation will be installed using the setup.exe provided by Microsoft rather
than the extracted MSI owing to complications in applying hot fixes thereafter. Client configuration
settings will be passed to the setup.exe via the command line and alterations will be coded to
provide configuration variations where necessary based on the PCMODELTYPE.
The App-V 5 SP2 Client UI is now provided separately as an App-V 5 packages application. We will
however not be providing this UI in DB. All User interaction with the App-V 5 client will be via the
MC7 console only.
Note: The App-V Client configuration settings can be retrieved from the client machine by using the
Powershell App-V 5 cmdlet “Get-AppVClientConfiguration”
About Client Configuration Settings
3.1 App-V 5 SP2 Client Configuration Settings differences per platform.

The App-V Client configuration settings that will vary dependent on platform type are as follows.
1. “NOTEBOOK”
 AutoLoad = 2
 PackageInstallationRoot = %programdata%\App-V
2. “DESKTOP”
 AutoLoad = 2
3. “VIRTUALDESKTOP”
 AutoLoad = 0
4. “RDSDESKTOPS”
 AutoLoad = 0
 PackageInstallationRoot = E:\AppV5Cache
5. “RDSAPPLICATIONS”
 AutoLoad = 2
 PackageInstallationRoot = E:\AppV5Cache
6. “BLADEWORKSTATION”
 AutoLoad = 2
9
3.2 Common App-V 5 SP2 Client Configuration Settings
The App-V 5 SP2 client configuration settings that are common across all platform types are as
follows
 PackageSourceRoot =
 LocationProvider =
 EnablePackageScripts = 1
 RestablishmentInterval = 5
 RestablishmentRetries = 3
 CertFilterForClientSsl = “LOCAL_MACHINE\MY\1.3.6.1.5.5.7.3.2”
 VerifyCertificateRevocationList = 1
 MigrationMode = 1
 RoamingFileExclusions = “Downloads;Saved Games;AppData\Roaming\Juniper
Networks;AppData\Roaming\SoftGrid Client\Icon Cache;AppData\Roaming\Macromedia\Flash
Player”
 RoamingRegistryExclusions = “software\classes;software\Clients”
 AllowHighCostLaunch = 0
 PackageStoreAccessControl = 0
 IntegrationRootUser = “%LOCALAPPDATA%\Microsoft\AppV\Client\Integration”
 IntegrationRootGlobal = “%ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration”
 VirtualizableExtensions = “exe,com,bat,cmd,vbs,ps1,cpl,jar,wsf,wsh,msc”
 ReportingEnabled = 0
 ReportingStartTime =
 ReportingRandomDelay =
 ReportingInterval =
 ReportingserverURL =
 ReportingDataCacheLimit =
 ReportingdataBlockSize =
 ExperienceImprovementOptIn = 0
 EnablePublishingRefreshUX =
 ProcessesUsingVirtualComponents = {%SystemRoot%\explorer.exe, %ProgramFiles%\Internet
Explorer\iexplore.exe, %ProgramFiles(x86)%\Internet Explorer\iexplore.exe}
Design Decision: The use of SharedContentStoreMode was considered for the DOD, DOD
Lite platforms. Extensive testing was carried out to determine its suitability. It was
decided that in the absence of a large scale pilot, there were too many unknowns in
terms of the potential impact on the ROFS infrastructure and the Network. It is it
however an area we would like to explore in the future and can be easily re-configured
on the client via group policy. Shared Content Store in Microsoft App-V 5.0
10
3.3 AutoLoad Setting
The AUTOLOAD setting defines how and when an App-V 5 package is streamed into the local cache
on the client. Laptops, Desktops, Bladeworkstations and AOD2 platforms will have the entire
package cached at App-V Publishing time (MC7 Install Action for AOD2 and the Unlock Action for all
platforms). Virtual Desktops and DOD Lite will ‘fault stream’ the package components during
application use by the Users. AutoLoad Setting in App-V 5.0
3.4 PackageStoreAccessControl Setting

PackageStoreAccessControl is a new App-V 5 Client configuration setting introduced in the SP2
release. The PackageInstallationRoot or the package cache location typically exists in the following
location “%programdata%\App-V\[PackageID]\[VersionID]”.
The default permissions for Users set on this directory is read access for “Everyone”. By enabling the
PackageStoreAccessControl setting, read access is only assigned to Users who have the package
Published (MC7 Unlocked) to them.
It is advised that this setting be added to the ADMX template and used across all platforms.
PackageStoreAccessControl - Restricting Access to the Package Cache in App-V 5.0
UPDATE: Following our testing we exposed issues with this feature and raised a case with Microsoft.
They confirmed our findings and as a result have deprecated the feature.
http://support.microsoft.com/kb/2963211
Without this PSAC there is an element of risk that a user who is not entitled to an application would
be able to browse to package cache directory and launch an application executable directly from
there. We believe the risk is minimal for the following reasons.
1. Workstations are typically used by a single user and a package will not be in cache unless it
was installed/entitled to that user.
2. It unlikely an un-entitled user would locate these folders.
3. Even if an un-entitled user did locate a cached package it is unlikely that the application
executable will work as the package has not been published or integrated for that user. E.g.
no FTA, COM, Shell integration, App paths registration etc and if the package is a connection
group member it will not be enabled for that user preventing the application from seeing its
other members.
11
4 App-V 5 SP2 Client Configuration - Group Policy Setting
The App-V 5 SP2 Client packages will set the client configuration settings at Install time. Re-
enforcement of some of these settings is advised via by group policy.
4.1 MDOP ADMX Template

Microsoft has provided an ADMX Group Policy template v2.0 for the purpose of creating the App-V 5
policy settings.
ADMX templates for MDOP products - UE-V and App-V
How to Modify Client Configuration Using the ADMX Template and Group Policy
The following group policy settings can be configured for App-V 5 using the template
 Microsoft Customer Experience Improvement Program
 Client Co-Existence (Enable Migration Mode)
 Integration & Exclusions
 Publishing server settings
 Reporting server settings
 Enable package scripts
 Streaming configuration settings
 Virtualization settings
It is advised that at least the following settings be set. Some may vary dependent on the Platform
type (PCMODELTYPE) as detailed earlier therefore different templates may need to be applied to the
appropriate OU’s.
1. PackageSourceRoot - This will be defined at package installation time therefore this must be not
be set.
2. PackageInstallationRoot – This will vary with PCMODELTYPE
3. EnablePackageScripts = 1
4. MigrationMode = 1
5. SharedContentStoreMode = 0
6. Autoload - This will vary with PCMODELTYPE
12
Following testing we discovered that there is an issue with the above ADMX template (v2.0)
regarding the display of “Virtual Component Process Whitelist” Group Policy object.
We raised a case with Microsoft and the solution they provided was to modify the ADMX file by
deleting the highlighted line below.
</policy>
<policy name="Virtualization_JITVWhitelist" class="Machine"
displayName="$(string.Virtualization_JITVWhitelist)"
explainText="$(string.Virtualization_JITVWhitelist_Help)"
presentation="$(presentation.Virtualization_JITVWhitelist)"
key="SOFTWARE\Policies\Microsoft\AppV\Client\Virtualization"
valueName="ProcessesUsingVirtualComponents">
<parentCategory ref="CAT_Virtualization" />
<supportedOn ref="windows:SUPPORTED_Windows7" />
<elements>
<multiText id="Virtualization_JITVWhitelist_Prompt" valueName="ProcessesUsingVirtualComponents" />
</elements>
</policy>
4.2 App-V 5 Client Configuration Group Policy Settings per PCMODELTYPE

See “Appv5_ClientConfig_Group_Policy_Settings.xlsx” for full list of App-V 5 client configuration
group policy setting.
13
5 ROFS Configuration for App-V 5
5.1 Package Streaming

Deutsche Bank will configure the App-V 5 clients in Stand-alone mode as it does today with App-V 4.
i.e. We will not be using the App-V Full infrastructure model or SCCM to deploy/publish packages.
We will also avail of the ROFS infrastructure to act as the App-V 5 content share for packaged
sequences.
Our intention originally was to use the same protocol for streaming App-V5 packages as we use with
App-V4 packages today namely HTTP.
Following testing we discovered unexpected excessive data transfer over the network between the
ROFS and the client during 1st launching of our test applications. We subsequently raised a case with
Microsoft following which they conceded that there was an overhead with HTTP streaming and that
they would now recommend SMB streaming over HTTP.
5.2 SMB Streaming Configuration

Packages will be streamed from the content share using the SMB protocol by default.
There are no new configurations required on the ROFS servers to enable SMB streaming of App-V5
packages.
However as MC7 on the client cannot currently distinguish between App-V 4 & 5 packages, we
needed to provide a solution for App-V5 to stream via SMB whilst allowing App-V4 to continue to
use HTTP.
This solution involves the addition of a registry key called "Appv5StreamingProtocol" = "SMB" or
"HTTP" under
 HKLM\Software\Policies\MC7\mcADA\GARs\Primary and Secondary
This key will be set at build time and reinforced by group policy.
14
Our App-V5 installation scripts then read this key to determine the protocol and then build the path
to the .appv package file on the ROFS with the help of the MC7 hardpath or APPVURL key depending
on the protocol specified.
5.3 HTTP Streaming Configuration

The ability to stream via HTTP is natively built-in to the App-V 5 client so no special configuration is
required there.
However on the ROFS servers there are some configurations that should be applied.
5.3.1 Mime Type
The MIME type for the .appv file extension should be configured in Internet Information Services
(IIS) on the ROFS Server.
1. Open the Internet Information Services (IIS) Manager

2. Select the (Default) Web Site
3. Click on IIS \ MIME Types
4. Click on Add
5. File name extension: .appv
6. MIME type: application/appv
5.3.2 IIS Package Caching
Microsoft IIS has a number of built-in caching mechanisms to accelerate the delivery of web content.
It is advised that the server team looks into the possibility of tuning the IIS settings to enable App-V 5
packages to be avail of the File Cache Memory.
Microsoft App-V 5.0 – Streaming via HTTP
15
6 App-V 5 Sequencing
Detailed documentation of the App-V 5 sequencing procedure will be outlined in a separate
document but the primary change from App-V 4 sequencing is that all packages, regardless of the
expected target platform, should be optimized for Streaming in the following manner.
In the ‘Prepare for Streaming’ dialog, the “Run Selected” option should not normally be executed to
create Feature blocks in the sequence and the check-box to ‘Force Applications to Fully Downloaded’
should remain Un-checked.
The Streaming behaviour will be subsequently managed by the App-V 5 Client ‘Autoload’
configuration which is set depending on the PCMODELTYPE as explained earlier.
Click ‘Next’ and the following dialog will appear.
Important changes in the App-V v5 Sequencer
16
7 App-V 5 Powershell Modules and Cmdlets
Microsoft App-V 5.0 marked the introduction of Powershell (v3.0) as a means to Sequence and
administer a vast array of tasks, all while leveraging the support of .NET’s extensive libraries.
7.1 The App-V AppVPkgConverter Module

The AppVPkgConverter powershell module is installed with the App-V 5 Sequencer. It contains two
cmdlets which can be used to convert App-V 4.6 packages to App-V 5. You must run the 32bit
version of Powershell console to expose this module and its cmdlets.
1. Cmdlet ConvertFrom-AppvLegacyPackage
2. Cmdlet Test-AppvLegacyPackage
Note there are some limitations to the ability of ConvertFrom-AppvLegacyPackage cmdlet to

successfully convert a package to App-V 5. Highly customized App-V 4 packages (OSD
customizations, scripts, dependencies) do not convert well with the converter. The Test-
AppvLegacyPackage cmdlet is designed to expose these deficiencies.
Known issues when using App-V v5 Package Converter
It is therefore advised that in Deutsche Bank new App-V 5 packages be sequenced from the Source
media where possible.
7.2 The App-V Client Module

The AppVClient Powershell module is delivered with the App-V 5 Client installation. Many of these
cmdlets will be used to deliver and configure App-V 5 packages in conjunction with the Managed
Client (MC7) manifest actions.
Many will also be useful to the Packager/Sequencer and potentially Desktop Support teams to test
and troubleshoot package installations.
1. Function Get-AppvVirtualProcess
2. Function Start-AppvVirtualProcess
3. Cmdlet Add-AppvClientConnectionGroup
4. Cmdlet Add-AppvClientPackage
5. Cmdlet Add-AppvPublishingServer
6. Cmdlet Disable-AppvClientConnectionGroup
7. Cmdlet Enable-AppvClientConnectionGroup
8. Cmdlet Get-AppvClientApplication
9. Cmdlet Get-AppvClientConfiguration
10. Cmdlet Get-AppvClientConnectionGroup
11. Cmdlet Get-AppvClientMode
12. Cmdlet Get-AppvClientPackage
13. Cmdlet Get-AppvPublishingServer
14. Cmdlet Mount-AppvClientConnectionGroup
15. Cmdlet Mount-AppvClientPackage
17
16. Cmdlet Publish-AppvClientPackage
17. Cmdlet Remove-AppvClientConnectionGroup
18. Cmdlet Remove-AppvClientPackage
19. Cmdlet Remove-AppvPublishingServer
20. Cmdlet Repair-AppvClientConnectionGroup
21. Cmdlet Repair-AppvClientPackage
22. Cmdlet Send-AppvClientReport
23. Cmdlet Set-AppvClientConfiguration
24. Cmdlet Set-AppvClientMode
25. Cmdlet Set-AppvClientPackage
26. Cmdlet Set-AppvPublishingServer
27. Cmdlet Stop-AppvClientConnectionGroup
28. Cmdlet Stop-AppvClientPackage
29. Cmdlet Sync-AppvPublishingServer
30. Cmdlet Unpublish-AppvClientPackage
7.3 The App-V 5 Event Logging

App-V 5 now writes its logs to the Event Viewer under “Applications and Services Logs”
The Secret App-V 5 Client Debug Logs
18
8 App-V 5 – New Features
App-V 5 has changed dramatically from App-V 4.6. It has been redeveloped from the ground up and
as a result there are many new features and changes.
Here we will identify the most important and explain their uses.
8.1 App-V 5 OS Integration

8.1.1 Package Format
The sequenced package components have changed. There is essentially only one file
required to deploy and publish our App-V 5 packaged application which is the .APPV file.
Dynamic Deployment Configuration .XML files are created as part of the sequencing process
but are not used unless specified in the Install/Publishing Powershell command lines. The
.APPV file can be renamed as .ZIP in order to reveal its components.
App-V 5.0 OS Integration – Package Format
8.1.2 File System Cache
App-V 5 packages now cache to the file system in a flat file structure typically under
 %ProgramData%\App-V\[PackageId]\[VersionId] (on Win7)

 E:\AppV5Cache\[PackageId]\[VersionId] (on DB RDS Platforms)
This provides greater transparency when compared to the App-V 4 file system cache
previously held in the .FSD file. The Application executables are now called directly.
App-V 5.0 OS Integration – File System Cache
8.1.3 Registry
The package registry information is held within the Registry.dat file found in the .APPV file. It
can be mounted in the Registry editor to reveal its settings.
App-V 5 packages when Added/Published to the client, store this registration in the
following locations
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages\[PackageId]
 HKEY_CURRENT_USER\SOFTWARE\Microsoft\AppV\Client\Packages\[PackageId]
App-V 5.0 OS Integration – Registry
8.1.4 State Changes
In App-V 5, User Profile file based changes are stored in the following location
 %APPDATA%\Microsoft\AppV\Client\VFS\[PackageId]
Here we find a list of all our packages in GUID based folders.
19
These changes will roam with the Users profile.
App-V 5.0 OS Integration – State Changes
Global file state changes are saved to the following location
 %LOCALAPPDATA%\Microsoft\AppV\Client\VFS\[PackageId]
These changes are machine based and will not be roamed with the User.
Global File State Changes in App-V 5.0
8.1.5 Shell Extensions & ActiveX Controls
With the introduction of App-V 5 SP2, the following list of Shell extensions are now fully
supported.
 Context menu handler

 Drag-and-drop handler
 Drop target handler
 Data object handler
 Property sheet handler
 Infotip handler
 Column handler
These extensions are captured within the AppxManifest.xml during sequencing.
ActiveX controls are now also registered and supported via the AppxManifest.xml. The
implementation is limited by the fact that the package must be globally published similar to
the RunVirtual solution outlined below.
Shell Extensions and Runtimes with App-V 5.0 SP2
8.1.6 Running Local Processes in a Virtual Environment
There are two principle methods of executing a local process such as iexplore.exe inside the
virtual environment of a package or connection group.
 RunVirtual
 /APPVVE: Switch
8.1.6.1 RunVirtual
RunVirtual is a way for the App-V 5 client to detect a particular local process and use it as a
trigger to launch it within the virtual environment of a specified App-V package.
It is potentially a solution for say, Internet Explorer and the sequencing of IE Plugins and
similarly for locally installed MS Office and virtualised Add-ins.
20
An important limitation is that the App-V 5 packages must be globally installed. As a result it
may only be suitable on the AOD2 (RDSAPPLICATIONS) platform or in a very controlled and
managed delivery to the other platforms. There would also be licensing considerations to
global installations.
Another limitation is that you can only list one virtual package against the native process.
You can however create a Connection Group of packages and access this group via the ID’s
of one member.
The Process keys are listed under
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual
RunVirtual End to End
8.1.6.2 /APPVVE: Switch

Another method of executing a local process in a packages virtual environment is to use the
/APPVE: Switch. You can create a sequence to deliver this shortcut or you could possibly
modify a locally installed shortcut. The format is as follows
 {Process Name} /appvve:{PackageId}_{VersionId}
Or for a Connection Group
 {Process Name} /appvve:{GroupId}_{VersionId}
e.g.
"C:\Program Files (x86)\Internet Explorer\iexplore.exe" /appvve:b0ae2cb1-9f42-4d80-b50a-

0f55cad39127_4c1ebc0b-eef8-4438-99ab-ec3f88fcd785
Unlike the RunVirtual keys this method can use the Connection Group Id’s to enter the
virtual environment of a Connection Group. It also does not require the package/Connection
Group members to be published globally.
8.1.7 Runtime Dependencies
The App-V 5 SP2 update also introduced the ability to automatically package and deploy SxS
Assemblies. These are most commonly in the form of Microsoft Visual C++ Runtime
dependencies and MSXML.
21
These runtime files are automatically detected regardless of whether they are already on the
sequencing machine or not, this is achieved by scanning the executable for any
dependencies. On the client side during package installation, the App-V 5 client will check for
the presence of the required SxS and if it is not there it will be automatically installed.
You can review captured dependencies after sequencing within the report.xml file:
Shell Extensions and Runtimes with App-V 5.0 SP2
22
8.1.8 Primary Virtual Application Directory (PVAD)
The PVAD is the location you tell the sequencer you are intending to install your application. This
then becomes your root directory. Everything written outside this location is located under the VFS.
Understanding the PVAD
8.1.9 Package Permissions
In summary, by default all files and folders sequenced under the PVAD are permissioned with write
access for both admin and non-admin Users whereas the VFS is permissioned with write access for
admin users only (with the exception of user profiled locations which standard users will have write
access ). These settings may become an issue where poorly coded applications at run-time need to
write to a location other than the PVAD.
Permissions in the PVAD and VFS with App-V 5.0
UPDATE: Full VFS Write Mode: Hotfix Package 4 for Application Virtualization 5.0 SP2 contains a new
sequencer setting that, when applied to a package, provisions the package with write access to any
files and folders in the virtual environment (VFS).
Hotfix Package 4 for Microsoft Application Virtualization 5.0 SP2
8.2 Dynamic Deployment Configuration

It is expected that in Deutsche Bank, the use cases for Dynamic Deployment Configuration will be
minimal as the Managed Client (MC7) provides a wide range of functionality to assist in configuring
the packaged application post sequencing. The intention is that Dynamic Deployment Configuration
will provide an additional set of tools available to the Packager if the desired
functionality/configurations cannot be achieved using MC7.
8.2.1 OS Integration
App-V 5.0 “isolates” virtual applications from the operating system and other processes. This is done
by hiding the application resources from everything else. One can imagine this as running the virtual
application in a bubble that isolates the application from the outside world.
23
Integration, on the other hand, can be thought of as tunnels punching through this bubble, exposing
the virtual application capabilities to the native operating system and to the user in a controlled
manner. This enables virtual applications to behave as native applications. Think about a shortcut of
a virtual application residing on the user’s desktop. This shortcut is outside the virtual bubble and is
not isolated since it is on user’s desktop. But this shortcut enables the user to launch the virtual
application seamlessly as if it was a native application. This shortcut feature and some others make
up the Integration component of App-V.
Integration is a collection of subsystems that individually handle one specific integration area. The
following is the list of integration subsystems currently available in App-V product:
 Shortcut Subsystem
 FTA Subsystem
 COM Subsystem
 Software Clients Subsystem
 Application Capabilities Subsystem
 URL Protocol Handler Subsystem
 App Path Subsystem
 Virtual Applications Subsystem
8.2.2 Extension Points
An extension point is a single integration unit such as a shortcut of a virtual application. Each
integration subsystem can have one or more extension points (EPs). An example would be a virtual
package having multiple shortcuts.
8.2.3 Dynamic Configuration Files
App-V uses dynamic configuration files to provide customizations to the virtual package post
sequencing since the package (.appv file) itself is not editable. These configuration files can be used
to alter behavior of integration subsystems such as adding or editing a new shortcut.
These configuration files can be used to:
 Enable or disable integration subsystems. When a subsystem is disabled, its EPs will not be
integrated
 Provide extra configuration for integration subsystems
 Replace EPs of subsystems
24
There are two types of configuration files:
1. Dynamic Deployment Configuration (DDC)
 Configure the package for global publishing or user publishing on that machine
o E.g. add a new shortcut for all users that get the package
2. Dynamic User Configuration (DUC)
 Configure the package for an individual user
o E.g. add a new shortcut specific to the user to whom the package is being
published
 If a Dynamic Deployment Configuration (DDC) exist for the package, DUC replaces “User
Configuration” section during integration
During sequencing, the sequencer captures all the extension information it can handle and places it
in the AppxManifest.xml file which is located inside the .appv file. The App-V Sequencer generates
sample DUC and DDC files for each package to ease creation or modification of these xml
documents. It uses EPs from the package manifest (AppxManifest.xml) to pre-populate them. The
DynamicConfig.xml or UserConfig.xml files are not actually used unless explicitly specified on the
command line for the Addition or Publishing of a package.
E.g. Add-AppvClientPackage –Path <path to .appv file> –DynamicDeploymentConfiguration

{Path to [PackageName]_DynamicConfig.xml}
E.g. Publish-AppvClientPackage –Path {path to .appv file} –DynamicUserConfigurationPath

{Path to [PackageName]_UserConfig.xml}
Important: When a configuration file includes EPs of a subsystem, these extensions will replace all
EPs defined in the package manifest (AppXmanifest.xml). To edit or remove a single EP (e.g. a
shortcut), all the EPs belonging to that subsystem should be copied first from the AppXmanifest and
the EP in question edited or removed from the DDC/DUC xml file.
Issues can also arise when subsystems enablement/disablement differ between the members of a
connection groups. It is therefore important that the subsystems settings match across all
connection group member packages.
Design Decision
We will not be using Dynamic User Configuration (DUC) in Deutsche Bank. You cannot use DUC
with globally published packages (i.e. AOD2/RDSAPPLICATIONS) thus compromising our goal of
using one package for all our target platforms.
It is our belief DDC will provide all the functionality we may need to post configure a sequence. 25
8.2.4 Publishing
During publishing of an App-V package, Integration reads extension points from the package
manifest (AppxManifest.xml), dynamic deployment configuration and dynamic user configuration
files (if these configuration files are provided via parameters). Integration then merges EPs from all
these sources and finally integrates these EPs to the native operating system.
8.2.5 Example Integration Scenarios
Let’s examine the example scenarios below using sample files to understand what happens during
publishing. First, let’s introduce sample files:
26
When a package is published to a User
 If no DDC or DUC provided during publishing, Shortcut 1 and Shortcut 2 are integrated
 If DDC is provided, only Shortcut 3 is integrated
 If DUC is provided, only Shortcut 4 is integrated
 If both DDC and DUC are provided, only Shortcut 4 is integrated
When a package is published globally (Note: with global publishing a DUC cannot be provided)
 If no DDC provided during publishing, Shortcut 1 and Shortcut 2 are integrated

 If DDC is provided, only Shortcut 3 is integrated
27
8.2.6 App-V Client Powershell Cmdlets and Integration
Below are the PowerShell cmdlets that are relevant to integration.
 Add-AppVClientPackage <path to package> [- DynamicDeploymentConfiguration <path to

file>]
o No integration of the extension points from the package is done during an Add-
Package
o Dynamic Deployment Configuration is optional
 Publish-AppVClientPackage [- DynamicUserConfigurationPath <path to file>] [-Global]
o Package gets integrated
o Dynamic User Configuration is optional
o If Dynamic Deployment Configuration was provided to Add-AppvClientPackage,
and/or Dynamic User Configuration is provided to Publish-AppvClientPackage, they
will be used during integration
o Note: as already stated, we will not be supporting the use of DUC.
 Unpublish-AppVClientPackage [-Global]
o Package gets de-integrated
o If Dynamic Deployment Configuration and/or Dynamic User Configuration was
provided, they will be used during de-integration
 Remove-AppVClientPackage
o If package is published globally: The package gets de-integrated immediately if not
de-integrated before (by an Unpublish-AppVClientPackage)
o If package is published for User: The package gets de-integrated immediately if the
user is logged on or next time the user logs on
 Repair-AppVClientPackage [- Extensions] [-Global]
o If “Extensions” flag is provided, or if “-UserState” is not provided, the package gets
re-integrated, effectively repairing all extension points
8.2.7 Dynamic Configuration – Scripting
Dynamic Configuration allows you to specify a policy for a package at either the machine level or at
the user level. So with the dynamic configuration xml files you can control the execution whether
you want to run a script at a machine level or at a user level. Also, you can run scripts at various
execution times of the package lifecycle.
The ability to execute scripts in the DDC will be essential in Deutsche bank in order to invoke the
Managed Clients Package Regionalisation utility for example.
Below is a table that helps describe the various script events and when and how they can execute.
28
More detailed information on Dynamic Deployment Configuration Scripting and how to implement it
can be found here.
Scripting and Embedded Scripting for AppV 5.0
App-V5 scripting changes
Much of the complexity associated with packaging scripts in App-V 5 come with improper placement
in deployment and dynamic configuration files and how they are targeted. Scripts that need to be
called during package add and global publishing events should be part of the DeploymentConfig.XML
file. These scripts will also run in the context of the local system account so scripts that map drives,
for example, should not go here. Those need to be called as a <UserScript> element. The following
visual workflow will help to determine targeting and publishing.
29
In the case of global publishing, the deployment configuration also has a UserConfiguration element
in addition to MachineConfiguration which means that scripts appearing during these events will
apply to all users when the package is published globally. This would be the appropriate place to
have scripts which for example map network drives.
As already stated we will not be supporting DUC in Deutsche Bank therefore the events in green
from the table above are not supported.
App-V 4 allowed for the execution of scripts and these were detailed on the OSD file. These scripts
were subsequently executed at application launch time (pre or post). It is expected that for App-V 5
the sequencer will normally execute scripts on the same event (Script Type =
“StartVirtualEnvironment”) but this will remain at the discretion of the Packager taking into account
what it is they are trying to achieve and the potential impact of placing the script in a particular
event.
30
9 App-V 5 – Connection Groups
Connection Groups group one or more APP-V 5 packages to enable member applications in these
packages to interact with one another while maintaining isolation from the rest of the system. This
gives the Packager the flexibility to maintain packages independently and removes the redundancy
of adding the same application several times onto a machine.
Connection groups can be managed using the APP-V management/publishing servers on a Full
Infrastructure Modeled environment or in our case on a Standalone environment using App-V 5
Powershell cmdlets on the Client machine. Providing a working solution for connection groups
proved very complex and a lot of time was spent arriving at the resultant solution.
Design Decision
Because we are in effect running a stand-alone app-v environment we do not have the benefit
of app-v management & publishing servers to centrally manage the creation and publishing of
connection groups.
We considered the idea of creating separate packages to create connection groups but this
was discounted. In the end we agreed the best solution available to us was to have a CG
Parent package define the details of a CG within its package manifest.xml and rely on our
installation scripts to dynamically manage the creation of the CG on the client.
9.1 Connection Group Descriptor XML

A Connection Group is defined on the Client machine running the App-V 5 client using an XML
document called the Connection Group Descriptor file.
The following is a sample section of this file.
31
The configurable components are
1. AppConnectionGroupId - This is the unique GUID identifier for this connection group. The
connection group state is associated with this identifier. You will only specify this identifier
when you create the connection group. You can create a new GUID using Powershell by
typing: [Guid]::NewGuid(). This ID will be defined within the parent package manifest.xml.
2. VersionId - This is the version GUID identifier for this version of the connection group. When
you update a connection group, for example by adding a new package or when a package is
updated, a new version GUID will be created. This will be dynamically created by our
installation scripts.
3. Priority - This is the priority field for the connection group. The lower the number the higher
the priority. This will be dynamically created by our installation scripts.
4. DisplayName - This is the display name of the connection group. This will be dynamically
created by our installation scripts.
5. Package Members – each package member is listed with the following information
a) DisplayName
b) PackageId
c) VersionId
These members will be defined in the Parent package manifest.xml and dynamically
created by our installation scripts.
9.2 App-V 5 Connection Group Powershell Cmdlets

The available App-V 5 SP2 Client Connection Group cmdlets are as follows.
Example command line format to Add and Enable a Connection Group
 Add-AppvClientConnectionGroup –Path {Path to Descriptor XML}

 Enable- AppvClientConnectionGroup –GroupId {GUID} –VersionId {GUID} [-Global]
The available attributes for a connection group retrievable using the Get-
AppVClientConnectionGroup cmdlet are as follows.
32
9.3 Areas to Consider
There are a number of important areas that require consideration when dealing with Connection
Groups.
9.3.1 Virtual Environment (VE)
Once a Connection Group is enabled, applications from the packages forming this Connection Group
are launched in the Virtual Environment of the Connection Group. The VE of the Connection Group is
identified by the Group ID and the Group Version ID. This is quite different when compared to App-V
4 where a dependent package was streamed into the VE of the Parent, identified by the Dynamic
Suite Composition (DSC) link in the parents .OSD file.
9.3.2 Connection Group Priority
Packages can exist in multiple connection groups. The VE that an application from such a package
launches into is determined by the priority specified in the connection group descriptor document.
Connection Group priority is identified by the “Priority” attribute of the “AppConnectionGroup”
element in the Connection Group Descriptor document.
If an application is launched from within a package that is a member of more than one Connection
Group and the priorities of these connection groups do not differ, then the application will error on
launch. It was therefore necessary for the logic in our installation scripts to handle this possibility
during the creation of the connection group.
9.3.3 Launch Order
A virtual application is launched in the VE of the connection group it belongs to, even when the
parent process is a virtual process belonging to a different connection group or package. When the
package belongs to multiple connection groups, the app is launched in the connection group with
the lower number for priority.
33
9.3.4 User Settings
User settings from member packages will not be propagated to Connection Groups when a package
is added to a Connection Group. Similarly, once the Connection Group is disabled, user settings from
the Connection Group will not be propagated to the member packages.
Similar to Package setting detailed earlier, User profile file setting for a Connection Group are stored
under
 %APPDATA%\Microsoft\AppV\Client\VFS\[GroupId]
Non-User Profile file based state changes are saved to the following location
 %LOCALAPPDATA%\Microsoft\AppV\Client\VFS\[GroupId]
Connection Group registration is stored in the following locations
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\PackagesGroups\[GroupId]
 HKEY_CURRENT_USER\SOFTWARE\Microsoft\AppV\Client\PackagesGroups\[GroupId]
Note, as with Package settings, the VersionId GUID is not used to identify settings. This allows for
User setting to be retained when a Connection Group is Minor updated.
This also allows for these settings to successfully roam as the GroupId is defined within the Parent
package manifest and therefore will be the same on all machines the package is installed.
9.3.5 Order of Packages in a Connection Group
The order in which the Connection Group member packages are listed in the descriptor XML
document dictates how the member packages are merged when combined into the Connection
group virtual environment. The first listed package has precedence over the second and so on.
Our solution sets the Connection group parent package as the first Package and the subsequent
merge order of the other member packages is defined within the manifest.xml by ascending ordinal
number as detailed further on.
Consider a Connection Group MyConnectionGroup with 2 Packages: Package1 and Package2 in that
order.
Registry Merge
Consider Value “Bar” under key “HKCU\Software\Foo”.
Package1 has “Bar” with REG_SZ value data: “Package1_Data”
Package2 has “Bar” with REG_DWORD value data: 12345
34
The registry data for the group MyConnectionGroup will have “Bar” with REG_SZ value data:
“Package1_Data” as Package1 has precedence in the merge.
File System Merge
Note: Only fully VFS’ed files are merged for Connection Groups. These include all files under
Root\VFS in the sequenced package directory.
Package1 has:
Root\Foo\Foo.exe
Root\VFS\Bar\Bar.exe
Package2 has:
Root\Foo\Foo.txt
Root\VFS\Bar\Bar.txt
In this case, contents of Root\VFS will be merged, contents of Root\Foo will NOT therefore
- If Foo.exe were to access Foo.txt using relative path (.\Foo.txt), it would NOT find it.
- If Bar.exe were to access Bar.txt using relative path (.\Bar.txt), it would be found.
The Connection Group Descriptor XML contents for the above example.
Connection Groups Internals (App-V 5.0)
35
10 App-V 5 – Roaming User Environments
App-V 5 profile management and storage locations have changed significantly from App-V 4. It is
now arguably more complex but certainly more transparent. No longer do we have .fsd and .pkg files
storing our cached packages and user data.
App-V 5 is able to provide a near-native experience when roaming, depending on how the
application being used is written. By default, App-V will roam AppData stored in the roaming
location, based on the roaming configuration of the operating system. Other locations for storage of
file-based data do not roam from machine to machine, since they are in locations that are not
roamed.
10.1 Registry Based Data

App-V registry roaming falls into two scenarios; applications executed as standard users, and
applications executed with elevation.
In the first scenario, when a standard user launches an App-V 5 application, both HKLM and HKCU
for App-V applications are stored in the HKCU hive on the machine. This presents as two distinct
paths:
HKLM:
HKCU\SOFTWARE\Classes\AppV\Client\Packages\{PkgGUID}\REGISTRY\MACHINE\SOFTWARE
HKCU:
HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\{PkgGUID}\REGISTRY\USER\{UserSID}\SOFTWA
RE
The locations are enabled for roaming based on the operating system settings.
For the second scenario, where an application is launched with elevation, the HKLM data is stored in
the HKLM hive on the local machine and HKCU data is stored in the User Registry location. This
eliminates these settings from being roamed with normal operating system roaming configurations,
and the resultant registry keys and values are stored in the following location:
HKLM:
HKLM\SOFTWARE\Microsoft\AppV\Client\Packages\{PkgGUID}\{UserSID}\REGISTRY\MACHINE\SOF
TWARE
HKCU:
HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\{PkgGUID}\Registry\User\{UserSID}\SOFTWARE
36
10.2 File Based Data
A typical package has several locations mapped in the users backing store for settings in both
“AppData\Local” and “AppData\Roaming”. These locations are the Copy on Write locations (COW)
that are used to store changes made to the package VFS directories and protecting the default
package VFS and stored per user in the user’s profile. The table below shows locations, both local
and roaming.
App-V5 VFS File locations
The following table provides a detailed list of locations where App-V 5 stores its data.
App-V5 File locations
37
10.3 Package Catalogs
The App-V Client manages the following two file-based locations:
 Catalogs (user and machine).
 Registry locations, depending on how the package is targeted for publishing. There is
a Catalog (data store) for the computer and one for each individual user. The
Machine Catalog stores global information applicable to all users or any user, and
the User Catalog stores information applicable to a specific user. The Catalog is a
collection of Dynamic Configurations and manifest files; there is discrete data both
file and registry per package version.
10.3.1 Machine Catalog

The machine catalog is stored in %ProgramData% by default, but is not the same location as the
Package Store. The Package Store is the golden or pristine copy of the package files. The machine
catalog is located by default at %programdata%\Microsoft\AppV\Client\Catalog\ and will include the
following files:
 Manifest.xml
 DeploymentConfiguration.xml
 UserManifest.xml (Globally Published Package i.e. AOD2)
 UserDeploymentConfiguration.xml (Globally Published Package i.e. AOD2)
If a package is part of a connection group the machine catalog is created at the following location in
addition to the specific package location above at
“%programdata%\Microsoft\AppV\Client\Catalog\PackageGroups\ConGroupGUID\ConGroupVerGU
ID” and includes the following files:
 PackageGroupDescriptor.xml
 UserPackageGroupDescriptor.xml (Globally published Connection Group i.e. AOD2)
The Machine Catalog stores package documents that are available to users on the machine, when
packages are added and published. However, if a package is “global” at publishing time, the
integrations are available to all users. If a package is non-global, the integrations are only published
for specific users, but there are still global resources that are modified and visible to anyone on the
machine (e.g. the package directory is in a shared disk location).
If a package is available to a user on the computer (global or non-global), the manifest is stored in
the Machine Catalog. When a package is published globally, there is a Dynamic Configuration file,
stored in the Machine Catalog; therefore, the determination of whether a package is global or not is
defined as whether there is a policy file (UserDeploymentConfiguration file) in the Machine Catalog.
10.3.2 User Catalog

The User Catalog is created during the publishing process and contains information utilized for
publishing the package, and also at launch to ensure that a package is provisioned to a specific user.
The user catalog is created in a roaming location and includes user specific publishing information at
“AppData\roaming\Microsoft\AppV\Client\Catalog\Packages\PkgGUID\VerGUID”, in the following
files:
 UserManifest.xml
 DynamicConfiguration.xml or UserDeploymentConfiguration.xml
38
If a package is part of a connection group, the user catalog is created at the following location, in
addition to the specific package location above at
“AppData\roaming\Microsoft\AppV\Client\Catalog\PackageGroups\PkgGroupGUID\PkgGroupVerG
UID” and includes the following file:
 UserPackageGroupDescriptor.xml
When a package is published for a user, the policy file is stored in the User Catalog. At the same
time, a copy of the manifest is also stored in the User Catalog. When a package entitlement is
removed for a user, the relevant package files are removed from the User Catalog. Looking at the
user catalog, an administrator can view the presence of a Dynamic Configuration file, which indicates
the package is entitled for that user.
10.4 Windows 7 Platform Configuration

On Deutsche Bank’s Windows 7 platforms we use Windows native Roaming profile solution. This will
roam everything under “AppData\Roaming” with the exception of the excluded profile directories
which are set by group policy.
App-V 5 client configuration does offer RoamingFileExclusions and RoamingRegistryExclusion lists

but following testing we were unable to get it to function and these findings were backed up by
Microsofts PFE David Falkus therefore we dispensed with it for now.
App-V 5 workaround
Following testing we discovered an issue when the connection group catalog folders were roamed.
The problem centered around inconsistencies on how the App-V5 powershell cmdlets read the
status of an application. We were seeing different results depending on which cmdlet we used. After
troubleshooting the issue is became apparent the root of the problem was the presence of the
connection group calatalog xml files when roamed to a machine where the connection group was
not currently added. Our solution was to exclude the following folder from the roaming profile via
GPO and this was approved by the Microsoft PFE David Falkus.
“AppData\Roaming\Microsoft\AppV\Client\Catalog\PackageGroups”
39
This folder will need to be added to the following GPO as per below.
10.5 RDS Platform Configuration (AOD2 & DOD Lite)

The RSD platforms will differ from the Windows 7 platform in that Citrix User Profile Manager (UPM)
will be utilised to manage the roaming user environment. Citrix provide their own recommendations
for file and registry based exclusions and are as follows.
You must exclude the following items using Profile management exclusions:
 Profile Management\File system\Exclusion list\directories:
 AppData\Roaming\Microsoft\AppV\Client\Catalog
 AppData\Local\Microsoft\AppV
 Profile Management\Registry\Exclusion list:
 Software\Microsoft\AppV\Client\Integration
 Software\Microsoft\AppV\Client\Publishing
Profile Manager and App-V
It’s worth noting that on the AOD2 (RDSAPPLICATIONS) platform packages are always globally
published and connection groups are always globally enabled. This means that the package and
connection group catalog xml files will never be created in the roaming profile and hence the issue
we highlighted above regarding roaming connection group catalog folders is not relevant.
It will be however be relevant to the DOD Lite (RDSDESKTOPS) platform as applications are to be
installed by the user via the managed client console (user publishing).
40
11 App-V 5 – MC7 Delivery
We will continue to leverage the Deutsche Bank Managed Client (MC7) to deploy App-V 5 packages
as we do today for App-V 4 packages.
The App-V 5 client Powershell cmdlets will be used to execute the installation of packages and
creation of Connection Groups using Powershell v3.
A collection of Powershell scripts will be used by the various MC7 actions on order to Install, Lock,
Unlock, Repair, Uninstall & Update the package
11.1 App-V 5 Package types

There will essentially be four types of App-V 5 packages. For the purposes of this document we will
refer to them as follows.
A. Standard Package – This is a singular package to deploy one App-V 5 Package i.e. No
Connection Groups but it may contain MSI dependencies.
B. Standard Update Package – This will provide minor updates to older versions of the
application and also manage the minor version update of any connection groups the
older version is a child member of on a given client.
C. Connection Group Parent Package – This will manage its own installation as well as
instructing the deployment of its dependencies and creating a Connection Group of App-
V 5 packages to run in the same virtual environment.
D. Connection Group Parent Minor Update Package – This will provide minor updates to
older versions of the application and also manage the minor version update of any other
connection groups the older version is a member of on a given client. It will also provide
the ability to update its own connection group in any manner e.g. Add a new package
member to the connection group or change the merge order of the group.
Design Decision
1. Design decision on how to deploy connection groups without full App-

V 5 infrastructure or SCCM. We considered separate Connection
Group packages but it was deemed too difficult to manage. Parent
package management of CG’s was decided as the best available
approach.
41
12 MC7 Manifest Schema for App-V 5
Updates to the MC7 manifest schema were required to provide the information necessary to
install/publish App-V 5 packages and create connection groups.
12.1 <appv> Section

App-V 5 will have its own section delimited by the <appv> and </appv> tags.
The following table identifies the tags that can be specified and some examples.
Example.
Tag Description Mandatory
<packageid> This is the App-V 5 Package GUID which is set by the Yes
Sequencer.
<versionid> This is the App-V 5 Package version GUID which is set by Yes
the Sequencer.
<connectiongroupid> For the creation of a Connection Group, this is the Group No

GUID for the new Connection Group. It should be randomly
generated by the Packager.
<appvfile> This is the name of the .APPV file to be Added to the Client. Yes
<connectiongroup> This section will define the package members to be added No

to a Connection Group headed by the parent package.
Each child member must sit under its own tag and contain
an Ordinal number to define its merge order of precedence
in the new Connection Group. The Ordinal sequence must
start with 0,1,2,3.. etc
Each <member> must contain two mandatory tags.
packagegroup Yes
packageid Yes
<sequencerversion> This is the version of the App-V 5 sequencer on which the Yes
package was sequenced. It is for informational purposes
only.
42
Design Decisions:
1. Both the packageid and the versionid are generated by the sequencer and are required in
order to Add and Publish the package to the user.
2. The connectiongroupid is provided when we want to build a connection group of App-V 5

packages. A connection group versionid is also required but we will randomly generate
this within the powershell scripts. The reason we do not provide the connection group
versionid within the manifest is because any given connection group may be minor
updated when a child member is minor updated hence the original versionid will not be
valid moving forward.
3. There was a requirement for a <connectiongroup> section within the appv tags in addition
to the existing Manifest <dependencies> section for the following reasons.
a. The App-V 5 dependency PackageId’s need to be referenced during package

installs & Updates.
b. The merge order of App-V 5 packages in a connection group is important and this
order is strictly controlled by the use of the ordinal numbers. Note: the parent
package is not listed here and is given precedence over all child members.
c. As with connectiongroup versionid’s, the versionid’s are not required here for
member packages as these members may be minor updated outside of the
control of this package hence the versionid would become obsolete.
d. Note: all member packages listed must first be delivered by the MC7
<dependencies> section. They may of course also be delivered as child
dependencies of these listed dependencies using MC7’s native dependency
management features.
43
12.2 <artefacts> Section
This is an existing section within the manifest which delimited by the <artefact> and </artefact>
tags.
It contains a list of files which must be downloaded from the package directory on the GAR to the
local machine before any package action takes place. Typically this will include any script or
executable files which need to be invoked as part of the install or update process or as part of the
locking or unlocking procedure.
App-V 5 will require a number of files to be added to this section
12.3 Standard App-V 5 Package Artefacts

1. Celo.exe (mandatory)
2. DB_MC_Install_Action.ps1 (mandatory)
3. DB_MC_Uninstall_Action.ps1 (mandatory)
4. DB_MC_Unlock_Action.ps1 (mandatory)
5. DB_MC_Lock_Action.ps1 (mandatory)
6. DB_MC_Update_Action.ps1 (optional)
Celo.exe
The Powershell scripts will be passed for execution to an in-house developed utility called Celo.exe
within each MC7 Action in order prevent the Powershell console window from appearing when the
scripts are executed. The exit codes returned from the Powershell scripts will also be passed out to
Celo.exe so they can be assessed by MC7 for Success or Failure.
Powershell workarounds
1. Powershell execution policy prevented us from executing the Install & Update scripts
from the ROFS as was our preference as these two scripts are only ever run when the
machine is connected.
2. It was required to have all the other scripts copied locally to allow for disconnected
operation.
3. Celo.exe was developed as fully hidden execution of a powershell script console
window was not possible natively.
44
12.4 <actions> Section
This section defines the various MC7 actions available to an App-V 5 package namely
1. Install
2. Update
3. Repair
4. Uninstall
12.4.1 Install Action
The schema for this action is as follows.
<action phase="install" ordinal="0"

command=""%LOCALMACHINEPACKAGEROOT%\CELO.EXE""
arguments="POWERSHELL.EXE -File
\"%LOCALMACHINEPACKAGEROOT%\DB_MC_Install_Action.ps1\" -PackageRoot
%PACKAGEROOT% [-DynamicDeploymentConfiguration
\"%PACKAGEROOT%\<PackageName>_DeploymentConfig.xml\"] [-ForceCache]"
success="0" scope="machine"/>
Celo.exe silently executes Powershell.exe (which will resolve to the 64bit version under
“C:\Windows\System32\WindowsPowerShell\v1.0”). To Powershell.exe we will pass the following
parameters
1. –File – This parameter is mandatory and will reference the

DB_MC_Install_Action.ps1 script which will be found in the MC7 folder
%LOCALMACHINEPACKAGEROOT% on the client (delivered as an artefact). E.g.
“C:\ProgramData\Deutsche Bank\MC7\ManagedApps\Registry\APP-
W7_NOTEPAD_PLUS_PLUS-633-000”
2. –PackageRoot – This parameter is mandatory and is used simply to pass the

value of the MC7 %PACKAGEROOT% variable into the powershell script where it
is used to define the path to the manifest.xml. For installs and Updates,
%PACKAGEROOT% will resolve to the location of the manifest.xml on the ROFS.
3. -DynamicDeploymentConfiguration – This parameter is optional. If the

sequencing engineer chooses to avail of App-V 5’s Dynamic configuration then
here they will pass the (DDC) deployment configuration xml file located in
%PACKAGEROOT% folder on ROFS. Note: The install action will always be scoped
as “machine” and any deployment configuration xml’s referenced in the install
action should match the update action as either action may run depending on
whether the target machine already has the older version installed or not.
45
4. –ForceCache – Optional switch. This is a switch that when present will force the
installation to be 100% cached or Mounted in App-V 5 terms, immediately at
install time. Typically the App-V 5 client configuration Autoload setting will
dictate how a package is cached (The exception being laptops which will be
automatically fully cached by the scripts). This switch should only be used as an
exception.
Example
Managed Client Dependency
The MC7 %PACKAGEROOT% variable is passed to the script using the

parameter “–PackageRoot”. For installs and Updates,
%PACKAGEROOT% will always resolve to the location of the
manifest.xml on the ROFS server as defined by MC7.
12.4.2 Update Action
<action phase="update" ordinal="0"

\"%LOCALMACHINEPACKAGEROOT%\DB_MC_Update_Action.ps1\" -PackageRoot
%PACKAGEROOT% [-DynamicDeploymentConfiguration
\"%PACKAGEROOT%\<PackageName>_DeploymentConfig.xml\"] [-ForceCache]"
success="0" scope="machine"/>
parameters
1. –File - This parameter is mandatory and will reference the DB_MC_ Update_Action.ps1
script which will be found in the MC7 folder %LOCALMACHINEPACKAGEROOT% on the
client (delivered as an artefact). E.g. “C:\ProgramData\Deutsche
Bank\MC7\ManagedApps\Registry\APP-W7_NOTEPAD_PLUS_PLUS-633-000”
46
2. –PackageRoot - This parameter is mandatory and is used simply to pass the value of the
MC7 %PACKAGEROOT% variable into the powershell script where it is used to define the
path to the manifest.xml. For installs and Updates, %PACKAGEROOT% will resolve to the
location of the manifest.xml on the ROFS.
3. -DynamicDeploymentConfiguration – This parameter is optional. If the sequencing

engineer chooses to avail of App-V 5’s Dynamic configuration then here they will pass
the (DDC) deployment configuration xml file located in %PACKAGEROOT% folder on
ROFS. Note: The Update action will always be scoped as “machine” and any deployment
configuration xml’s referenced in the Update action should match the install action as
either action may run depending on whether the target machine already has the older
version installed or not.
4. –ForceCache – Optional switch. This is a switch that when present will force the
installation to be 100% cached or Mounted in App-V 5 terms, immediately at install
time. Typically the App-V 5 client configuration Autoload setting will dictate how a
package is cached (The exception being laptops which will be automatically fully cached
by the scripts). This switch should only be used as an exception.
Example
12.4.3 Repair Action
<action phase="repair" ordinal="0"

\"%LOCALMACHINEPACKAGEROOT%\DB_MC_Repair_Action.ps1\" success="0"
scope="user"/>
parameters
1. –File - This parameter is mandatory and will reference the DB_MC_Repair_Action.ps1

client (must be delivered as an artefact)
Example
47
Note: This action will always be scoped as “User”.
12.4.4 Uninstall Action
<action phase="uninstall" ordinal="0"

\"%LOCALMACHINEPACKAGEROOT%\DB_MC_Uninstall_Action.ps1\" success="0"
scope="machine"/>
parameters
2. –File - This parameter is mandatory and will reference the DB_MC_uninstall_Action.ps1

client (must be delivered as an artefact)
Example
Note: This action will always be scoped as “machine”.
48
12.5 <unlocktargets> and <locktargets> Sections
For App-V 5 the unlocktargets and locktargets sections are used to Publish/Unpublish packages and
Enable/Disable connection groups. They are executed by MC7 under various circumstances which
we will outline later.
The schema for these actions should never require altering.
<unlocktargets>
<target type="command" scope="user">
<command>%LOCALMACHINEPACKAGEROOT%\CELO.EXE</command>
<arguments>POWERSHELL.EXE -File
\"%LOCALMACHINEPACKAGEROOT%\DB_MC_Unlock_Action.ps1\"</arguments>
</target>
</unlocktargets>
<locktargets>
<target type="command" scope="user">
<command>%LOCALMACHINEPACKAGEROOT%\CELO.EXE</command>
<arguments>POWERSHELL.EXE -File
\"%LOCALMACHINEPACKAGEROOT%\DB_MC_Lock_Action.ps1\"</arguments>
</target>
</locktargets>
49
13 Manifest Powershell Scripts for App-V 5
The App-V4 client uses the sftmime command line interface to install App-V4 sequenced packages.
These command lines are entered directly into the MC7 actions as commands.
Due to the complexity involved in installing App-V 5 packages and connection groups in particular,
along with the difficulty in integrating them with the sequential requirements of the Managed Client
(MC7) and added to the need to target multiple platforms with different App-V 5 configuration
requirements, it became obvious very quickly that we would need to write code to assist MC7 in
delivering App-V 5 packages and connection groups.
The following is a detailed explanation of the code contained in each script.
13.1 DB_MC_Install_Action.ps1
 The purpose of this script is to add a package to the client and if required create a
connection group of packages of which this package will act as the parent.
 This script is executed by the MC7 manifest Install action when
o A user initiates a package install via the MC7 console.
o Via mcCLInt
1. # Define Script Parameters

 Three parameters may be passed to the script from the manifest install action.
i. $PackageRoot: MC7 %PACKAGEROOT% variable. (mandatory)
ii. $DynamicDeploymentConfiguration: Path to the Deployment Config xml.
iii. $ForceCache: Switch to mount the package regardless of the PCMODETYPE
2. # Get MC7 version and define its log folder

 Here we retrieve the MC7 product version using (Get-Item
"hklm:\SOFTWARE\Deutsche Bank\MC7").getvalue("ProductVersion")
 If the version is less than 7.3 then the $MC7Folder will resolve to "\Deutsche
Bank\MC7" else the folder changes to "\Deutsche Bank\MC7\AM" to be used later
to build the log file by the LogWrite function.
$Logfile = $env:ProgramData + $MC7Folder + "\logs\" + $AppGroupName +

"\MACHINE-" + $AppGroupName + "-install-0-" + $Date + ".log"
The log file location has changed with MC7.3. We have coded to change
the location from “%ProgramData%\Deutsche Bank\MC7\logs” to
“%ProgramData%\Deutsche Bank\MC7\AM\logs” from this version
onwards.
50
3. # Load Manifest.xml from %PACKAGEROOT% and retrieve appv related information
 The manifest located on ROFS is loaded into an $xml object from $Manifest =
$PackageRoot + "\manifest.xml"
[xml]$xml = Get-Content $Manifest

## Manifest Data ##
#Package Data
$AppGroupName = $xml.manifest.package.general.group
$AppName = $xml.manifest.package.general.name
$AppVersion = $xml.manifest.package.general.("product-version")
$ManifestVersion = $xml.manifest.package.general.("manifest-version")
#Appv5 Package Data
$packageid = $xml.manifest.package.appv.packageid
$versionid = $xml.manifest.package.appv.versionid
$appvfile = $xml.manifest.package.appv.appvfile
#Appv5 Connection Group Data
$connectiongroupid = $xml.manifest.package.appv.connectiongroupid
#New randomly generated Version Id for the ConnectionGroup
$connectionversionid = [guid]::NewGuid()
We leverage the %PACKAGEROOT% variable to determine the location of the

package manifest on ROFS. It cannot be referenced locally as it is not copied there
in time.
1.
4. # Establish type of Update (single Package or Connection Group Parent Package)
 If the $connectiongroupid is retrieved from the manifest then we will assume this is
an $InstallType = “CGUpdate” else it’s a “PKGUpdate”
 This $InstallType value will be used for decision making later.
5. # Get PCMODELTYPE
 This value is taken from the client and will determine which switch statement code
blocks will be run later.
$PCModelType = (Get-Item "hklm:\SOFTWARE\Deutsche

Bank").getvalue("PCMODELTYPE")
 If the value is null or empty we abort the installation (Exit 1)
6. # Build the .Appv Path for streaming package

 The purpose of this code block is to define the path from which we will ADD the
package. It may be the MC7 Primary or Secondary GAR path and it may use SMB or
HTTP protocols depending on the clients’ configuration.
 Here we carry out a comparison of the $GarRoot folder (resolved from the MC7
%PACKAGEROOT% variable passed in) e.g. “\\dcrofs.gslb.db.com\rofs” and the MC7
Client GAR HardPaths settings to confirm where the package is being installed from
(as per MC7 code).
51
 Then depending if the AppV5StreamingProtocol GPO setting is set to “SMB”
(default) we will use the matched PrimaryHardPath or if set to “HTTP” then we will
use the corresponding APPVURL value to the build our installation path.
 Eventually we end up with a path to the .appv file on the ROFS assigned to a variable
called $appvfilePath which will be used by the powershell cmdlets later to Add
the package to the client.
1. Use of %PACKAGEROOT% variable.

2. Here we replicate how MC7 determines which GAR (Primary or Secondary) is
should use.
3. MC7 cannot currently distinguish between Appv 4 & 5. We query the
“Appv5StreamingProtocol” reg key streaming protocol options with a default of
SMB therefore it was necessary to add an additional key via GPO
“AppV5StreamingProtocol” to reference.
7. # Import the App-V Client module

 Here we import the appvclient powershell module and measure the time taken.
 We have experienced delays when importing the AppvClient module where the test
machine is not connected to the internet and as a result the CRL check fails with a
delay of 15-30 seconds.
 It is not expected that we will experience this in a production environment but in
some test environments this may be an issue due to firewall restrictions. To work
around this problem (for testing purposes only), the module dll’s can be directly
imported as detailed below.
 “To verify an Authenticode signature, the requesting computer must connect to the
Internet to obtain a current Certificate Revocation List (CRL). For .NET applications,
the .NET Common Language Runtime (CLR) verifies Authenticode signatures for
assemblies. If the computer that loads the assembly is not connected to the Internet,
the CLR waits 15 seconds before timing out.”
 Essentially if the machine doesn’t have access to download the certificates for the
following locations then it will take 15 seconds to load to App-V client module.
52
1. http://crl.microsoft.com/pki/crl/products/microsoftrootcert.crl
2. http://crl.microsoft.com/pki/crl/products/MicCodSigPCA_08-31-2010.crl
3.http://www.download.windowsupdate.com/msdownload/update/v3/static/truste
dr/en/authrootstl.cab
 Workaround code 1.
o Load the module dll’s directly. You will need to modify the scripts to
replace the existing module importation code. Please ensure this is
never included in a production package.
Import-module "C:\Program Files\Microsoft Application

Virtualization\Client\AppvClient\Microsoft.AppV.AppvClientC
omConsumer.dll"
Import-Module "C:\Program Files\Microsoft Application
Virtualization\Client\AppvClient\Microsoft.AppV.AppVClientP
owerShell.dll"
Import-module "C:\Program Files\Microsoft Application
Virtualization\Client\AppvClient\Microsoft.AppV.ClientProgr
ammability.Eventing.dll"
 Workaround code 2.
o Bypass CRL checking on you test machine by setting the following
registry key.
o “HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing\State” from 0x00023c00 to 0x00023e00
8. # Switch statements based on the PCModeltype

PCMODELTYPE = “Default”
The default code block will cater for all PCMODELTYPE’s other than the ones specified following
this section. It currently includes VIRTUALDESKTOP, DESKTOP, RDSDESKTOP,
BLADEWORKSTATION.
 If the $InstallType = “PKGInstall” then Add the package using the appv5 powershell
cmdlet “Add-AppvClientPackage”. There are four variations in the command line used
depending on whether we had $DynamicDeploymentConfiguration and/or $ForceCache
parameters passed to the script.
E.g. Add-AppvClientPackage -Path $appvfilePath -

DynamicDeploymentConfiguration $DynamicDeploymentConfiguration | Mount-
AppvClientPackage
 We then exit the script with a 1 or 0 depending on any errors returned from the cmdlet.
 If the $InstallType = “CGInstall” then we execute a different code block.
 As above we will first Add the package in a similar manner.
 On success we will then execute the CreateAddConnectionGroupFromManifest
function
53
Function CreateAddConnectionGroupFromManifest
 Firstly we must create the connection group child member objects and establish what
the Priority of our new connection group will be.
 Retrieve number of child member packages from the ROFS manifest
 Create a package object for each child member and save to and array.
 The child members as identified from the manifest will only provide a packageid. We will
select the package based on a package containing this packageid of which there can be a
maximum of one as only one version of a package can be published to a user at any one
time.
$package_dep = Get-appvclientpackage -PackageId $packageid_dep.packageid
 In the unlikely event we do not find a published package based on the above search then
we will widen the search to “–All” packages on the machine and if there are multiple
versions returned then we will select the latest version.
$package_dep = Get-appvclientpackage -PackageId $packageid_dep.packageid

-All|Sort-Object {$_.Version}|Select-Object -last 1
 The reason we included the above –All search was because we discovered that MC7
dependency Unlock actions are sequenced differently for a fresh install compared with
an Uninstall and reinstall of a package. See MC7 flow diagrams. We expect this to be a
rare occurrence.
 For each connection child package object we then must check to see if they are a
member of any connection groups on the client using the function
GetConnectionGroupPriority and if they are we need to record the highest
connection group priority in order to ensure our new connection group is not built with
the same priority (Note: If two enabled connection contain the same member package
and the same priority then the common application will fail to launch). We will
increment the priority by 10 off the highest number returned by all executions of the
function.
Managed Client Workaround
MC7 dependency unlocking is sequenced differently for a fresh install compared to

an Install, Uninstall and Reinstall of the same parent package. i.e. dependencies are
being unlocked after the parent as opposed to before it as with a fresh install.
Function GetConnectionGroupPriority
 Get all the connection groups added to the client (Whether enabled to the User or not).
$ConnectionGroupObj = Get-AppvClientConnectionGroup -All
54
 For each connection group found, get all its member packages (whether published to
the user or not)
$CGMembers = (Get-AppvClientConnectionGroup -GroupId $CG.GroupId -
VersionId $CG.VersionId -All).GetPackages()
 For each member compare it’s packageId with the packageId of the child member we
passed to it.
 If we get a match then record the Priority of that connection group.
 The function will return the highest priority found or default to a value of 1000 if there
were no matches.
App-V5 Standalone Environment Workaround
If two connection groups share the same member package and the same Priority then this
application will fail to launch as the App-V 5 client does not know which connection group VE
to launch the application in.
 The next step is to build the parameter values we will pass to the New-
AppvConnectionGroupFile function.
Function New-AppvConnectionGroupFile
 The purpose of this function is to create the connection group descriptor xml and Add
the connection group to the client.
 The following are the function parameters explained.
New-AppvConnectionGroupFile -Path $NewXML -DisplayName $DisplayName -

Priority $Priority -connectiongroupid $connectiongroupid -
connectionversionid $connectionversionid -Packages $Packages | Add-
AppvClientConnectionGroup
o -Path – This is the name and path to the new connection group descriptor file
which will contain the details of the connection group.
$CGRepository = $env:ProgramData + "\App-V\DB_ConnectionGroups"

$NewXML = $CGRepository + "\" + $connectiongroupid + "_" +
$connectionversionid +".xml"
 Note the $connectiongroupid is taken from the manifest and the

$connectionversionid is randomly generated by the script.
o -DisplayName – Is the $AppGroupName taken from the manifest with
“_ConnectionGroup” appended. $DisplayName = $AppGroupName +
"_ConnectionGroup"
o -Priority – As determined earlier by the GetConnectionGroupPriority
function.
o -connectiongroupid – As provided by the manifest
o -connectionversionid – Randomly generated by the script
55
o -Packages – An array containing the all the member packages objects in order of
merge precedence. The parent package is always the first followed by the child
members in an order dictated by the manifest appv member ordinal numbers.
 Finally we will check that the connection group object has been created successfully exiting
with 1 on failure and 0 on success.
PCMODELTYPE = “NOTEBOOK”
 The code is the same as the above except we will Mount (fully cache) the package as part of
the Add-AppvClientPackage cmdlet.
 The –ForceCache parameter is overlooked as we are already mounting the package.
 There is no requirement to Mount the Connection group when adding it as the members will
already be mounted.
E.g. Add-AppvClientPackage -Path $appvfilePath -DynamicDeploymentConfiguration

$DynamicDeploymentConfiguration | Mount-AppvClientPackage
PCMODELTYPE = “RDSAPPLICATIONS”
1. RDSAPPLICATIONS installations are expected to run only within a maintenance window
therefore we assume no users will be logged on and therefore no packages will be in use.
2. The RDSAPPLICATIONS code block again follows a similar pattern to the above with a few
significant exceptions.
3. A requirement of the AOD2 platform is to globally publish all App-V 5 packages and enable
all connection groups globally. Unlike the other platforms we will carry out the package
publishing and Connection group enabling within this script as opposed to the
DB_MC_Unlock_Action.ps1 script which is not run on this platform.
4. Global publishing/Enabling is a machine based state therefore it was right that it should be
executed as part of this MC7 machine scoped action. The UnlockTargets/LockTargets actions
are consequently not required on this platform.
#Add Package
Add-AppvClientPackage -Path $appvfilePath
#Publish Package Globally

Publish-AppvClientPackage -PackageId $packageid -VersionId $versionid -Global
# Create Connection Group XML and Add Connection Group to client

CreateAddConnectionGroupFromManifest
# Enable Connection Group Globally

Enable-AppvClientConnectionGroup -GroupId $connectiongroupid -VersionId
$connectionversionid -Global
56
DB_MC_Install_Action
CLINT/PREPOP -
MC7 GUI - Install
Install
Manifest.xml Details
Mandatory
<packageid>
<versionid>
<appvfile>
Retrieve Manifest.xml details from ROFS
Optional
<connectiongroupid>
<connectiongroup>
Is this a Connection group Install?

Get PCMODELTYPE No (determined by presence of a
connectiongroupid)
Yes Get PCMODELTYPE
PCMODELTYPE =
PCMODELTYPE = “VIRTUALDESKTOP”,
“VIRTUALDESKTOP”, PCMODELTYPE = “DESKTOP”,
PCMODELTYPE =
“NOTEBOOK” “RDSAPPLICATION” “NOTEBOOK”,
“RDSAPPLICATIONS”
“DESKTOP”, “RDSDESKTOPS”,
“RDSDESKTOPS” “BLADEWORKSTATION”
Optional Install Action Parameters.

Optional Install Action Parameters.
1. -DynamicDeploymentConfiguration Optional ADD Parameters.
1. -DynamicDeploymentConfiguration Optional ADD Parameters.
2. -ForceCache 1. DynamicDeploymentConfiguration
2. -ForceCache 1. DynamicDeploymentConfiguration
2. ForceCache 2. ForceCache
ADD Package ADD Package ADD Package ADD Package
Publish Package -Globally Publish Package -Globally
Get new Connection Group Get new Connection Group

Priority - If dependencies listed in Priority - If dependencies listed in
<appv> section of Manifest.xml, <appv> section of Manifest.xml,
then For each dependency check then For each dependency check
all existing Connection Groups all existing Connection Groups
member packages registered on member packages registered on
the client for a package match and the client for a package match and
if found record the Priority. The if found record the Priority. The
largest found priority of all largest found priority of all
matches +10 will be our CG matches +10 will be our CG
priority Else priority = 0 priority Else priority = 0
Create new Create new

ConnectionGroup.xml ConnectionGroup.xml
on client on client
Add CG to the Client Add CG to the Client
Enable the Connection

Group - Globally
MC7
Unlock
Action
57
13.2 DB_MC_Update_Action.ps1
 The purpose of this script is to update a package on the client and if required update all
connection groups it is a member of.
 This script is executed by the MC7 manifest Update action when
o A user initiates a package update via the MC7 console.
o Via mcCLInt

 Three parameters may be passed to the script from the manifest install action.
i. $PackageRoot: MC7 %PACKAGEROOT% variable. (mandatory)
ii. $DynamicDeploymentConfiguration: Path to the Deployment Config xml.
iii. $ForceCache: Switch to mount the package regardless of the PCMODETYPE

 As previously defined
3. # Load Manifest.xml and retrieve appv related information

4. # Establish type of Update (single Package or Connection Group Parent Package)

an $InstallType = “CGUpdate” else it’s a “PKGUpdate”
 This $InstallType value will be used for decision making later.
6. # Build the .Appv Path for streaming package


8. # Create old package and old connection group objects

 Here we will create powershell objects for the package to be updated and if necessary
also for the connection group to be updated.
 Firstly we must determine if the script is being executed by the User via the MC7 console
as this will help us to locate the old package and connection group versions with
58
certainty as the package/connection groups to be updated will be published/enabled to
the current user prior to the script execution. (note: only one version of a package or a
connection group can be published/enable to any given user at one time)
 We can also assume the same on AOD2 (RDSAPPLICATIONS) as the installations are
globally published/enabled therefore every installing account will have the package/CG
published/enabled to it.
 To establish this we will run the function IsUserInitiated.
Function IsUserInitiated
o The purpose of this function is to determine if the powershell script process is User
initiated i.e. executed by MC7 (mcADA.exe) or not.
o If it’s not mcADA.exe then the likelihood is it will be mcCLInt but we just need to
establish if the action has been initiated by the User via the MC7 console or not.
o We will check the parent and grandparent processes running our powershell script
to see if either matches “mcADA”.
o We then set the $UserAction variable to $true or $false depending on the result.
$UserAction will be used later for decision making. E.g. to decide if we can present
User dialogs.
Function IsUserInitiated{
# Function to determine if mcADA.exe is executing this script and if so
we can assume this is being executed by the User via the MC7 console.
$MyPid = $PID
$ParentPid=(Get-WmiObject win32_process -Filter
"processid='$MyPid'").parentprocessid
$GrandParentPid=(Get-WmiObject win32_process -Filter
"processid='$ParentPid'").parentprocessid
$ParentProcessObj = Get-Process -Id $ParentPid
$GrandParentProcessObj = Get-Process -Id $GrandParentPid
If (($ParentProcessObj.Name -eq "mcADA") -or
($GrandParentProcessObj.Name -eq "mcADA")){LogWrite $("The parent process is
mcADA.exe therefore this action is User initiated via MC7 Console");Return
$true}
Else{LogWrite $("The parent process is not mcADA.exe therefore this
action is NOT User initiated via MC7 console");Return $false}
}
$UserAction = IsUserInitiated
In order to determine if the execution of this script is User driven via MC7 console or not
we check to see if one of the parent/grandparent processes are mcADA.
 If our script has not been initiated by the mcADA or is not RDSAPPLICATIONS then
we will widen the search for the old package (the installing account will not have
anything published/enabled to it e.g. mcCLInt = System Account, PrePOP = local
Admin account)
59
 As a consequence, the $OldPackageObj may contain more than one package
object.
 The same applies for the $OldConnectionGroupObj

PCMODELTYPE = “default”
The default code block currently includes all PCMODELTYPE’s except RDSAPPLICATIONS for this
script.
 If the Update is $UserInitiated and a “CGUpdate” then we will check if the old CG is in
use by the current user ($OldConnectionGroupObj.InUseByCurrentUser). If it is then
we must get a list of the virtual processes running, using the Get-AppvVirtualProcess
cmdlet, which belong to the CG packages members and retrieve their process
descriptions in order to present a dialog to the current user informing them to shut
down those applications or allow us to (StopDisableOldConnectionGroup) before
continuing.
 However if the $OldConnectionGroupObj is not in use by the current user but is in

enabled to the current user ($OldConnectionGroupObj.IsEnabledToUser) then we will
go ahead and call the StopDisableOldConnectionGroup function which stops and
disables the old connection group in the context of the current user only.
 Next we must check to see if the old package is a member of any other connection
groups on the client (excluding our own CG GroupId as we will recreate this from the
updated manifest later) using the ConnectionGroupMemberships function. If we find
any matches then we will record this information in an object to be processes later in
order to update these connection groups with the new package.
 If any CG matches were found for our old package then we must now check to see if any
of them are in use by the current user. If they are we must again present a dialog to the
user listing the running applications and ask the user to shut them down or allow us to.
If CG’s were found but they are not in use by the current user then we will just carry on
60
and Stop and Disable these connections groups. (Note: we cannot update a package
whilst it is a member of any connection group enabled to current user)
 We should now be in a position to update the old package with the new.
 We will first ensure the old package is not in use by the current user and if it is present a
dialog requesting the application to be shut down before continuing.
 We will then add the new package and Mount it for NOTEBOOK.
 We do not remove the old package at this time as adding the new package over the top
will result in only the new package additions (deltas) being streamed over the network
and written to disk.
 Our next task will be to update any other connection groups we found containing our
old package using the ReCreateFoundConnectionGroups function.
 This function iterates through the connection group matches saved earlier, builds a new
CG descriptor xml file for each replacing the old package member with our update
package.
 For each package member the ReCreateFoundConnectionGroups function will also call
the GetConnectionGroupPriority function to establish the new Priority for the CG
update.
 The descriptor files are created and the connection groups are registered with the client
using the New-AppvConnectionGroupFile function.

Appv5 Workaround/Managed Client Dependency
1. We must stop a connection group before we can update it. If connection group
is found to be in use by the current user then we must present a dialog to the
user before we can stop it in order to warn the user and prevent any loss of
unsaved application data.
2. You must disable for the current user all connection groups a package is a
member of before you can unpublish that package for that same user.
61
Function New-AppvConnectionGroupFile
 The purpose of this function is to create the connection group descriptor xml and Add
the connection group to the client.
 The following are the function parameters explained.
 New-AppvConnectionGroupFile -Path $NewXML -DisplayName $DisplayName -Priority
$Priority -connectiongroupid $connectiongroupid -connectionversionid
$connectionversionid -Packages $Packages | Add-AppvClientConnectionGroup
o -Path – This is the name and path to the new connection group descriptor file
which will contain the details of the connection group.
 $CGRepository = $env:ProgramData + "\App-
V\DB_ConnectionGroups"
 $NewXML = $CGRepository + "\" + $connectiongroupid + "_" +
$connectionversionid +".xml"
 Note the $connectiongroupid is taken from the manifest and the
$connectionversionid is randomly generated by the script.
o -DisplayName – Is the taken directly from the old connectiongroup.
o -Priority – This is returned from GetConnectionGroupPriority function and
incremented by 10.
o -connectiongroupid – This is taken from the old connection group.
o -connectionversionid – Randomly generated by the script
o -Packages – An array containing the all the member packages objects in order of
merge precedence as per the old connection group. The only difference should
be the old package versionid will be swapped with our new packages’ versionid.
 We have now reached the point where we have disabled the old version of our
connection group (If this is a CGUpdate). We have also disabled all other connection
groups containing our old package, created new versions of those CG’s (containing our
update package) and Added them to the client.
 The final task is to update our own connection group. The reason we handle this
separately is to allow us to cater for any additions/updates to the new manifest version.
E.g a new connection group member or merge order.
 We will call the CreateAddConnectionGroupFromManifest function to create our new
connection group.
Function CreateAddConnectionGroupFromManifest
 Firstly we must create the connection group child member objects and establish what
the Priority of our new connection group will be.
 Retrieve number of child member packages from the ROFS manifest
 Create a package object for each child member and save to and array.
 The child members as identified from the manifest will only provide a packageid. We will
select the package based on a published package containing this packageid of which
there can be a maximum of one as only one version of a package can be published to a
user at any one time. $package_dep = Get-appvclientpackage -PackageId
$packageid_dep.packageid
 If for any reason we do not find a package based on the above search then we will widen
the search to –All packages on the machine and if there are multiple versions returned
then we will select the latest version. $package_dep = Get-appvclientpackage -
62
PackageId $packageid_dep.packageid -All|Sort-Object {$_.Version}|Select-
Object -last 1
 The reason we included the above “–All” search was because we discovered that MC7
dependency Unlock actions are sequenced differently for a fresh install compared with
an Uninstall and reinstall of a package. See MC7 flow diagrams. We expect this to be
rarely required.
 For each child package object we then must check to see if they are a member of any
connection groups on the client using the function GetConnectionGroupPriority and
if they are we need to record the highest connection group priority in order to ensure
our new connection group is not built with the same priority (Note: If two enabled
connection contain the same member package and the same priority then the common
application will fail to launch). We will increment the priority by 10 off the highest
number returned by all executions of the function.
This function references the <connectiongroups> section of the parent

package manifest on the ROFS server.
Function GetConnectionGroupPriority
 Get all the connection groups added to the client (Whether enabled to the User or not).
 $ConnectionGroupObj = Get-AppvClientConnectionGroup -All
 For each connection group found, get all its member packages (whether published to
the user or not)
 $CGMembers = (Get-AppvClientConnectionGroup -GroupId $CG.GroupId -
VersionId $CG.VersionId -All).GetPackages()
 For each member compare it’s PackageId with the packageId of the child member we
passed to the function.
 If we get a match then record the Priority of that connection group.
 The function will return the highest priority found or default to a value of 1000 if there
were no matches.
 The next step is to build the parameter values we will pass to the New-
AppvConnectionGroupFile function and run it resulting our new connection group
added to the client.
1. RDSAPPLICATIONS updates are expected to run only within a maintenance window
therefore we assume no users will be logged on and therefore no packages will be in use.
2. The RDSAPPLICATIONS code block again follows a similar pattern to the above with a few
significant exceptions.
63
3. A requirement of the AOD2 platform is to globally publish all App-V 5 packages and globally
enable all connectiongroups globally. Unlike the other platforms we will carry out the
package publishing and Connection group enabling within this script as opposed to the
DB_MC_Unlock_Action.ps1 script which is not run on this platform.
#Add Package
Add-AppvClientPackage -Path $appvfilePath
#Publish Package Globally

Publish-AppvClientPackage -PackageId $packageid -VersionId $versionid -
Global
# Create Connection Group XML and Add Connection Group to client

CreateAddConnectionGroupFromManifest
# Enable Connection Group Globally

Enable-AppvClientConnectionGroup -GroupId $connectiongroupid -VersionId
$connectionversionid -Global
Update Design Decision
When updating a package which is a member of connections groups we will version

update all the CG’s that the package is a member of on the client regardless of whether
the CG is enabled to the current user or not. (By Version update we mean create the
updated connection group descriptor xml and Add the connection group to the client
during the Update script execution.) This is necessary because when a 2nd User logs
onto the same machine they may have connection groups containing the old package
that they are entitled to but User 1 wasn’t. User 2 may then be offered the same
package update but because the package update script has already been executed on
the machine (machine registered in MC7 terms) the Update script will not run again,
only the Unlock action. The Unlock action will then publish the updated package to
User2 and check all connection groups on the client for a package match and after
checking all the CG members are published to User2, enable those connection groups
to User2.
64
CLINT/ Manifest.xml Details
DB_MC_Update_Action MC7 GUI -
Update
PREPOP -
Update Mandatory
<packageid>
<versionid>
<appvfile>
Optional
<connectiongroupid>
PCMODELTYPE = PCMODELTYPE = <connectiongroup>
Retrieve Manifest.xml details from ROFS
“RDSAPPLICATIONS” “DEFAULT”
MC7 (mcADA) driven? No Exit 1
Is this a CG
Update? Yes
Yes Is this a CG
Update?
Is the old CG
Yes Exit 1 Yes Exit 1
in use?
Is the old CG No
in use by the
User? Yes
No
No
No Present application list to No
shut down and permission
to continue?
Stop Globally, Disable
Globally & Remove old CG. Stop & Disable old CG for
Delete old CG.xml Current User Only. (If
enabled for User)
Yes
Is old package a member of any

Connection group Added to the
client (excluding our own
connectiongroupId for CG
Is old package in use?
Exit 1 Yes Update)?
(shouldn’t be)
Exit 1
Yes
No No
Store details of all Connection Group
matches (regardless of whether
Enabled to the Current User or not)
Present application list to

Is old package a member of
shut down and permission
any other Connection
to continue?
groups Added to the client? Yes
Are any of these CG’s in
use by current User?
No
No
Yes
No
Store details of all Connection

Group matches
Stop & Disable all matched

Yes
CG’s for Current User Only
No
Stop & Disable Globally &

Remove all matched CG’s &
delete the CG.xml Ask User to shut down
Is the old package in use
package and permission
by the User?
to continue?
Stop Old package for

Stop Old package Yes
Current User
Globally
Add New Package
Add new package (If

NOTEBOOK also Mount
package)
Publish New Package

Globally
Recreate & Add all these

CG’s (exc our CG) with new
Was old package a member of
Yes CG versionid applied and
any connection groups?
incl new package as an
updated member
Remove Old Package
No
Recreate, Add and globally

publish all these CG’s (exc
Was old package a member of our CG) with new CG
Yes
any connection groups? versionid applied and incl Is this a CG
new package as an updated Update?
member
No Yes
No
Is this a CG
No
Update?
Create & Add our New
Connection Group (using details
from Manifest)
Yes
Create & Add New Connection

Group (using details from
Manifest) & Publish Globally MC7 Unlock Action
65
13.3 DB_MC_Unlock_Action.ps1
 The DB_MC_Unlock_Action.ps1 powershell script is executed by MC7 UnlockTargets.

 Its purpose is to publish the package and enable any connection groups containing this
package.
 The target type = “command” and is always scope=”user”.
 This command runs
o Immediately following MC7 Install actions
o As a result of an MC7 User entitlement refresh which occurs on User log-on or
can be forced using a MC7 console hard-refresh button
o Following an MC7 Repair action
o When a User is re-added to a package ACL group.

 There are no parameters required to be passed into the script.

4. # Load the machine Manifest.xml to retrieve the AppGroupName in order to locate the
User manifest
 The manifest referenced is the User profiled version under “%AppData%\Deutsche
Bank\MC7\ManagedApps\Registry\<AppGroupName>”
$Manifest = $env:appdata + "\Deutsche Bank\MC7\ManagedApps\Registry\"
+ $AppGroupName + "\manifest.xml"
 The following information is retrieved from the manifest.
#Package Data
#Appv5 Data
#Package Data
#Connection Group Data
66
As this is a User scoped action we have chosen to reference the User profiled
version of the manifest. This will allow us to retrieve details relevant to a particular
user. E.g. On a shared desktop if a package is updated by one user it will allow
another user to remain on the older version until they choose to update via the MC7
console. Note: we must first reference the machine based manifest in order to
retrieve the AppGroupName which will enable us to find the User based manifest.

6. # Create package objects

 Create the package object based on the PackageId and VersionId taken from the
Users manifest.
$PackageObj = Get-AppvClientPackage -PackageId $packageid -VersionId
$versionid -All
 Note we use the “–All” switch in case the package is not currently published to the
user.
 If we are running on the RDSDESKTOPS platform then we will check for an older
version of our package that is published to the current user and assign to an object.
This is necessary as the unlock action may be required to present a dialog to the user
in a certain scenario (see flow diagram)
The default code block currently includes all PCMODELTYPE’s except RDSDESKTOPS and
RDSAPPLICATIONS. If the PCMODELTYPE is found to be RDSAPPLICATIONS then we will have
already aborted the script entirely as it is not required to run as global publishing is carried
out at install time for AOD2 platform.
 Firstly we check to see if the package is published to the current user

($PackageObj.IsPublishedToUser).
 It was necessary to enhance this check as we discovered that the appv cmdlet was not
totally reliable as is appears to base the check solely on the presence of appv User
catalog xml files located under
“appdata\roaming\Microsoft\AppV\Client\Catalog\Packages\PackageId\VersionId”.
67
 Hence the use of the UserIntegrationCheck function which also checks for the
presence of the package integration folder under IntegrationPath =
$env:LOCALAPPDATA + "\Microsoft\AppV\Client\Integration\" + $packageid
 If the package does not pass these checks then we will publish the package to the
current user.
 Next step is to search the machine for any connection groups containing our package
that may require enabling for the current user.
 To achieve this we run the FindEnableConnectionGroups function.
Appv5 Bug Workaround
The UserIntegrationCheck has been added to double-check whether a package is

really published to the User as the relevant appv cmdlet proved unreliable. It is
expected that this check will be unnecessary following App-V5SP2HF4
Function FindEnableConnectionGroups
 Firstly we use the appv cmdlets to retrieve all the connection groups on the client that
are not enabled to the current user and order them by Priority number.
$ConnectionGroupObj = Get-AppvClientConnectionGroup -All | Where

{$_.IsEnabledToUser -eq $False} | Sort-Object {$_.Priority}
 We then cycle through all the disabled connection groups found checking for the
existence of our package as a member (using package & version id’s).
 For each connection group match we then check the published status of each package
member and if all the members are all published to the current user then we enable
that connection group to the user.
 Note: Updates or downgrades (roll-back) to a connection group will always require a
new CG to be created with a new versionid and the priority will always be incremented
by 10 off the previous version. It is therefore possible that we can have two connection
groups with exactly the same package members. Because we cycle through enabling the
matched CG’s in ascending order of Priority number the CG that will be last enabled will
be the one with the higher number which will be the last one installed as is required.
 The script then completes. Note: MC7 does not accept any return codes for the
UnlockTargets action.
Appv5 Workaround
Currently we do not remove old packages or connection groups during an update.

Updates or downgrades (roll-back) to a connection group will always require a new CG
to be created with a new CG versionid and the priority will always be incremented. It is
therefore possible in a down-grade scenario that we can have two connection groups
with exactly the same package members. Because we cycle through enabling the
matched CG’s in ascending order of Priority number the CG that will be last enabled
will be the one with the highest number which will be the last one installed as is
required.
68
PCMODELTYPE = “RDSDESKTOPS”
 Firstly we check to see if the package is published to the current user

($PackageObj.IsPublishedToUser).
 It was necessary to enhance this check as we discovered that the appv cmdlet was not
totally reliable as is appears to base the check solely on the presence of appv User
catalog xml files located under
“appdata\roaming\Microsoft\AppV\Client\Catalog\Packages\PackageId\VersionId”.
Note: the catalog folders are to be excluded from roaming by Citrix GPO.
 Hence the use of the UserIntegrationCheck function which also checks for the
presence of the package integration folder under IntegrationPath =
$env:LOCALAPPDATA + "\Microsoft\AppV\Client\Integration\" + $packageid
 If the package is already published to the current user then we check the machine for
any connection groups containing our package that may require enabling for the current
user.
 If however the package is not published to the current user then we take a different
approach to the other platforms.
 We next check to see if there is another version of our package in use by the current
user. If there isn’t then we publish the package and run the
FindEnableConnectionGroups function as before.
 If however the user is currently running an older version of our package then we must
present a dialog to the user requesting a shutdown of the necessary applications. To
determine what these applications are we must carry out the following.
 We will now check to see if our package is in any connection groups that are in use by
the current user and if there are more than one then return connection group with the
lowest priority as this is the connection group virtual environment the package will be
launched into. To retrieve this info we must run the Get-
InUseConnectionGroupLowPriority function.
 If no connection group objects are returned from this function then we will run the
OldPkgDialogShutdown function which will present the following dialog to the user
requesting a shut-down of the application. Note: There are no options to cancel this
action. This was necessary to ensure the dialog does continuously pop-up every time
the unlock action is executed. Once the new package is published to the user it will not
present the pop-up again due to the code logic.
69
 If we discovered that our old package was currently running inside a connection group
VE we will then determine which virtual applications are running inside this CG VE and
present this application list using the GenerateFormBig function. Again note the user
will have no option to cancel this dialog action.
 Once the requested applications are closed down we will then publish the package to
the current user.
 Next step is again to search the machine for any connection groups containing our
package that may require enabling for the current user.
70
DB_MC_Unlock_Action
Update (m/c Repair (user User re-added
MC7 Install Action
scope) scope Only) to Package AD
Group
Manifest.xml Details
Mandatory
<packageid>
<versionid>
<appvfile>
Retrieve Manifest.xml details from Optional
%AppData%\Deutsche Bank\MC7\ <connectiongroupid>
ManagedApps\Registry\<group>\ <connectiongroup>
This section will handle an

Update scenario on
RDSDESKTOPS where a User
Get PCMODELTYPE
initiates an Update to a Package
that is already Added to the
Server by someone else and
where the old version is in use by
the current User. Note: the
Update action does not run (as
PCMODELTYPE = MC7 recognises it as already run)
“VIRTUALDESKTOP”, but the Unlock action does.
PCMODELTYPE = PCMODELTYPE =
“DESKTOP”,
“RDSAPPLICATIONS” “RDSDESKTOPS”
“NOTEBOOK”,,
“BLADEWORKSTATION”
Abort (Exit 0)
Is the package Is there an old version of Determine what virtual

Is the package Published to
Published to the No the package in use by the Yes environment it is launched in (its
the User?
User? user? own or a connection group)
No
Yes
Yes
Publish Package to No
User
Request user to shut down relevant apps
in order to continue. (no option to
cancel because running in Unlock action)
Loop through all connection groups Loop through all connection groups
disabled to the current user for a disabled to the current user for a Publish Package to
match with our package. match with our package. User
Match found? No Exit 0 Match found? No Exit 0
Yes Yes
Is each member of this Is each member of this

connection group Published to connection group Published to
No Exit 0 No Exit 0
the Current User? the Current User?
Yes Yes
Enable Connection Group for current user Enable Connection Group for current user
71
13.4 DB_MC_Lock_Action.ps1
 The DB_MC_Lock_Action.ps1 powershell script is executed by MC7 LockTargets.

 Its purpose is to remove the publication of the package from the User.
 If the package is a member of any connection groups enabled to the user then it must
also disable those connection groups first.
 The target type = “command” and is always scope=”user”.
o Immediately prior to the MC7 Uninstall action running for MC7 driven Uninstalls.
o When a User is removed from the package ACL group and MC7 carries out a
User entitlement refresh.


User manifest

 As outlined previously.
6. # Create package object

Users manifest.
$versionid -All
 Note we use the “–All” switch in case the package is not currently published to the
user.
72
The default code block currently includes all PCMODELTYPE’s except RDSDESKTOPS. If the
PCMODELTYPE is found to be RDSAPPLICATIONS then we abort the script entirely as it is not
required to run as global publishing is carried out at install time for AOD2 platform.
 Before we can unpublish a package for the user we must first make sure the package is
not a member of any connection groups that are enabled to the user.
 To achieve this we will run the IfMemberStopDisableConnectionGroups function.
Function IfMemberStopDisableConnectionGroups
 Get all Connections Groups on Client that are enabled to the Current User
 Cycle through each connection group and see if there is a member match with our
package (based on packageid & versionid).
 If we find a member match then if the connection group is in use we stop it for the
user.
Important Note
Stopping a connection group/package without warning the user can

result in loss of unsaved data.
This script can run in two scenarios, When a User is removed from
the Application group or when a user initiates an uninstall of the
package. In both of these scenarios we have assumed that it is
acceptable to stop the package without warning.
 If the connection group is enabled to the current user then we disable it.
Appv5 Standalone Workaround
Before we can unpublish a package for the user we must first make
sure the package is not a member of any connection groups that are
enabled to that user. To achieve this we will run the
IfMemberStopDisableConnectionGroups function.
 We should now be in a position to Unpublish the package for the user.

 The script then completes. Note: MC7 does not accept any return codes for the
UnlockTargets action.
73
DB_MC_Lock_Action
User removed from

Package Uninstall
Package AD Group
Retrieve Manifest.xml details from

%AppData%\Deutsche Bank\MC7\
ManagedApps\Registry\<group>\
Get PCMODELTYPE
PCMODELTYPE =
“VIRTUALDESKTOP”,
PCMODELTYPE = “DESKTOP”,
“RDSAPPLICATIONS” “RDSDESKTOPS”,
“NOTEBOOK”,,
“BLADEWORKSTATION”
Abort (Exit 0)
IfMemberStopDisableConnectionGroups
If our package is a member of any Connection
groups on the client then force Stop & Disable
them to allow us to Unpublish the package
Stop Package for User
Disable Package for User
74
13.5 DB_MC_Repair_Action.ps1
 The DB_MC_Repair_Action.ps1 powershell script is executed by MC7 Repair action.

 Its purpose is to repair the integration points of the package for the User and wipe any
application data.
 If the package is a member of any connection groups enabled to the user then we must
instead repair the connection group with the lowest Priority number.
 The action scope will always be scope=”user” for App-V 5.
o When initiated by the User via the MC7 console
o Via mcCLInt.


User manifest

6. # Code Execution
 Before we can repair the package we must establish if the package is a member of
any connection groups that are enabled to the current user. If it is then the package
will not be launching in its own virtual environment but in the VE of the connection
group.
 If the package is a member of more than one connection group then the application
will be launching in the VE of the enabled connection group with the lowest priority
number (i.e. highest priority).
 We will also need to consider the possibility that the package or connection group it
is launched in is in use by the user and present a message dialog where appropriate.
75
 In order to get this information we will run the Get-
EnabledConnectionGroupLowPriority function.
Function Get-EnabledConnectionGroupLowPriority
o Get all connection groups, enabled & disabled.
o Cycle through each connection group and test for a match with the package
we are repairing.
o When complete, order the found connection groups by Priority number and
the select the lowest
o Return the connection group object if one found.
 If a connection group was returned then we will check if it’s in use by the user.
 If it is in use then we must present a dialog to the user containing a list of the
running virtual processes belonging to the connection group members requesting
shut down of them before we can repair. Note: we must stop the package before we
can repair it (potential loss of unsaved data) and also the user should be made
aware that they will lose all application user preferences of not only the package,
but all member packages if it is indeed a connection group we are repairing.
 To achieve this we will run the Get-ConnectionGroupRunningProcessList
function to gain the application friendly name list of the connection group members.
Function Get-ConnectionGroupRunningProcessList
o Get a list of the virtual process descriptions for all running virtual processes
who’s VirtualEnvironmentVersion match our connection group versionid and
are running under the users Sid.
o Gather all the application names into an array and return.
 Next we pass these application names to the GenerateFormBig function.

 This will present the following dialog to the user.
Connection Group member Package (parent or child) Repair - (with two CG apps already
launched).
76
 If the User chooses to continue then the StopRepair-ConnectionGroup function is
called. This will stop the connection group VE for the User and repair the connection
group for the user.
 Script completion
 If it was found that the package was not a member of any enabled connection
groups the Repair-Package function would have been called.
Function Repair-Package
o Creates package object and ensures the package is published to the current
user.
o Checks if the package is in use by the user and if so presents a dialog
Package Repair (App already in a launched state)
o If the user chooses to continue then we stop and repair the package for the
User.
o If the package was not in use by the user we will still present a dialog
informing the user
Package Repair (App not in a launched state)
o If the user chooses to continue then we stop and repair the package for the
User.
o We exit the script with a 0 whether a repair has taken place or not.
77
DB_MC_Repair_Action MC7 UI – User initiated Repair

%AppData%\Deutsche Bank\MC7\
ManagedApps\Registry\<group>\
Get PCMODELTYPE
PCMODELTYPE = PCMODELTYPE = “RDSDESKTOPS”, “VIRTUALDESKTOP”,

“RDSAPPLICATIONS” “DESKTOP”, “NOTEBOOK”,, “BLADEWORKSTATION”
Abort (Exit 0)
Is the package a member of any

Connection groups Enabled to
the Current User?
Yes
Get Connection group with

Exit 1
the lowest priority #
no
Present dialog asking to close a

Is this Connection Group
Yes list of virtual processes and loss
in use by the User?
of AppData. Continue?
No
No
Yes
Stop & Repair Connection
Group for User
Is package Published to the User? No Exit 1
no
Yes
Present dialog asking to close

Is package in use by the
Yes package and loss of AppData.
User?
Continue?
No
Present dialog informing of loss

Exit 1 No
of AppData. Continue?
Yes
Yes
Repair Package for User
78
13.6 DB_MC_Uninstall_Action.ps1
 The DB_MC_Uninstall_Action.ps1 powershell script is executed by MC7 Uninstall action.

 Its purpose is to remove all versions of the appv package from the machine (based on
PackageId).
 If the package is a child member of any connection groups enabled to the user then we
will inform the user of the Parent applications they must uninstall first.
 If the package is a connection group parent package then we will remove all connection
group containing our GroupId before removing the package(s).
 The action scope will always be scope=”machine” for App-V 5 therefore we must be
certain the Uninstall is User initiated before presenting any dialogs.
o When initiated by the User via the MC7 console
o Via mcCLInt.


3. # Load Manifest.xml from %LOCALMACHINEPACKAGEROOT% folder and retrieve appv

related information
 The manifest referenced sits in the folder from which this script is executing which
will be the “C:\ProgramData\Deutsche
 The following information is retrieved from the manifest.
#Package Data
#Appv5 Data
#Appv5 Connection Group Data
The manifest loaded sits in the same folder from which this script is executed which
will be “C:\ProgramData\Deutsche
1.
79
4. # Establish type of uninstall (single Package or Connection Group Parent Package)
an $IninstallType = “CGUninstall” else it’s a “PKGUninstall”
 This $UninstallType value will be used for decision making later.

7. # Create package and connection group objects

machine manifest.
$versionid -All
 Note: we use the –All switch above because the Lock action script will have run
before this action and will have already unpublished the package.
 If the this is a “CGUninstall” then create the connection group object based on the
following command Get-AppvClientConnectionGroup -GroupId $connectiongroupid -
All
 If more than one connection group is found with this connectiongroupid then we
will
MC7 Workaround
When a User initiates an Uninstall from the MC7 console the first action to run is the
Lock action. This will disable to the user all CG’s the package is a member of and then
unpublish the package. We exactly define the package we are removing as we have
possession of the packageId & versionId but defining the connection group proves more
difficult as we only have the groupId to work with. We therefore will remove all
connection groups that contain our package as they are of no use if our package is not
present.
This behaviour differs for mcCLInt Uninstalls as the Lock action will not be run for the
user prior to the Uninstall script executing.
80
The default code block currently includes all PCMODELTYPE’s except RDSAPPLICATIONS and
RDSDESKTOPS. If the PCMODELTYPE is found to be RDSDESKTOPS then we abort the script after
logging this fact it’s not supported on this platform.
 Firstly we check if this is a “PKGUninstall” or if it’s a “CGUninstall”.

 If it’s a “PKGInstall” then we must next check to see if the package was a child member
of any connection groups on the client as we cannot remove the package whilst is
remains in a connection group which is enabled or disabled.
 Here we call the IsPackageConnectionGroupChildMember function.
Function IsPackageConnectionGroupChildMember
o The purpose of this function is to get the Connection group Parent package
Application “friendly” names of all connection groups enabled or disabled that our
package is a child member of and return them (assuming the script is
$UserInitiated). If the action is not $UserInitiated then the function will return just
the number of connection group matches.
o Get all the connection groups on the client enabled or disabled to the current user.
If this is a “CGUninstall” we will exclude our own connectiongroupid from the
search.
o Cycle through each discovered connection group and search its members for a
match with our package based on packageid & versionid.
o Count every CG match and then extract the Parent package Group name from the
connection group name, use this to locate the parent packages manifest.xml in
%ProgramData% to get the application friendly name.
$CGParentPackageManifest = $env:programdata + "\Deutsche

Bank\MC7\ManagedApps\Registry\" + $CGParentGroupName +
"\manifest.xml"
NOTE
This section of code is reliant on a standard for Connection group name of

{AppGroupName}_ConnectionGroup which will be the case based on the
Install/Update scripts code.
o Return a list of Unique Parent package application “friendly” names or

“NoneFound”.
Function IsUserInitiated
o The purpose of this function is to determine if the powershell script process is User
initiated i.e. executed by MC7 (mcADA.exe) or not.
81
o If it’s not mcADA.exe then the likelihood is it will be mcCLInt but this is not of
concern as we just need to establish if the action has been initiated by the User via
the MC7 console.
o We will check the parent and grandparent processes running our powershell script
to see if either matches “mcADA”.
o We then set the $UserInitiated variable to $true or $false depending on the result.
$UserInitiated will be used later for decision making. E.g. to decide if we can present
User dialogs.
In order to determine if the execution of this script is User driven via MC7
console or not we check to see if one of the parent/grandparent processes are
mcADA.
 If matches were found and the script is $UserInitiated then we will present a dialog to the
User using the GenerateForm function informing them that the Listed connection group
parent applications must to be uninstalled first.
Connection Group child member Uninstall
 We will then Exit with 1 as we have not removed the package and we must ensure MC7
recognises this fact or else it will remove its package registration and components.
 If no connection group matches were found then we execute the RemovePackages function.
Function RemovePackages
o This function will remove all minor versions of our package.
o If the package is in use by anyone we will abort the package removal to prevent loss
of user data. Note: The package will already be stopped for the current user for a
UserInitiated Uninstall as the Lock action will have handled it for the current user.
o If the package is published to the current user then (it won’t be for a $Userinitiated
Uninstall as the Lock action will have unpublished it first) Unpublish the package.
o We have chosen not to repair the package before unpublishing in case the user data
is required on another machine by that user.
82
o Next we remove all versions of the package from the machine using the $PackageId.
o Delete the package local cache folder if its empty
o Default: “$Env:ProgramData + "\App-V\" + $packageid”
o RDSDESKTOPS & RDSAPPLICATIONS: "E:\AppV5Cache\" + $packageid”
o Exit the script with 0 for success.
Appv5 workaround
After the removal of a package we will delete the package cache if it’s empty as the
appvclient neglects to do so.
a. Default: "%ProgramData%\App-V\<PackageID>"
b. RDSDESKTOPS & RDSAPPLICATIONS: "E:\AppV5Cache\<PackageID>"
 If we return to the beginning of this code block and it is confirmed this is a “CGInstall” we
will again run the IsPackageConnectionGroupChildMember function which will return a
list of connection group parent package friendly names or “NoneFound
 If no matches were returned then we will call the RemoveConnectionGroups function.
Function RemoveConnectionGroups
o This function will remove all connection groups containing our connectiongroupid.
o If the CG is in use by anyone then we abort the script with Exit code 1 to prevent any
possibility of User data loss.
o If the CG is enabled to the user then disable it. For an MC7 driven uninstall the lock
action will have already disabled the CG but for a mcCLInt removal this may not be
the case.
o Remove all connection groups containing our $GroupId. (If we are removing a
member package then there is no requirement for any CG containing this package to
exist.)
o Delete the connection group descriptor file under $Env:ProgramData + "\App-
V\DB_ConnectionGroups\" + $ConnectionGroupObj.groupid + "_" +
$ConnectionGroupObj.versionid +".xml"
 Following this we execute the RemovePackages function which was described earlier.
 If matches were found and if the script is $UserInitiated we will present the same dialog as
before to the user and if not we abort the script with Exit code 1.
83
 The code for this platform is essentially the same except we do not offer any user
dialogs as Uninstalls will never be actioned by a User (typically just using mcCLInt).
 As all packages are globally published and connection groups are globally enabled on
the AOD2 platform we must consequently globally unpublish packages and globally
disable connections groups as part of this script
PCMODELTYPE = “RDSDESKTOPS”
 Package and Connection group removals are not currently supported on this
platform. We log out the following statement. "We don't currently offer
Package Removals on the RDSDESKTOPS platform. Aborting.."
 Exit 1
84
DB_MC_Uninstall_Action
MC7 GUI - Uninstall Clint/PREPOP - Uninstall
RDSDESKTOPS Users will not be offered an Uninstall

ROFS
PCMODELTYPE =
PCMODELTYPE = “NOTEBOOK”,
“RDSAPPLICATION” “VIRTUALDESKTOP”,
“DESKTOP”
Exit 1
Yes
Is this package a child member of Is this package a child member of

Is this package a Connection Is this package a Connection
any other connection groups on No No any other connection groups on
Group Parent? Group Parent?
the client? the client?
Yes Yes Yes
Present UI to potential User informing

them which parent packages they must
Is package a member of a Is package a member of a
Uninstall before attempting to Uninstall
Connection Group other than the Yes Exit 1 Connection Group other than the Yes
this one. A timeout shall abort the
one it manages? one it manages?
execution (which should satisfy clint/
prepop)
No No
Yes
Are any connection groups with Are any connection groups with
Yes Exit 1
our connectiongroupid in use? our connectiongroupid in use?
No No
Disable All Connection Disable All Connection

Groups that contain our Groups that contain our
No connectiongroupid Globally connectiongroupid
No
Remove All Connection

Groups that contain our
connectiongroupid & Remove All Connection
delete their CG.xml Groups that contain our
connectiongroupid &
delete their CG.xml
Stop all versions of

Stop all versions of
Package
Package
Globally
Unpublish all versions of

Unpublish all versions of
Package
Package
Globally
Remove all versions of Remove all versions of

Package Package
Delete package cache Delete package cache

folder if empty folder if empty
85
14 Managed Client Action flow diagrams
 The above scripts and the logic contained within them have had to consider the
action sequencing for the existing Managed Client (v7.2 & 7.3).
 The following are the action sequencing flow diagrams as discovered during our
testing and for which we have coded the powershell installation scripts.
86
MC 7.2 Install/Update Action
Sequencing
MC7 UI - Install MC7 UI - Update
Manifest Manifest
Dependencies? Dependencies?
Yes Yes
Dependencies Install Action – M/C Dependencies Install Action – M/C

Scope Scope
No No
Dependencies Install Action – User Dependencies Install Action – User

Scope Scope
Dependencies Unlock Action Dependencies Unlock Action

– User Scope – User Scope
Install Action – M/C Scope Update Action – M/C Scope
Install Action – User Scope Update Action – User Scope
Unlock Action – User Scope Unlock Action – User Scope
User Entitlement Refresh i.e. User Entitlement Refresh i.e.

Unlock of all packages Unlock of all packages
87
MC 7.2 Repair Actions
MC7 UI - Repair
Repair Action
– User Scope
Unlock Action
– User Scope
User Entitlement Refresh i.e.

Unlock/Lock
88
MC 7.2 Uninstall Action
& Reinstall
MC7 UI - Uninstall
Lock Action
– User Scope
Note: The dependency package is not

Uninstalled, just Locked (unpublished) for
the User
Uninstall Action
– m/c Scope Only
Dependency Lock Action Is User in AD group Are there Manifest

No Yes
– User Scope for dependency ? Dependencies?
Yes
Exit
MC7 UI - ReInstall
Install Action
– m/c Scope
Install Action
– user Scope
Unlock Action
– user Scope
This behaviour differs from a fresh install

in that the dependency Unlock is
occurring after the parent Unlock.
Dependency UnLock Action

– User Scope
User Entitlement Refresh i.e.

Unlock/Lock of both packages
89

Appv Low Level Design

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Appv Low Level Design

Diunggah oleh

Hak Cipta:

Format Tersedia

App-V 5

Low Level Design

Reference Architecture Specification

Date: 25th July 2014

Author(s): Mark Charles

Document Status: Draft

For further information please contact:

Name Title Section(s) Purpose Complete

Document Sign Off

Name Title Date Signature

1.1 Background ............................................................................................................................. 7

1.2 Objective ................................................................................................................................. 7

1.3 High Level Requirements ........................................................................................................ 7

1.4 Scope ....................................................................................................................................... 7

2 Target Platforms ............................................................................................................................. 8

2.1 PCMODELTYPE ........................................................................................................................ 8

3 App-V 5 SP2 Client Configurations per Platform Type .................................................................... 9

3.2 Common App-V 5 SP2 Client Configuration Settings ............................................................ 10

3.3 AutoLoad Setting................................................................................................................... 11

3.4 PackageStoreAccessControl Setting...................................................................................... 11

4 App-V 5 SP2 Client Configuration - Group Policy Setting.............................................................. 12

4.1 MDOP ADMX Template......................................................................................................... 12

5 ROFS Configuration for App-V 5.................................................................................................... 14

5.1 Package Streaming ................................................................................................................ 14

5.2 SMB Streaming Configuration............................................................................................... 14

5.3 HTTP Streaming Configuration.............................................................................................. 15

6 App-V 5 Sequencing ...................................................................................................................... 16

7 App-V 5 Powershell Modules and Cmdlets................................................................................... 17

7.1 The App-V AppVPkgConverter Module ................................................................................ 17

7.2 The App-V Client Module ...................................................................................................... 17

7.3 The App-V 5 Event Logging ................................................................................................... 18

8 App-V 5 – New Features ............................................................................................................... 19

8.2 Dynamic Deployment Configuration..................................................................................... 23

9 App-V 5 – Connection Groups....................................................................................................... 31

9.1 Connection Group Descriptor XML ....................................................................................... 31

9.2 App-V 5 Connection Group Powershell Cmdlets .................................................................. 32

9.3 Areas to Consider .................................................................................................................. 33

10 App-V 5 – Roaming User Environments ........................................................................................ 36

10.1 Registry Based Data .............................................................................................................. 36

10.2 File Based Data ...................................................................................................................... 37

10.3 Package Catalogs................................................................................................................... 38

10.3.1 Machine Catalog ........................................................................................................... 38

10.5 RDS Platform Configuration (AOD2 & DOD Lite) .................................................................. 40

11 App-V 5 – MC7 Delivery ................................................................................................................ 41

11.1 App-V 5 Package types .......................................................................................................... 41

12 MC7 Manifest Schema for App-V 5............................................................................................... 42

12.1 <appv> Section ...................................................................................................................... 42

12.3 Standard App-V 5 Package Artefacts .................................................................................... 44

12.4 <actions> Section .................................................................................................................. 45

12.5 <unlocktargets> and <locktargets> Sections ...................................................................... 49

13 Manifest Powershell Scripts for App-V 5 ...................................................................................... 50

13.2 DB_MC_Update_Action.ps1 ................................................................................................. 58

13.3 DB_MC_Unlock_Action.ps1 .................................................................................................. 66

13.4 DB_MC_Lock_Action.ps1 ...................................................................................................... 72

13.5 DB_MC_Repair_Action.ps1 ................................................................................................... 75

13.6 DB_MC_Uninstall_Action.ps1 ............................................................................................... 79

1.3 High Level Requirements

Platform PCMODELTYPE Value

About Client Configuration Settings

3.1 App-V 5 SP2 Client Configuration Settings differences per platform.

3.4 PackageStoreAccessControl Setting

PackageStoreAccessControl - Restricting Access to the Package Cache in App-V 5.0

4.1 MDOP ADMX Template