deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-15 02:13:43 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Formatting for application publishing and client interaction article

Browse Source
This commit is contained in:
Heidi Lohr
2018-04-19 14:43:10 -07:00
parent 2eeab188ab
commit cf74f93f48
2 changed files with 272 additions and 331 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
windows/application-management/app-v/appv-allow-administrators-to-enable-connection-groups.md
View File

@ -8,54 +8,26 @@ ms.sitesec: library
ms.prod: w10
ms.date: 04/19/2017
---
# How to allow only administrators to enable connection groups
>Applies to: Windows 10, version 1607
# How to Allow Only Administrators to Enable Connection Groups
You can configure the App-V client so that only administrators, not users, can enable or disable connection groups. In earlier versions of App-V, there was no way to restrict access to disabling connection groups to users.
**Applies to**
- Windows 10, version 1607
You can configure the App-V client so that only administrators (not end users) can enable or disable connection groups. In earlier versions of App-V, you could not prevent end users from performing these tasks.
**Note**<br>
This feature is supported starting in App-V 5.0 SP3.
>[!NOTE]
>This feature is supported starting in App-V 5.0 SP3.
Use one of the following methods to allow only administrators to enable or disable connection groups.
<table>
<colgroup>
<col width="30%" />
<col width="70%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Method</th>
<th align="left">Steps</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Group Policy setting</p></td>
<td align="left"><p>Enable the “Require publish as administrator” Group Policy setting, which is located in the following Group Policy Object node:</p>
<p><strong>Computer Configuration &gt; Administrative Templates &gt; System &gt; App-V &gt; Publishing</strong></p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows PowerShell cmdlet</p></td>
<td align="left"><p>Run the <strong>Set-AppvClientConfiguration</strong> cmdlet with the <strong>-RequirePublishAsAdmin</strong> parameter.</p>
<p>Parameter values:</p>
<ul>
<li><p>0 - False</p></li>
<li><p>1 - True</p></li>
</ul>
<p>Example: <strong>Set-AppvClientConfiguration -RequirePublishAsAdmin 1</strong></p></td>
</tr>
</tbody>
</table>
|Method|Steps|
|---|---|
|Group Policy setting|Enable the “Require publish as administrator” Group Policy setting, which is located in the following Group Policy Object node:<br><br>**Computer Configuration** > **Administrative Templates** > **System** > **App-V** > **Publishing**|
|Windows PowerShell cmdlet|Run the **Set-AppvClientConfiguration** cmdlet with the *-RequirePublishAsAdmin* parameter. <br><br>Parameter values:<br>- **0** – False<br>- **1** – True<br><br>Example: ```Set-AppvClientConfiguration -RequirePublishAsAdmin 1```|
## Have a suggestion for App-V?
Add or vote on suggestions on the [Application Virtualization feedback site](https://appv.uservoice.com/forums/280448-microsoft-application-virtualization).<br>For App-V issues, use the [App-V TechNet Forum](https://social.technet.microsoft.com/Forums/en-US/home?forum=mdopappv).
Add or vote on suggestions on the [Application Virtualization feedback site](https://appv.uservoice.com/forums/280448-microsoft-application-virtualization).
## Related topics
[Managing Connection Groups](appv-managing-connection-groups.md)
- [Managing Connection Groups](appv-managing-connection-groups.md)

553
windows/application-management/app-v/appv-application-publishing-and-client-interaction.md
View File

@ -1,6 +1,6 @@
---
title: Application Publishing and Client Interaction (Windows 10)
description: Application Publishing and Client Interaction
description: Application publishing and client interaction.
author: MaggiePucciEvans
ms.pagetype: mdop, appcompat, virtualization
ms.mktglfcycl: deploy
@ -8,20 +8,26 @@ ms.sitesec: library
ms.prod: w10
ms.date: 04/19/2017
---
# Application publishing and client interaction
# Application Publishing and Client Interaction
**Applies to**
- Windows 10, version 1607
>Applies to: Windows 10, version 1607
This article provides technical information about common App-V client operations and their integration with the local operating system.
## App-V package files created by the Sequencer
The Sequencer creates App-V packages and produces a virtualized application. The sequencing process creates the following files:
|File|Description|
|---|---|
|.appv|- The primary package file, which contains the captured assets and state information from the sequencing process.<br>- Architecture of the package file, publishing information, and registry in a tokenized form that can be reapplied to a machine and to a specific user upon delivery.|
|.MSI|Executable deployment wrapper that you can use to deploy .appv files manually or by using a third-party deployment platform.|
|_DeploymentConfig.XML|File used to customize the default publishing parameters for all applications in a package that is deployed globally to all users on a computer that is running the App-V client.|
|_UserConfig.XML|File used to customize the publishing parameters for all applications in a package that is a deployed to a specific user on a computer that is running the App-V client.|
|Report.xml|Summary of messages resulting from the sequencing process, including omitted drivers, files, and registry locations.|
|.CAB|Optional: Package accelerator file used to automatically rebuild a previously sequenced virtual application package.|
|.appvt|Optional: Sequencer template file used to retain commonly reused Sequencer settings.|
<table>
<colgroup>
<col width="30%" />
@ -72,7 +78,6 @@ For information about sequencing, see [How to Sequence a New Application with Ap
## What’s in the appv file?
The appv file is a container that stores XML and non-XML files together in a single entity. This file is built from the AppX format, which is based on the Open Packaging Conventions (OPC) standard.
To view the appv file contents, make a copy of the package, and then rename the copied file to a ZIP extension.
@ -80,7 +85,7 @@ To view the appv file contents, make a copy of the package, and then rename the
The appv file contains the following folder and files, which are used when creating and publishing a virtual application:
| Name | Type | Description |
| - | - | - |
|---|---|---|
| Root | File folder | Directory that contains the file system for the virtualized application that is captured during sequencing. |
| [Content_Types].xml | XML File | List of the core content types in the appv file (e.g. DLL, EXE, BIN). |
| AppxBlockMap.xml | XML File | Layout of the appv file, which uses File, Block, and BlockMap elements that enable location and validation of files in the App-V package.|
@ -90,14 +95,12 @@ The appv file contains the following folder and files, which are used when creat
| Registry.dat | DAT File | Registry keys and values captured during the sequencing process for the package.|
| StreamMap.xml | XML File | List of files for the primary and publishing feature block. The publishing feature block contains the ICO files and required portions of files (EXE and DLL) for publishing the package. When present, the primary feature block includes files that have been optimized for streaming during the sequencing process.|
 
## App-V client data storage locations
The App-V client performs tasks to ensure that virtual applications run properly and work like locally installed applications. The process of opening and running virtual applications requires mapping from the virtual file system and registry to ensure the application has the required components of a traditional application expected by users. This section describes the assets that are required to run virtual applications and lists the location where App-V stores the assets.
| Name | Location | Description |
| - | - | - |
|---|---|---|
| Package Store | %ProgramData%\App-V| Default location for read only package files|
| Machine Catalog | %ProgramData%\Microsoft\AppV\Client\Catalog| Contains per-machine configuration documents|
| User Catalog | %AppData%\Microsoft\AppV\Client\Catalog| Contains per-user configuration documents|
@ -126,21 +129,26 @@ To change the default location of the package store during setup, see [Enable th
If the App-V Client is configured in Shared Content Store mode, no data is written to disk when a stream fault occurs, which means that the packages require minimal local disk space (publishing data). The use of less disk space is highly desirable in VDI environments, where local storage can be limited, and streaming the applications from a high performance network location (such as a SAN) is preferable. For more information, see [Shared Content Store in Microsoft App-V 5.0 - Behind the Scenes](https://blogs.technet.microsoft.com/appv/2013/07/22/shared-content-store-in-microsoft-app-v-5-0-behind-the-scenes/).
> [!NOTE]
> [!NOTE]
> The machine and package store must be located on a local drive, even when you’re using Shared Content Store configurations for the App-V Client.
 
### Package catalogs
The App-V Client manages the following two file-based locations:
- **Catalogs (user and machine).**
- **Registry locations** - depends on how the package is targeted for publishing. There is a Catalog (data store) for the computer, and a catalog 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 for both file and registry per package version. 
- **Catalogs (user and machine).**
- **Registry locations**—depends on how the package is targeted for publishing. There is a Catalog (data store) for the computer, and a catalog 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 for both file and registry per package version. 
### Machine catalog
|||
|---|---|
|Description|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.<br></br>If a package is non-global, the integrations are published only for specific users, but there are still global resources that are modified and visible to anyone on the client computer (such as when the package directory is in a shared disk location).<br></br>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 is defined according to whether there is a policy file (UserDeploymentConfiguration file) in the Machine Catalog.|
|Default storage location|```%programdata%\Microsoft\AppV\Client\Catalog\```<br></br>This location is not the same as the Package Store location. The Package Store is the golden or pristine copy of the package files.|
|Files in the machine catalog|- Manifest.xml<br>- DeploymentConfiguration.xml<br>- UserManifest.xml (Globally Published Package)<br>- UserDeploymentConfiguration.xml (Globally Published Package)|
|Additional machine catalog location, used when the package is part of a connection group|The following location is in addition to the specific package location mentioned previously as the default storage location:<br></br>```%programdata%\Microsoft\AppV\Client\Catalog\PackageGroups\ConGroupGUID\ConGroupVerGUID```|
|Additional files in the machine catalog when the package is part of a connection group|- PackageGroupDescriptor.xml<br>- UserPackageGroupDescriptor.xml (globally published Connection Group)|
<table>
<colgroup>
<col width="50%" />
@ -182,10 +190,16 @@ The App-V Client manages the following two file-based locations:
</tbody>
</table>
 
### User catalog
|||
|---|---|
|Description|Created during the publishing process. Contains information used for publishing the package, and also used at launch to ensure that a package is provisioned to a specific user. Created in a roaming location and includes user-specific publishing information.<br></br>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 that the package is entitled for that user.<br></br>For roaming users, the User Catalog needs to be in a roaming or shared location to preserve the legacy App-V behavior of targeting users by default. Entitlement and policy are tied to a user, not a computer, so they should roam with the user once they are provisioned.|
|Default storage location|```appdata\roaming\Microsoft\AppV\Client\Catalog\Packages\PkgGUID\VerGUID```|
|Files in the user catalog|- UserManifest.xml<br>- DynamicConfiguration.xml or UserDeploymentConfiguration.xml|
|Additional user catalog location, used when the package is part of a connection group|The following location is in addition to the specific package location mentioned above:<br></br>```appdata\roaming\Microsoft\AppV\Client\Catalog\PackageGroups\PkgGroupGUID\PkgGroupVerGUID```|
|Additional file in the machine catalog when the package is part of a connection group|```UserPackageGroupDescriptor.xml```|
<table>
<colgroup>
<col width="50%" />
@ -221,11 +235,9 @@ The App-V Client manages the following two file-based locations:
</tbody>
</table>
 
### Shortcut backups
During the publishing process, the App-V Client backs up any shortcuts and integration points to `%AppData%\Microsoft\AppV\Client\Integration\ShortCutBackups.` This backup enables the restoration of these integration points to the previous versions when the package is unpublished.
During the publishing process, the App-V Client backs up any shortcuts and integration points to ```%AppData%\Microsoft\AppV\Client\Integration\ShortCutBackups```. This backup enables the restoration of these integration points to the previous versions when the package is unpublished.
### Copy on Write files
@ -239,17 +251,15 @@ The COW Roaming location described above stores changes to files and directories
The COW Local location is similar to the roaming location, but the directories and files are not roamed to other computers, even if roaming support has been configured. The COW Local location described above stores changes applicable to typical windows and not the %AppData% location. The directories listed will vary but there will be two locations for any typical Windows locations (e.g. Common AppData and Common AppDataS). The **S** signifies the restricted location when the virtual service requests the change as a different elevated user from the logged on users. The non-**S** location stores user based changes.
## <a href="" id="bkmk-pkg-registry"></a>Package registry
## Package registry
Before an application can access the package registry data, the App-V Client must make the package registry data available to the applications. The App-V Client uses the real registry as a backing store for all registry data.
When a new package is added to the App-V Client, a copy of the REGISTRY.DAT file from the package is created at `%ProgramData%\Microsoft\AppV\Client\VREG\{Version GUID}.dat`. The name of the file is the version GUID with the .DAT extension. The reason this copy is made is to ensure that the actual hive file in the package is never in use, which would prevent the removal of the package at a later time.
When a new package is added to the App-V Client, a copy of the REGISTRY.DAT file from the package is created at ```%ProgramData%\Microsoft\AppV\Client\VREG\{Version GUID}.dat```. The name of the file is the version GUID with the .DAT extension. The reason this copy is made is to ensure that the actual hive file in the package is never in use, which would prevent the removal of the package at a later time.
**Registry.dat from Package Store** > **%ProgramData%\Microsoft\AppV\Client\Vreg\\{VersionGuid}.dat**
 
When the first application from the package is launched on the client, the client stages or copies the contents out of the hive file, re-creating the package registry data in an alternate location `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages\PackageGuid\Versions\VersionGuid\REGISTRY`. The staged registry data has two distinct types of machine data and user data. Machine data is shared across all users on the machine. User data is staged for each user to a userspecific location `HKCU\Software\Microsoft\AppV\Client\Packages\PackageGuid\Registry\User`. The machine data is ultimately removed at package removal time, and the user data is removed on a user unpublish operation.
When the first application from the package is launched on the client, the client stages or copies the contents out of the hive file, re-creating the package registry data in an alternate location ```HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages\PackageGuid\Versions\VersionGuid\REGISTRY```. The staged registry data has two distinct types of machine data and user data. Machine data is shared across all users on the machine. User data is staged for each user to a userspecific location ```HKCU\Software\Microsoft\AppV\Client\Packages\PackageGuid\Registry\User```. The machine data is ultimately removed at package removal time, and the user data is removed on a user unpublish operation.
### Package registry staging vs. connection group registry staging
@ -267,6 +277,12 @@ There are two package registry locations and two connection group locations wher
**Single Package VReg:**
|Location|Description|
|---|---|
|COW|- Machine Registry\Client\Packages\PkgGUID\REGISTRY (Only elevate process can write)<br>- User Registry\Client\Packages\PkgGUID\REGISTRY (User Roaming anything written under HKCU except Software\Classes<br>- User Registry Classes\Client\Packages\PkgGUID\REGISTRY (HKCU\Software\Classes writes and HKLM for non elevated process)|
|Package|- Machine Registry\Client\Packages\PkgGUID\Versions\VerGuid\Registry\Machine<br>- User Registry Classes\Client\Packages\PkgGUID\Versions\VerGUID\Registry|
|Native|- Native application registry location|
<table>
<colgroup>
<col width="50%" />
@ -301,12 +317,14 @@ There are two package registry locations and two connection group locations wher
</tbody>
</table>
 
 
**Connection Group VReg:**
|Location|Description|
|---|---|
|COW|- Machine Registry\Client\PackageGroups\GrpGUID\REGISTRY (only elevate process can write)<br>- User Registry\Client\PackageGroups\GrpGUID\REGISTRY (Anything written to HKCU except Software\Classes)<br>- User Registry Classes\Client\PackageGroups\GrpGUID\REGISTRY|
|Package|- Machine Registry\Client\PackageGroups\GrpGUID\Versions\VerGUID\REGISTRY<br>- User Registry Classes\Client\PackageGroups\GrpGUID\Versions\VerGUID\REGISTRY|
|Native|- Native application registry location|
<table>
<colgroup>
<col width="50%" />
@ -341,41 +359,36 @@ There are two package registry locations and two connection group locations wher
</tbody>
</table>
 
 
There are two COW locations for HKLM; elevated and non-elevated processes. Elevated processes always write HKLM changes to the secure COW under HKLM. Non-elevated processes always write HKLM changes to the non-secure COW under HKCU\\Software\\Classes. When an application reads changes from HKLM, elevated processes will read changes from the secure COW under HKLM. Non-elevated reads from both, favoring the changes made in the unsecure COW first.
### Pass-through keys
Pass-through keys enable an administrator to configure certain keys so they can only be read from the native registry, bypassing the Package and COW locations. Pass-through locations are global to the machine (not package specific) and can be configured by adding the path to the key, which should be treated as pass-through to the **REG\_MULTI\_SZ** value called **PassThroughPaths** of the key `HKLM\Software\Microsoft\AppV\Subsystem\VirtualRegistry`. Any key that appears under this multi-string value (and their children) will be treated as pass-through.
Pass-through keys enable an administrator to configure certain keys so they can only be read from the native registry, bypassing the Package and COW locations. Pass-through locations are global to the machine (not package specific) and can be configured by adding the path to the key, which should be treated as pass-through to the **REG\_MULTI\_SZ** value called **PassThroughPaths** of the key ```HKLM\Software\Microsoft\AppV\Subsystem\VirtualRegistry```. Any key that appears under this multi-string value (and their children) will be treated as pass-through.
The following locations are configured as pass-through locations by default:
- HKEY\_CURRENT\_USER\\SOFTWARE\\Classes\\Local Settings\\Software\\Microsoft\\Windows\\CurrentVersion\\AppModel
- HKEY\_CURRENT\_USER\\SOFTWARE\\Classes\\Local Settings\\Software\\Microsoft\\Windows\\CurrentVersion\\AppModel
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Classes\\Local Settings\\Software\\Microsoft\\Windows\\CurrentVersion\\AppModel
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Classes\\Local Settings\\Software\\Microsoft\\Windows\\CurrentVersion\\AppModel
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WINEVT
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WINEVT
- HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\services\\eventlog\\Application
- HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\services\\eventlog\\Application
- HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\WMI\\Autologger
- HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\WMI\\Autologger
- HKEY\_CURRENT\_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings
- HKEY\_CURRENT\_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies
- HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies
- HKEY\_CURRENT\_USER\\SOFTWARE\\Policies
- HKEY\_CURRENT\_USER\\SOFTWARE\\Policies
The purpose of Pass-through keys is to ensure that a virtual application does not write registry data in the VReg that is required for non-virtual applications for successful operation or integration. The Policies key ensures that Group Policy based settings set by the administrator are utilized and not per package settings. The AppModel key is required for integration with Windows Modern UI based applications. It is recommend that administers do not modify any of the default pass-through keys, but in some instances, based on application behavior may require adding additional pass-through keys.
## App-V package store behavior
App-V manages the Package Store, which is the location where the expanded asset files from the appv file are stored. By default, this location is stored at %ProgramData%\\App-V, and is limited in terms of storage capabilities only by free disk space. The package store is organized by the GUIDs for the package and version as mentioned in the previous section.
### Add packages
@ -384,11 +397,19 @@ App-V Packages are staged upon addition to the computer with the App-V Client. T
### Mounting packages
Packages can be explicitly loaded using the Windows PowerShell `Mount-AppVClientPackage` or by using the **App-V Client UI** to download a package. This operation completely loads the entire package into the package store.
Packages can be explicitly loaded by entering the **Mount-AppVClientPackage** PowerShell cmdlet or by using the **App-V Client UI** to download a package. This operation completely loads the entire package into the package store.
### Streaming packages
The App-V Client can be configured to change the default behavior of streaming. All streaming policies are stored under the following registry key: `HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Client\Streaming`. Policies are set using the Windows PowerShell cmdlet `Set-AppvClientConfiguration`. The following policies apply to Streaming:
The App-V Client can be configured to change the default behavior of streaming. All streaming policies are stored under the following registry key: ```HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Client\Streaming```. Policies are set by entering the **Set-AppvClientConfiguration** PowerShell cmdlet. The following policies apply to streaming:
|Policy|Description|
|---|---|
|AllowHighCostLaunch|Allows streaming over 3G and cellular networks|
|AutoLoad|Specifies the Background Load setting:<br>**0** – Disabled<br>**1** – Previously Used Packages only<br>**2** – All Packages|
|PackageInstallationRoot|The root folder for the package store in the local machine|
|PackageSourceRoot|The root override where packages should be streamed from|
|SharedContentStoreMode|Enables the use of Shared Content Store for VDI scenarios|
<table>
<colgroup>
@ -428,21 +449,15 @@ The App-V Client can be configured to change the default behavior of streaming.
</tbody>
</table>
 
 
These settings affect the behavior of streaming App-V package assets to the client. By default, App-V only downloads the assets required after downloading the initial publishing and primary feature blocks. There are three specific behaviors around streaming packages that must be explained:
- Background Streaming
- Optimized Streaming
- Stream Faults
- Background Streaming
- Optimized Streaming
- Stream Faults
### Background streaming
The Windows PowerShell cmdlet `Get-AppvClientConfiguration` can be used to determine the current mode for background streaming with the AutoLoad setting and modified with the cmdlet Set-AppvClientConfiguration or from the registry (HKLM\\SOFTWARE\\Microsoft\\AppV\\ClientStreaming key). Background streaming is a default setting where the Autoload setting is set to download previously used packages. The behavior based on default setting (value=1) downloads App-V data blocks in the background after the application has been launched. This setting can be disabled all together (value=0) or enabled for all packages (value=2), whether they have been launched.
The Windows PowerShell cmdlet ```Get-AppvClientConfiguration``` can be used to determine the current mode for background streaming with the AutoLoad setting and modified with the cmdlet Set-AppvClientConfiguration or from the registry (HKLM\\SOFTWARE\\Microsoft\\AppV\\ClientStreaming key). Background streaming is a default setting where the Autoload setting is set to download previously used packages. The behavior based on default setting (value=1) downloads App-V data blocks in the background after the application has been launched. This setting can be disabled all together (value=0) or enabled for all packages (value=2), whether they have been launched.
### Optimized streaming
@ -454,36 +469,37 @@ After the initial stream of any publishing data and the primary feature block, r
### Package upgrades
App-V Packages require updating throughout the lifecycle of the application. App-V Package upgrades are similar to the package publish operation, as each version will be created in its own PackageRoot location: `%ProgramData%\App-V\{PkgGUID}\{newVerGUID}`. The upgrade operation is optimized by creating hard links to identical- and streamed-files from other versions of the same package.
App-V Packages require updating throughout the lifecycle of the application. App-V Package upgrades are similar to the package publish operation, as each version will be created in its own PackageRoot location: ```%ProgramData%\App-V\{PkgGUID}\{newVerGUID}```. The upgrade operation is optimized by creating hard links to identical- and streamed-files from other versions of the same package.
### Package removal
The behavior of the App-V Client when packages are removed depends on the method used for removal. Using an App-V full infrastructure to unpublish the application, the user catalog files (machine catalog for globally published applications) are removed, but retains the package store location and COW locations. When the Windows PowerShell cmdlet `Remove-AppVClientPackge` is used to remove an App-V Package, the package store location is cleaned. Remember that unpublishing an App-V Package from the Management Server does not perform a Remove operation. Neither operation will remove the Package Store package files.
## <a href="" id="bkmk-roaming-reg-data"></a>Roaming registry and data
The behavior of the App-V Client when packages are removed depends on the method used for removal. Using an App-V full infrastructure to unpublish the application, the user catalog files (machine catalog for globally published applications) are removed, but retains the package store location and COW locations. When the Windows PowerShell cmdlet ```Remove-AppVClientPackge``` is used to remove an App-V Package, the package store location is cleaned. Remember that unpublishing an App-V Package from the Management Server does not perform a Remove operation. Neither operation will remove the Package Store package files.
## Roaming registry and data
App-V is able to provide a near-native experience when roaming, depending on how the application being used is written. By default, App-V roams AppData that is 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 computer to computer, since they are in locations that are not roamed.
### <a href="" id="bkmk-clt-inter-roam-reqs"></a>Roaming requirements and user catalog data storage
### Roaming requirements and user catalog data storage
App-V stores data, which represents the state of the user’s catalog, in the form of:
- Files under %appdata%\\Microsoft\\AppV\\Client\\Catalog
- Registry settings under `HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages`
- Files under %appdata%\\Microsoft\\AppV\\Client\\Catalog
- Registry settings under `HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages`
Together, these files and registry settings represent the user’s catalog, so either both must be roamed, or neither must be roamed for a given user. App-V does not support roaming %AppData%, but not roaming the user’s profile (registry), or vice versa.
> [!NOTE]
> The **Repair-AppvClientPackage** cmdlet does not repair the publishing state of packages, where the user’s App-V state under `HKEY_CURRENT_USER` is missing or mismatched with the data in %appdata%.
 
>[!NOTE]
>The **Repair-AppvClientPackage** cmdlet does not repair the publishing state of packages, where the user’s App-V state under `HKEY_CURRENT_USER` is missing or mismatched with the data in %appdata%.
### Registry-based data
App-V registry roaming falls into two scenarios, as shown in the following table.
|Scenario|Description|
|---|---|
|Applications that are run as standard users|When a standard user launches an App-V application, both HKLM and HKCU for App-V applications are stored in the HKCU hive on the machine. This presents as two distinct paths:<br>- HKLM: HKCU\SOFTWARE\Classes\AppV\Client\Packages\\{PkgGUID}\REGISTRY\MACHINE\SOFTWARE<br>- HKCU: HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\REGISTRY\USER\\{UserSID}\SOFTWARE<br>The locations are enabled for roaming based on the operating system settings.|
|Applications that are run with elevation|When an application is launched with elevation:<br>- HKLM data is stored in the HKLM hive on the local computer<br>- HKCU data is stored in the User Registry location<br>In this scenario, these settings are not roamed with normal operating system roaming configurations, and the resulting registry keys and values are stored in the following location:<br>- HKLM\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\\{UserSID}\REGISTRY\MACHINE\SOFTWARE<br>- HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\\Registry\User\\{UserSID}\SOFTWARE|
<table>
<colgroup>
<col width="25%" />
@ -521,8 +537,6 @@ App-V registry roaming falls into two scenarios, as shown in the following table
</tbody>
</table>
 
### App-V and folder redirection
App-V supports folder redirection of the roaming AppData folder (%AppData%). When the virtual environment is started, the roaming AppData state from the user’s roaming AppData directory is copied to the local cache. Conversely, when the virtual environment is shut down, the local cache that is associated with a specific user’s roaming AppData is transferred to the actual location of that user’s roaming AppData directory.
@ -532,7 +546,7 @@ A typical package has several locations mapped in the user’s backing store for
The following table shows local and roaming locations, when folder redirection has not been implemented.
| VFS directory in package | Mapped location of backing store |
| - | - |
|---|---|
| ProgramFilesX86 | C:\Users\Local\AppData\Local\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\ProgramFilesX86 |
| SystemX86 | C:\Users\username\AppData\Local\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\SystemX86 |
| Windows | C:\Users\username\AppData\Local\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\Windows |
@ -542,64 +556,48 @@ The following table shows local and roaming locations, when folder redirection h
The following table shows local and roaming locations, when folder redirection has been implemented for %AppData%, and the location has been redirected (typically to a network location).
| VFS directory in package | Mapped location of backing store |
| - | - |
|---|---|
| ProgramFilesX86 | C:\Users\Local\AppData\Local\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\ProgramFilesX86 |
| SystemX86 | C:\Users\Local\AppData\Local\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\SystemX86 |
| Windows | C:\Users\Local\AppData\Local\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\Windows |
| appv_ROOT | C:\Users\Local\AppData\Local\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\appv\_ROOT |
| AppData | \\Fileserver\users\Local\roaming\Microsoft\AppV\Client\VFS\\&lt;GUID&gt;\AppData |
 
The current App-V Client VFS driver cannot write to network locations, so the App-V Client detects the presence of folder redirection and copies the data on the local drive during publishing and when the virtual environment starts. After the user closes the App-V application and the App-V Client closes the virtual environment, the local storage of the VFS AppData is copied back to the network, enabling roaming to additional machines, where the process will be repeated. The detailed steps of the processes are:
1. During publishing or virtual environment startup, the App-V Client detects the location of the AppData directory.
2. If the roaming AppData path is local or ino AppData\\Roaming location is mapped, nothing happens.
3. If the roaming AppData path is not local, the VFS AppData directory is mapped to the local AppData directory.
1. During publishing or virtual environment startup, the App-V Client detects the location of the AppData directory.
2. If the roaming AppData path is local or ino AppData\\Roaming location is mapped, nothing happens.
3. If the roaming AppData path is not local, the VFS AppData directory is mapped to the local AppData directory.
This process solves the problem of a non-local %AppData% that is not supported by the App-V Client VFS driver. However, the data stored in this new location is not roamed with folder redirection. All changes during the running of the application happen to the local AppData location and must be copied to the redirected location. The detailed steps of this process are:
1. App-V application is shut down, which shuts down the virtual environment.
2. The local cache of the roaming AppData location is compressed and stored in a ZIP file.
3. A timestamp at the end of the ZIP packaging process is used to name the file.
4. The timestamp is recorded in the registry: HKEY\_CURRENT\_USER\\Software\\Microsoft\\AppV\\Client\\Packages\\&lt;GUID&gt;\\AppDataTime as the last known AppData timestamp.
5. The folder redirection process is called to evaluate and initiate the ZIP file uploaded to the roaming AppData directory.
1. App-V application is shut down, which shuts down the virtual environment.
2. The local cache of the roaming AppData location is compressed and stored in a ZIP file.
3. A timestamp at the end of the ZIP packaging process is used to name the file.
4. The timestamp is recorded in the registry: HKEY\_CURRENT\_USER\\Software\\Microsoft\\AppV\\Client\\Packages\\&lt;GUID&gt;\\AppDataTime as the last known AppData timestamp.
5. The folder redirection process is called to evaluate and initiate the ZIP file uploaded to the roaming AppData directory.
The timestamp is used to determine a “last writer wins” scenario if there is a conflict and is used to optimize the download of the data when the App-V application is published or the virtual environment is started. Folder redirection will make the data available from any other clients covered by the supporting policy and will initiate the process of storing the AppData\\Roaming data to the local AppData location on the client. The detailed processes are:
1. The user starts the virtual environment by starting an application.
2. The application’s virtual environment checks for the most recent time stamped ZIP file, if present.
3. The registry is checked for the last known uploaded timestamp, if present.
4. The most recent ZIP file is downloaded unless the local last known upload timestamp is greater than or equal to the timestamp from the ZIP file.
5. If the local last known upload timestamp is earlier than that of the most recent ZIP file in the roaming AppData location, the ZIP file is extracted to the local temp directory in the user’s profile.
6. After the ZIP file is successfully extracted, the local cache of the roaming AppData directory is renamed and the new data is moved into place.
7. The renamed directory is deleted and the application opens with the most recently saved roaming AppData data.
1. The user starts the virtual environment by starting an application.
2. The application’s virtual environment checks for the most recent time stamped ZIP file, if present.
3. The registry is checked for the last known uploaded timestamp, if present.
4. The most recent ZIP file is downloaded unless the local last known upload timestamp is greater than or equal to the timestamp from the ZIP file.
5. If the local last known upload timestamp is earlier than that of the most recent ZIP file in the roaming AppData location, the ZIP file is extracted to the local temp directory in the user’s profile.
6. After the ZIP file is successfully extracted, the local cache of the roaming AppData directory is renamed and the new data is moved into place.
7. The renamed directory is deleted and the application opens with the most recently saved roaming AppData data.
This completes the successful roaming of application settings that are present in AppData\\Roaming locations. The only other condition that must be addressed is a package repair operation. The details of the process are:
1. During repair, detect if the path to the user’s roaming AppData directory is not local.
2. Map the non-local roaming AppData path targets are recreated the expected roaming and local AppData locations.
3. Delete the timestamp stored in the registry, if present.
1. During repair, detect if the path to the user’s roaming AppData directory is not local.
2. Map the non-local roaming AppData path targets are recreated the expected roaming and local AppData locations.
3. Delete the timestamp stored in the registry, if present.
This process will re-create both the local and network locations for AppData and remove the registry record of the timestamp.
## App-V client application lifecycle management
In an App-V Full Infrastructure, after applications are sequenced they are managed and published to users or computers via the App-V Management and Publishing servers. This section details the operations that occur during the common App-V application lifecycle operations (Add, publishing, launch, upgrade, and removal) and the file and registry locations that are changed and modified from the App-V Client perspective. The App-V Client operations are performed as a series of Windows PowerShell commands initiated on the computer running the App-V Client.
In an App-V Full Infrastructure, after applications are sequenced they are managed and published to users or computers through the App-V Management and Publishing servers. This section details the operations that occur during the common App-V application lifecycle operations (Add, publishing, launch, upgrade, and removal) and the file and registry locations that are changed and modified from the App-V Client perspective. The App-V Client operations are performed as a series of Windows PowerShell commands initiated on the computer running the App-V Client.
This document focuses on App-V Full Infrastructure solutions. For specific information on App-V Integration with Configuration Manager 2012, see [Integrating Virtual Application Management with App-V 5 and Configuration Manager 2012 SP1](https://www.microsoft.com/en-us/download/details.aspx?id=38177).
@ -609,19 +607,15 @@ The App-V application lifecycle tasks are triggered at user login (default), mac
The publishing refresh process is comprised of several smaller operations that are performed on the App-V Client. Since App-V is an application virtualization technology and not a task scheduling technology, the Windows Task Scheduler is utilized to enable the process at user logon, machine startup, and at scheduled intervals. The configuration of the client during setup listed above is the preferred method when distributing the client to a large group of computers with the correct settings. These client settings can be configured with the following Windows PowerShell cmdlets:
- **Add-AppVPublishingServer:** Configures the client with an App-V Publishing Server that provides App-V packages.
- **Set-AppVPublishingServer:** Modifies the current settings for the App-V Publishing Server.
- **Set-AppVClientConfiguration:** Modifies the currents settings for the App-V Client.
- **Sync-AppVPublishingServer:** Initiates an App-V Publishing Refresh process manually. This is also utilized in the scheduled tasks created during configuration of the publishing server.
- **Add-AppVPublishingServer:** Configures the client with an App-V Publishing Server that provides App-V packages.
- **Set-AppVPublishingServer:** Modifies the current settings for the App-V Publishing Server.
- **Set-AppVClientConfiguration:** Modifies the currents settings for the App-V Client.
- **Sync-AppVPublishingServer:** Initiates an App-V Publishing Refresh process manually. This is also utilized in the scheduled tasks created during configuration of the publishing server.
The focus of the following sections is to detail the operations that occur during different phases of an App-V Publishing Refresh. The topics include:
- Adding an App-V Package
- Publishing an App-V Package
- Adding an App-V Package
- Publishing an App-V Package
### Adding an App-V package
@ -629,65 +623,61 @@ Adding an App-V package to the client is the first step of the publishing refres
**How to add an App-V package**
1. Manual initiation via Windows PowerShell or Task Sequence initiation of the Publishing Refresh process.
1. Manual initiation via Windows PowerShell or Task Sequence initiation of the Publishing Refresh process.
1. The App-V Client makes an HTTP connection and requests a list of applications based on the target. The Publishing refresh process supports targeting machines or users.
1. The App-V Client makes an HTTP connection and requests a list of applications based on the target. The Publishing refresh process supports targeting machines or users.
2. The App-V Publishing Server uses the identity of the initiating target, user or machine, and queries the database for a list of entitled applications. The list of applications is provided as an XML response, which the client uses to send additional requests to the server for more information on a per package basis.
2. The App-V Publishing Server uses the identity of the initiating target, user or machine, and queries the database for a list of entitled applications. The list of applications is provided as an XML response, which the client uses to send additional requests to the server for more information on a per package basis.
2. The Publishing Agent on the App-V Client performs all actions below serialized.
2. The Publishing Agent on the App-V Client performs all actions below serialized.
Evaluate any connection groups that are unpublished or disabled, since package version updates that are part of the connection group cannot be processed.
3. Configure the packages by identifying an Add or Update operations.
3. Configure the packages by identifying an Add or Update operations.
1. The App-V Client utilizes the AppX API from Windows and accesses the appv file from the publishing server.
1. The App-V Client utilizes the AppX API from Windows and accesses the appv file from the publishing server.
2. The package file is opened and the AppXManifest.xml and StreamMap.xml are downloaded to the Package Store.
2. The package file is opened and the AppXManifest.xml and StreamMap.xml are downloaded to the Package Store.
3. Completely stream publishing block data defined in the StreamMap.xml. Stores the publishing block data in the Package Store\\PkgGUID\\VerGUID\\Root.
3. Completely stream publishing block data defined in the StreamMap.xml. Stores the publishing block data in the Package Store\\PkgGUID\\VerGUID\\Root.
- Icons: Targets of extension points.
- Icons: Targets of extension points.
- Portable Executable Headers (PE Headers): Targets of extension points that contain the base information about the image need on disk, directly accessed or via file types.
- Scripts: Download scripts directory for use throughout the publishing process.
- Portable Executable Headers (PE Headers): Targets of extension points that contain the base information about the image need on disk, directly accessed or via file types.
4. Populate the Package store:
- Scripts: Download scripts directory for use throughout the publishing process.
1. Create sparse files on disk that represent the extracted package for any directories listed.
4. Populate the Package store:
2. Stage top level files and directories under root.
1. Create sparse files on disk that represent the extracted package for any directories listed.
3. All other files are created when the directory is listed as sparse on disk and streamed on demand.
2. Stage top level files and directories under root.
5. Create the machine catalog entries. Create the Manifest.xml and DeploymentConfiguration.xml from the package files (if no DeploymentConfiguration.xml file in the package a placeholder is created).
3. All other files are created when the directory is listed as sparse on disk and streamed on demand.
6. Create location of the package store in the registry HKLM\\Software\\Microsoft\\AppV\\Client\\Packages\\PkgGUID\\Versions\\VerGUID\\Catalog
5. Create the machine catalog entries. Create the Manifest.xml and DeploymentConfiguration.xml from the package files (if no DeploymentConfiguration.xml file in the package a placeholder is created).
7. Create the Registry.dat file from the package store to %ProgramData%\\Microsoft\\AppV\\Client\\VReg\\{VersionGUID}.dat
6. Create location of the package store in the registry HKLM\\Software\\Microsoft\\AppV\\Client\\Packages\\PkgGUID\\Versions\\VerGUID\\Catalog
8. Register the package with the App-V Kernal Mode Driver HKLM\\Microsoft\\Software\\AppV\\MAV
7. Create the Registry.dat file from the package store to %ProgramData%\\Microsoft\\AppV\\Client\\VReg\\{VersionGUID}.dat
9. Invoke scripting from the AppxManifest.xml or DeploymentConfig.xml file for Package Add timing.
8. Register the package with the App-V Kernal Mode Driver HKLM\\Microsoft\\Software\\AppV\\MAV
4. Configure Connection Groups by adding and enabling or disabling.
9. Invoke scripting from the AppxManifest.xml or DeploymentConfig.xml file for Package Add timing.
5. Remove objects that are not published to the target (user or machine).
4. Configure Connection Groups by adding and enabling or disabling.
>[!NOTE]
>This will not perform a package deletion but rather remove integration points for the specific target (user or machine) and remove user catalog files (machine catalog files for globally published).
5. Remove objects that are not published to the target (user or machine).
6. Invoke background load mounting based on client configuration.
> [!NOTE]
> This will not perform a package deletion but rather remove integration points for the specific target (user or machine) and remove user catalog files (machine catalog files for globally published).
7. Packages that already have publishing information for the machine or user are immediately restored.
 
>[!NOTE]
>This condition occurs as a product of removal without unpublishing with background addition of the package.
6. Invoke background load mounting based on client configuration.
7. Packages that already have publishing information for the machine or user are immediately restored.
> [!NOTE]   
> This condition occurs as a product of removal without unpublishing with background addition of the package.
 
This completes an App-V package add of the publishing refresh process. The next step is publishing the package to the specific target (machine or user).
@ -697,28 +687,28 @@ This completes an App-V package add of the publishing refresh process. The next
During the Publishing Refresh operation, the specific publishing operation (Publish-AppVClientPackage) adds entries to the user catalog, maps entitlement to the user, identifies the local store, and finishes by completing any integration steps. The following are the detailed steps.
**How to publish and App-V package**
#### How to publish an App-V package
1. Package entries are added to the user catalog
1. Package entries are added to the user catalog
1. User targeted packages: the UserDeploymentConfiguration.xml and UserManifest.xml are placed on the machine in the User Catalog
1. User targeted packages: the UserDeploymentConfiguration.xml and UserManifest.xml are placed on the machine in the User Catalog
2. Machine targeted (global) packages: the UserDeploymentConfiguration.xml is placed in the Machine Catalog
2. Machine targeted (global) packages: the UserDeploymentConfiguration.xml is placed in the Machine Catalog
2. Register the package with the kernel mode driver for the user at HKLM\\Software\\Microsoft\\AppV\\MAV
2. Register the package with the kernel mode driver for the user at HKLM\\Software\\Microsoft\\AppV\\MAV
3. Perform integration tasks.
3. Perform integration tasks.
1. Create extension points.
1. Create extension points.
2. Store backup information in the user’s registry and roaming profile (Shortcut Backups).
2. Store backup information in the user’s registry and roaming profile (Shortcut Backups).
**Note**  
This enables restore extension points if the package is unpublished.
>[!NOTE]
>This enables restore extension points if the package is unpublished.
 
3. Run scripts targeted for publishing timing.
3. Run scripts targeted for publishing timing.
Publishing an App-V Package that is part of a Connection Group is very similar to the above process. For connection groups, the path that stores the specific catalog information includes PackageGroups as a child of the Catalog Directory. Review the machine and users catalog information above for details.
@ -728,25 +718,24 @@ Publishing an App-V Package that is part of a Connection Group is very similar t
After the Publishing Refresh process, the user launches and subsequently re-launches an App-V application. The process is very simple and optimized to launch quickly with a minimum of network traffic. The App-V Client checks the path to the user catalog for files created during publishing. After rights to launch the package are established, the App-V Client creates a virtual environment, begins streaming any necessary data, and applies the appropriate manifest and deployment configuration files during virtual environment creation. With the virtual environment created and configured for the specific package and application, the application starts.
**How to launch App-V applications**
#### How to launch App-V applications
1. User launches the application by clicking on a shortcut or file type invocation.
1. User launches the application by clicking on a shortcut or file type invocation.
2. The App-V Client verifies existence in the User Catalog for the following files
2. The App-V Client verifies existence in the User Catalog for the following files
- UserDeploymentConfiguration.xml
- UserDeploymentConfiguration.xml
- UserManifest.xml
- UserManifest.xml
3. If the files are present, the application is entitled for that specific user and the application will start the process for launch. There is no network traffic at this point.
3. If the files are present, the application is entitled for that specific user and the application will start the process for launch. There is no network traffic at this point.
4. Next, the App-V Client checks that the path for the package registered for the App-V Client service is found in the registry.
4. Next, the App-V Client checks that the path for the package registered for the App-V Client service is found in the registry.
5. Upon finding the path to the package store, the virtual environment is created. If this is the first launch, the Primary Feature Block downloads if present.
5. Upon finding the path to the package store, the virtual environment is created. If this is the first launch, the Primary Feature Block downloads if present.
6. After downloading, the App-V Client service consumes the manifest and deployment configuration files to configure the virtual environment and all App-V subsystems are loaded.
6. After downloading, the App-V Client service consumes the manifest and deployment configuration files to configure the virtual environment and all App-V subsystems are loaded.
7. The Application launches. For any missing files in the package store (sparse files), App-V will stream fault the files on an as needed basis.
7. The Application launches. For any missing files in the package store (sparse files), App-V will stream fault the files on an as needed basis.
![package add file and registry data - stream](images/packageaddfileandregistrydata-stream.png)
@ -754,52 +743,52 @@ After the Publishing Refresh process, the user launches and subsequently re-laun
The App-V package upgrade process differs from the older versions of App-V. App-V supports multiple versions of the same package on a machine entitled to different users. Package versions can be added at any time as the package store and catalogs are updated with the new resources. The only process specific to the addition of new version resources is storage optimization. During an upgrade, only the new files are added to the new version store location and hard links are created for unchanged files. This reduces the overall storage by only presenting the file on one disk location and then projecting it into all folders with a file location entry on the disk. The specific details of upgrading an App-V Package are as follows:
**How to upgrade an App-V package**
#### How to upgrade an App-V package
1. The App-V Client performs a Publishing Refresh and discovers a newer version of an App-V Package.
1. The App-V Client performs a Publishing Refresh and discovers a newer version of an App-V Package.
2. Package entries are added to the appropriate catalog for the new version
2. Package entries are added to the appropriate catalog for the new version
1. User targeted packages: the UserDeploymentConfiguration.xml and UserManifest.xml are placed on the machine in the user catalog at appdata\\roaming\\Microsoft\\AppV\\Client\\Catalog\\Packages\\PkgGUID\\VerGUID
1. User targeted packages: the UserDeploymentConfiguration.xml and UserManifest.xml are placed on the machine in the user catalog at appdata\\roaming\\Microsoft\\AppV\\Client\\Catalog\\Packages\\PkgGUID\\VerGUID
2. Machine targeted (global) packages: the UserDeploymentConfiguration.xml is placed in the machine catalog at %programdata%\\Microsoft\\AppV\\Client\\Catalog\\Packages\\PkgGUID\\VerGUID
2. Machine targeted (global) packages: the UserDeploymentConfiguration.xml is placed in the machine catalog at %programdata%\\Microsoft\\AppV\\Client\\Catalog\\Packages\\PkgGUID\\VerGUID
3. Register the package with the kernel mode driver for the user at HKLM\\Software\\Microsoft\\AppV\\MAV
3. Register the package with the kernel mode driver for the user at HKLM\\Software\\Microsoft\\AppV\\MAV
4. Perform integration tasks.
4. Perform integration tasks.
1. Integrate extensions points (EP) from the Manifest and Dynamic Configuration files.
2. File based EP data is stored in the AppData folder utilizing Junction Points from the package store.
2. File based EP data is stored in the AppData folder utilizing Junction Points from the package store.
3. Version 1 EPs already exist when a new version becomes available.
3. Version 1 EPs already exist when a new version becomes available.
4. The extension points are switched to the Version 2 location in machine or user catalogs for any newer or updated extension points.
4. The extension points are switched to the Version 2 location in machine or user catalogs for any newer or updated extension points.
5. Run scripts targeted for publishing timing.
5. Run scripts targeted for publishing timing.
6. Install Side by Side assemblies as required.
6. Install Side by Side assemblies as required.
### Upgrading an in-use App-V package
If you try to upgrade a package that is in use by an end user, the upgrade task is placed in a pending state. The upgrade will run later, according to the following rules:
| Task type | Applicable rule |
| - | - |
| User-based task, e.g., publishing a package to a user | The pending task will be performed after the user logs off and then logs back on. |
| Globally based task, e.g., enabling a connection group globally | The pending task will be performed when the computer is shut down and then restarted. |
|---|---|
| User-based tasks, such as publishing a package to a user | The pending task will be performed after the user logs off and then logs back on. |
| Globally based tasks, such as enabling a connection group globally | The pending task will be performed when the computer is shut down and then restarted. |
When a task is placed in a pending state, the App-V client also generates a registry key for the pending task, as follows:
| User-based or globally based task | Where the registry key is generated |
| - | - |
|---|---|
| User-based tasks | HKEY\_CURRENT\_USER\Software\Microsoft\AppV\Client\PendingTasks |
| Globally based tasks | HKEY\_LOCAL\_MACHINE\Software\Microsoft\AppV\Client\PendingTasks |
The following operations must be completed before users can use the newer version of the package:
| Task | Details |
| - | - |
|---|---|
| Add the package to the computer | This task is computer specific and you can perform it at any time by completing the steps in the Package Add section above. |
| Publish the package | See the Package Publishing section above for steps. This process requires that you update extension points on the system. End users cannot be using the application when you complete this task. |
@ -810,14 +799,12 @@ Use the following example scenarios as a guide for updating packages.
| App-V package is not in use when you try to upgrade | None of the following components of the package can be in use: virtual application, COM server, or shell extensions.<br/><br/>The administrator publishes a newer version of the package and the upgrade works the next time a component or application inside the package is launched. The new version of the package is streamed and ran. |
| App-V package is in use when the administrator publishes a newer version of the package | The upgrade operation is set to pending by the App-V Client, which means that it is queued and carried out later when the package is not in use.<br/><br/>If the package application is in use, the user shuts down the virtual application, after which the upgrade can occur.<br/><br/>If the package has shell extensions, which are permanently loaded by Windows Explorer, the user cannot be logged in. Users must log off and the log back in to initiate the App-V package upgrade.|
 
### Global vs user publishing
### Global vs. user publishing
App-V Packages can be published in one of two ways; User which entitles an App-V package to a specific user or group of users and Global which entitles the App-V package to the entire machine for all users of the machine. Once a package upgrade has been pended and the App-V package is not in use, consider the two types of publishing:
- **Globally published**: the application is published to a machine; all users on that machine can use it. The upgrade will happen when the App-V Client Service starts, which effectively means a machine restart.
- **User published**: the application is published to a user. If there are multiple users on the machine, the application can be published to a subset of the users. The upgrade will happen when the user logs in or when it is published again (periodically, ConfigMgr Policy refresh and evaluation, or an App-V periodic publishing/refresh, or explicitly via Windows PowerShell commands).
- **Globally published**: the application is published to a machine; all users on that machine can use it. The upgrade will happen when the App-V Client Service starts, which effectively means a machine restart.
- **User published**: the application is published to a user. If there are multiple users on the machine, the application can be published to a subset of the users. The upgrade will happen when the user logs in or when it is published again (periodically, ConfigMgr Policy refresh and evaluation, or an App-V periodic publishing/refresh, or explicitly via Windows PowerShell commands).
### Removing an App-V package
@ -829,52 +816,37 @@ The repair operation is very simple but may affect many locations on the machine
## Integration of App-V packages
The App-V Client and package architecture provides specific integration with the local operating system during the addition and publishing of packages. Three files define the integration or extension points for an App-V Package:
- AppXManifest.xml: Stored inside of the package with fallback copies stored in the package store and the user profile. Contains the options created during the sequencing process.
- DeploymentConfig.xml: Provides configuration information of computer and user based integration extension points.
- UserConfig.xml: A subset of the Deploymentconfig.xml that only provides user- based configurations and only targets user-based extension points.
- AppXManifest.xml: Stored inside of the package with fallback copies stored in the package store and the user profile. Contains the options created during the sequencing process.
- DeploymentConfig.xml: Provides configuration information of computer and user based integration extension points.
- UserConfig.xml: A subset of the Deploymentconfig.xml that only provides user- based configurations and only targets user-based extension points.
### Rules of integration
When App-V applications are published to a computer with the App-V Client, some specific actions take place as described in the list below:
- Global Publishing: Shortcuts are stored in the All Users profile location and other extension points are stored in the registry in the HKLM hive.
- Global Publishing: Shortcuts are stored in the All Users profile location and other extension points are stored in the registry in the HKLM hive.
- User Publishing: Shortcuts are stored in the current user account profile and other extension points are stored in the registry in the HKCU hive.
- Backup and Restore: Existing native application data and registry (such as FTA registrations) are backed up during publishing.
- User Publishing: Shortcuts are stored in the current user account profile and other extension points are stored in the registry in the HKCU hive.
- Backup and Restore: Existing native application data and registry (such as FTA registrations) are backed up during publishing.
1. App-V packages are given ownership based on the last integrated package where the ownership is passed to the newest published App-V application.
2. Ownership transfers from one App-V package to another when the owning App-V package is unpublished. This will not initiate a restore of the data or registry.
3. Restore the backed up data when the last package is unpublished or removed on a per extension point basis.
1. App-V packages are given ownership based on the last integrated package where the ownership is passed to the newest published App-V application.
2. Ownership transfers from one App-V package to another when the owning App-V package is unpublished. This will not initiate a restore of the data or registry.
3. Restore the backed up data when the last package is unpublished or removed on a per extension point basis.
### Extension points
The App-V publishing files (manifest and dynamic configuration) provide several extension points that enable the application to integrate with the local operating system. These extension points perform typical application installation tasks, such as placing shortcuts, creating file type associations, and registering components. As these are virtualized applications that are not installed in the same manner a traditional application, there are some differences. The following is a list of extension points covered in this section:
- Shortcuts
- File Type Associations
- Shell Extensions
- COM
- Software Clients
- Application capabilities
- URL Protocol Handler
- AppPath
- Virtual Application
- Shortcuts
- File Type Associations
- Shell Extensions
- COM
- Software Clients
- Application capabilities
- URL Protocol Handler
- AppPath
- Virtual Application
### Shortcuts
@ -882,7 +854,7 @@ The short cut is one of the basic elements of integration with the OS and is the
From the package manifest and dynamic configuration XML files, the path to a specific application executable can be found in a section similar to the following:
``` syntax
```XML
<Extension Category="AppV.Shortcut">
<Shortcut>
<File>[{Common Desktop}]\Adobe Reader.lnk</File>
@ -902,7 +874,7 @@ As mentioned previously, the App-V shortcuts are placed by default in the user
The App-V Client manages the local operating system File Type Associations during publishing, which enables users to use file type invocations or to open a file with a specifically registered extension (.docx) to start an App-V application. File type associations are present in the manifest and dynamic configuration files as represented in the example below:
``` syntax
```XML
<Extension Category="AppV.FileTypeAssociation">
<FileTypeAssociation>
<FileExtension MimeAssociation="true">
@ -939,48 +911,39 @@ The App-V Client manages the local operating system File Type Associations durin
</Extension>
```
**Note**  
In this example:
- `<Name>.xdp</Name>` is the extension
- `<Name>AcroExch.XDPDoc</Name>` is the ProgId value (which points to the adjoining ProgId)
- `<CommandLine>"[{AppVPackageRoot}]\Reader\AcroRd32.exe" "%1"</CommandLine>` is the command line, which points to the application executable
 
>[!NOTE]
>In this example:
>
>- `<Name>.xdp</Name>` is the extension
>- `<Name>AcroExch.XDPDoc</Name>` is the ProgId value (which points to the adjoining ProgId)
>- `<CommandLine>"[{AppVPackageRoot}]\Reader\AcroRd32.exe" "%1"</CommandLine>` is the command line, which points to the application executable
### Shell extensions
Shell extensions are embedded in the package automatically during the sequencing process. When the package is published globally, the shell extension gives users the same functionality as if the application were locally installed. The application requires no additional setup or configuration on the client to enable the shell extension functionality.
**Requirements for using shell extensions:**
#### Requirements for using shell extensions
- Packages that contain embedded shell extensions must be published globally.
- Packages that contain embedded shell extensions must be published globally.
- The “bitness” of the application, Sequencer, and App-V client must match, or the shell extensions won’t work. For example:
- The “bitness” of the application, Sequencer, and App-V client must match, or the shell extensions won’t work. For example:
- The version of the application is 64-bit.
- The Sequencer is running on a 64-bit computer.
- The package is being delivered to a 64-bit App-V client computer.
- The version of the application is 64-bit.
- The Sequencer is running on a 64-bit computer.
- The package is being delivered to a 64-bit App-V client computer.
The following table displays the supported shell extensions.
| Handler | Description |
| - | - |
|---|---|
| Context menu handler | Adds menu items to the context menu. It is called before the context menu is displayed. |
| Drag-and-drop handler | Controls the action upon right-click drag-and-drop and modifies the context menu that appears. |
| Drop target handler | Controls the action after a data object is dragged-and-dropped over a drop target such as a file.|
| Data object handler| Controls the action after a file is copied to the clipboard or dragged-and-dropped over a drop target. It can provide additional clipboard formats to the drop target.|
| Property sheet handler| Replaces or adds pages to the property sheet dialog box of an object.|
| Infotip handler| Allows retrieving flags and infotip information for an item and displaying it inside a popup tooltip upon mouse- hover.|
| Infotip handler| Allows retrieving flags and infotip information for an item and displaying it inside a popup tooltip upon mouse-hover.|
| Column handler| Allows creating and displaying custom columns in Windows Explorer *Details view*. It can be used to extend sorting and grouping.|
| Preview handler| Enables a preview of a file to be displayed in the Windows Explorer Preview Pane.|
 
### COM
The App-V Client supports publishing applications with support for COM integration and virtualization. COM integration allows the App-V Client to register COM objects on the local operating system and virtualization of the objects. For the purposes of this document, the integration of COM objects requires additional detail.
@ -995,7 +958,7 @@ App-V supports specific software clients and application capabilities extension
Example of software client registration of an App-V based mail client.
``` syntax
```XML
<SoftwareClients Enabled="true">
<ClientConfiguration EmailEnabled="true" />
<Extensions>
@ -1035,16 +998,12 @@ Example of software client registration of an App-V based mail client.
</SoftwareClients>
```
**Note**  
>[!NOTE]
In this example:
- `<ClientConfiguration EmailEnabled="true" />` is the overall Software Clients setting to integrate Email clients
- `<EMail MakeDefault="true">` is the flag to set a particular Email client as the default Email client
- `<MAPILibrary>[{ProgramFilesX86}]\Mozilla Thunderbird\mozMapi32_InUse.dll</MAPILibrary>` is the MAPI dll registration
 
>
>- `<ClientConfiguration EmailEnabled="true" />` is the overall Software Clients setting to integrate Email clients
>- `<EMail MakeDefault="true">` is the flag to set a particular Email client as the default Email client
>- `<MAPILibrary>[{ProgramFilesX86}]\Mozilla Thunderbird\mozMapi32_InUse.dll</MAPILibrary>` is the MAPI dll registration
### URL Protocol handler
@ -1068,6 +1027,25 @@ The extension points described above are integrated into the operating system ba
Extension points are not all published the same way, where some extension points will require global publishing and others require sequencing on the specific operating system and architecture where they are delivered. Below is a table that describes these two key rules.
|Virtual Extension|Requires target OS Sequencing|Requires Global Publishing|
|---|:---:|:---:|
|Shortcut|||
|File Type Association|||
|URL Protocols|X||
|AppPaths|X||
|COM Mode|||
|Software Client|X||
|Application Capabilities|X|X|
|Context Menu Handler|X|X|
|Drag-and-drop Handler|X||
|Data Object Handler|X||
|Property Sheet Handler|X||
|Infotip Handler|X||
|Column Handler|X||
|Shell Extensions|X||
|Browser Helper Object|X|X|
|Active X Object|X|X|
<table>
<colgroup>
<col width="33%" />
@ -1180,9 +1158,9 @@ App-V Packages contain the Manifest file inside of the appv package file, which
The example below shows the combination of the Manifest, Deployment Configuration and User Configuration files after publishing and during normal operation. These examples are abbreviated examples of each of the files. The purpose is show the combination of the files only and not to be a complete description of the specific categories available in each of the files. For more information, download the [App-V Sequencing Guide](https://www.microsoft.com/en-us/download/details.aspx?id=27760).
**Manifest**
#### Manifest
``` syntax
```XML
<appv:Extension Category="AppV.Shortcut">
<appv:Shortcut>
<appv:File>[{Common Programs}]\7-Zip\7-Zip File Manager.lnk</appv:File>
@ -1192,9 +1170,9 @@ The example below shows the combination of the Manifest, Deployment Configuratio
</appv:Extension>
```
**Deployment Configuration**
#### Deployment Configuration
``` syntax
```XML
<MachineConfiguration>
<Subsystems>
<Registry>
@ -1207,9 +1185,9 @@ The example below shows the combination of the Manifest, Deployment Configuratio
</Subsystems>
```
**User Configuration**
#### User Configuration
``` syntax
```XML
<UserConfiguration>
<Subsystems>
<appv:ExtensionCategory="AppV.Shortcut">
@ -1248,41 +1226,32 @@ The example below shows the combination of the Manifest, Deployment Configuratio
## Side-by-side assemblies
App-V supports the automatic packaging of side-by-side (SxS) assemblies during sequencing and deployment on the client during virtual application publishing. App-V supports capturing SxS assemblies during sequencing for assemblies not present on the sequencing machine. And for assemblies consisting of Visual C++ (Version 8 and newer) and/or MSXML run-time, the Sequencer will automatically detect and capture these dependencies even if they were not installed during monitoring. The side-by-side assemblies feature removes the limitations of previous versions of App-V, where the App-V Sequencer did not capture assemblies already present on the sequencing workstation, and privatizing the assemblies which limited to one bit version per package. This behavior resulted in deployed App-V applications to clients missing the required SxS assemblies, causing application launch failures. This forced the packaging process to document and then ensure that all assemblies required for packages were locally installed on the user’s client operating system to ensure support for the virtual applications. Based on the number of assemblies and the lack of application documentation for the required dependencies, this task was both a management and implementation challenge.
App-V supports the automatic packaging of side-by-side (SxS) assemblies during sequencing and deployment on the client during virtual application publishing. App-V supports capturing SxS assemblies during sequencing for assemblies not present on the sequencing machine. And for assemblies consisting of Visual C++ (Version 8 and newer) and/or MSXML run-time, the Sequencer will automatically detect and capture these dependencies even if they were not installed during monitoring. The Side by Side assemblies feature removes the limitations of previous versions of App-V, where the App-V Sequencer did not capture assemblies already present on the sequencing workstation, and privatizing the assemblies which limited to one bit version per package. This behavior resulted in deployed App-V applications to clients missing the required SxS assemblies, causing application launch failures. This forced the packaging process to document and then ensure that all assemblies required for packages were locally installed on the user’s client operating system to ensure support for the virtual applications. Based on the number of assemblies and the lack of application documentation for the required dependencies, this task was both a management and implementation challenge.
Side-by-side assembly support in App-V has the following features.
Side by Side Assembly support in App-V has the following features.
- Automatic captures of SxS assembly during Sequencing, regardless of whether the assembly was already installed on the sequencing workstation.
- The App-V Client automatically installs required SxS assemblies to the client computer at publishing time when they are not present.
- The Sequencer reports the VC run-time dependency in Sequencer reporting mechanism.
- The Sequencer allows opting to not package the assemblies that are already installed on the Sequencer, supporting scenarios where the assemblies have previously been installed on the target computers.
- Automatic captures of SxS assembly during Sequencing, regardless of whether the assembly was already installed on the sequencing workstation.
- The App-V Client automatically installs required SxS assemblies to the client computer at publishing time when they are not present.
- The Sequencer reports the VC run-time dependency in Sequencer reporting mechanism.
- The Sequencer allows opting to not package the assemblies that are already installed on the Sequencer, supporting scenarios where the assemblies have previously been installed on the target computers.
### Automatic publishing of SxS assemblies
During publishing of an App-V package with SxS assemblies the App-V Client will check for the presence of the assembly on the machine. If the assembly does not exist, the client will deploy the assembly to the machine. Packages that are part of connection groups will rely on the Side by Side assembly installations that are part of the base packages, as the connection group does not contain any information about assembly installation.
> [!NOTE]
> Unpublishing or removing a package with an assembly does not remove the assemblies for that package.
 
>[!NOTE]
>Unpublishing or removing a package with an assembly does not remove the assemblies for that package.
## Client logging
The App-V client logs information to the Windows Event log in standard ETW format. The specific App-V events can be found in the event viewer, under Applications and Services Logs\\Microsoft\\AppV\\Client.
There are three specific categories of events recorded described below.
**Admin**: Logs events for configurations being applied to the App-V Client, and contains the primary warnings and errors.
**Operational**: Logs the general App-V execution and usage of individual components creating an audit log of the App-V operations that have been completed on the App-V Client.
**Virtual Application**: Logs virtual application launches and use of virtualization subsystems.
- **Admin**: Logs events for configurations being applied to the App-V Client, and contains the primary warnings and errors.
- **Operational**: Logs the general App-V execution and usage of individual components creating an audit log of the App-V operations that have been completed on the App-V Client.
- **Virtual Application**: Logs virtual application launches and use of virtualization subsystems.
## Have a suggestion for App-V?
Add or vote on suggestions on the [Application Virtualization feedback site](https://appv.uservoice.com/forums/280448-microsoft-application-virtualization).<br>For App-V issues, use the [App-V TechNet Forum](https://social.technet.microsoft.com/Forums/en-US/home?forum=mdopappv).
Add or vote on suggestions on the [Application Virtualization feedback site](https://appv.uservoice.com/forums/280448-microsoft-application-virtualization).