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

Acrolinx score

Browse Source
This commit is contained in:
Siddarth Mandalika
2022-02-11 19:34:43 +05:30
parent 40da2948f7
commit 6d7a30f811
13 changed files with 165 additions and 163 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -67,9 +67,9 @@ The App-V Client performs tasks to keep virtual applications running properly an
| Copy on Write (COW) Local | %LocalAppData%\Microsoft\AppV\Client\VFS| Writeable non-roaming location for package modification.|
| Machine Registry | HKLM\Software\Microsoft\AppV| Contains package state information, including VReg for machine or globally published packages (Machine hive).|
| User Registry | HKCU\Software\Microsoft\AppV| Contains user package state information including VReg.|
| User Registry Classes | HKCU\Software\Classes\AppV| Contains additional user package state information.|
| User Registry Classes | HKCU\Software\Classes\AppV| Contains more user package state information.|
Additional details for the table are provided in the section below and throughout the document.
More details for the table are provided in the section below and throughout the document.
### Package store
@ -92,10 +92,10 @@ If the App-V Client is configured in Shared Content Store mode, no data is writt
### Package catalogs
The App-V Client manages the following two file-based locations:
The App-V Client manages the following 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 specific 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.
- **Registry locations**—depends on how the package is targeted for publishing. There's 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 specific user, and the User catalog stores information applicable to a specific user. The catalog is a collection of Dynamic Configurations and manifest files; there's discrete data for both file and registry per package version.
### Machine catalog
@ -103,8 +103,8 @@ The locations described in this table can be found in the %programdata%\Microsof
| | Location |
|:---|:---|
|**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.|
|**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's a Dynamic Configuration file, stored in the Machine Catalog; therefore, the determination of whether a package is global is defined according to whether there's a policy file (UserDeploymentConfiguration file) in the Machine Catalog.|
|**Default storage location**|%programdata%\Microsoft\AppV\Client\Catalog\<br></br>This location isn't 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)|
@ -115,7 +115,7 @@ The locations described in this table can be found in the appdata\roaming\Micros
|| Location |
|:---|:---|
|**Description**|Created during the publishing process. Contains information used for publishing the package, and for making sure that a package is provisioned to a specific user at launch. 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.|
|**Description**|Created during the publishing process. Contains information used for publishing the package, and for making sure that a package is provisioned to a specific user at launch. 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're 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|
@ -135,7 +135,7 @@ The COW Roaming location described above stores changes to files and directories
### COW local
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 (for example, 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 signed-in users. The non-**S** location stores user-based changes.
The COW Local location is similar to the roaming location, but the directories and files aren't 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 (for example, 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 signed-in users. The non-**S** location stores user-based changes.
## Package registry
@ -151,15 +151,15 @@ When the first application from the package is launched on the client, the clien
When connection groups are present, the previous process of staging the registry holds true, but instead of having one hive file to process, there are more than one. The files are processed in the order in which they appear in the connection group XML, with the first writer winning any conflicts.
The staged registry persists the same way as in the single package case. Staged user registry data remains for the connection group until it is disabled; staged machine registry data is removed on connection group removal.
The staged registry persists the same way as in the single package case. Staged user registry data remains for the connection group until it's disabled; staged machine registry data is removed on connection group removal.
### Virtual registry
The purpose of the virtual registry (VREG) is to provide a single merged view of the package registry and the native registry to applications. It also provides copy-on-write (COW) functionality—that is, any changes made to the registry from the context of a virtual process are made to a separate COW location. This means that the VREG must combine up to three separate registry locations into a single view based on the populated locations in the **registry COW** > **package** > **native**. When a request is made for a registry data it will locate in order until it finds the data it was requesting. Meaning if there is a value stored in a COW location it will not proceed to other locations, however, if there is no data in the COW location it will proceed to the Package and then Native location until it finds the appropriate data.
The purpose of the virtual registry (VREG) is to provide a single merged view of the package registry and the native registry to applications. It also provides copy-on-write (COW) functionality—that is, any changes made to the registry from the context of a virtual process are made to a separate COW location. This functionality means that the VREG must combine up to three separate registry locations into a single view based on the populated locations in the **registry COW** > **package** > **native**. When a request is made for a registry data it will locate in order until it finds the data it was requesting. Meaning if there's a value stored in a COW location it will not proceed to other locations, however, if there's no data in the COW location it will proceed to the Package and then Native location until it finds the appropriate data.
### Registry locations
There are two package registry locations and two connection group locations where the App-V Client stores registry information, depending on whether the Package is published individually or as part of a connection group. There are three COW locations for packages and three for connection groups, which are created and managed by the VREG. Settings for packages and connection groups are not shared:
There are two package registry locations and two connection group locations where the App-V Client stores registry information, depending on whether the Package is published individually or as part of a connection group. There are three COW locations for packages and three for connection groups, which are created and managed by the VREG. Settings for packages and connection groups aren't shared:
#### Single Package VReg
@ -207,7 +207,7 @@ The following locations are configured as pass-through locations by default:
- 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. Administers ideally should not modify any of the default pass-through keys, but in some instances, the admin may need to add additional pass-through keys to adjust application behavior.
The purpose of pass-through keys is to ensure that a virtual application doesn't 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. Administers ideally shouldn't modify any of the default pass-through keys, but in some instances, the admin may need to add more pass-through keys to adjust application behavior.
## App-V package store behavior
@ -233,7 +233,7 @@ The App-V Client can be configured to change the default behavior of streaming.
|PackageSourceRoot|The root override where packages should be streamed from|
|SharedContentStoreMode|Enables the use of Shared Content Store for VDI scenarios|
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 in streaming packages that it's particularly important to understand:
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 in streaming packages that is important to understand:
- Background Streaming
- Optimized Streaming
@ -241,7 +241,7 @@ These settings affect the behavior of streaming App-V package assets to the clie
### 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 either the **Set-AppvClientConfiguration** cmdlet 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 either be disabled altogether (value=0) or enabled for all packages (value=2), regardless of 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 either the **Set-AppvClientConfiguration** cmdlet 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 either be disabled altogether (value=0) or enabled for all packages (value=2), regardless of whether they've been launched.
### Optimized streaming
@ -249,7 +249,7 @@ App-V packages can be configured with a primary feature block during sequencing.
### Stream faults
After the initial stream of any publishing data and the primary feature block, requests for additional files perform stream faults. These blocks of data are downloaded to the package store on an as-needed basis. This allows a user to download only a small part of the package, typically enough to launch the package and run normal tasks. All other blocks are downloaded when a user initiates an operation that requires data not currently in the package store.
After the initial stream of any publishing data and the primary feature block, requests for more files perform stream faults. These blocks of data are downloaded to the package store on an as-needed basis. This flexibility allows a user to download only a small part of the package, typically enough to launch the package and run normal tasks. All other blocks are downloaded when a user initiates an operation that requires data not currently in the package store.
### Package upgrades
@ -257,11 +257,11 @@ App-V Packages require updating throughout the lifecycle of the application. App
### Package removal
The App-V Client's behavior when packages are removed depends on the package removal method. Using an App-V full infrastructure to unpublish the application, the user catalog files (machine catalog for globally published applications) are removed, but the package store location and COW locations remain. When the **Remove-AppVClientPackge** Windows PowerShell cmdlet 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.
The App-V Client's behavior when packages are removed depends on the package removal method. Using an App-V full infrastructure to unpublish the application, the user catalog files (machine catalog for globally published applications) are removed, but the package store location and COW locations remain. When the **Remove-AppVClientPackge** Windows PowerShell cmdlet 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 doesn't 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.
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 don't roam from computer to computer, since they're in locations that aren't roamed.
### Roaming requirements and user catalog data storage
@ -270,7 +270,7 @@ App-V stores data, which represents the state of the user’s catalog, in the fo
- 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.
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 doesn't support roaming %AppData%, but not roaming the user’s profile (registry), or vice versa.
>[!NOTE]
>The **Repair-AppvClientPackage** cmdlet doesn't 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%.
@ -281,8 +281,8 @@ 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><br>- HKLM's location is HKCU\SOFTWARE\Classes\AppV\Client\Packages\\{PkgGUID}\REGISTRY\MACHINE\SOFTWARE<br>- HKCU's location is HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\REGISTRY\USER\\{UserSID}\SOFTWARE<br><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><br>- HKLM data is stored in the HKLM hive on the local computer<br>- HKCU data is stored in the User Registry location<br><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 locations:<br><br>- HKLM's location is HKLM\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\\{UserSID}\REGISTRY\MACHINE\SOFTWARE<br>- HKCU's location is HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\\Registry\User\\{UserSID}\SOFTWARE|
|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 scenario presents two distinct paths:<br><br>- HKLM's location is HKCU\SOFTWARE\Classes\AppV\Client\Packages\\{PkgGUID}\REGISTRY\MACHINE\SOFTWARE<br>- HKCU's location is HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\REGISTRY\USER\\{UserSID}\SOFTWARE<br><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><br>- HKLM data is stored in the HKLM hive on the local computer<br>- HKCU data is stored in the User Registry location<br><br>In this scenario, these settings aren't roamed with normal operating system roaming configurations, and the resulting registry keys and values are stored in the following locations:<br><br>- HKLM's location is HKLM\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\\{UserSID}\REGISTRY\MACHINE\SOFTWARE<br>- HKCU's location is HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\\Registry\User\\{UserSID}\SOFTWARE|
### App-V and folder redirection
@ -290,7 +290,7 @@ App-V supports folder redirection of the roaming AppData folder (%AppData%). Whe
A typical package has several locations mapped in the user’s backing store for settings in both AppData\\Local and AppData\\Roaming. These locations are the Copy on Write locations that are stored per user in the user’s profile, and that are used to store changes made to the package VFS directories and to protect the default package VFS.
The following table shows local and roaming locations when folder redirection has not been implemented.
The following table shows local and roaming locations when folder redirection hasn't been implemented.
| VFS directory in package | Mapped location of backing store |
|---|---|
@ -310,13 +310,13 @@ The following table shows local and roaming locations when folder redirection ha
| 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 can't 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. Here's what happens during the process:
The current App-V Client VFS driver can't 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 more machines, where the process will be repeated. Here's what happens during the process:
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 no 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.
3. If the roaming AppData path isn't 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 process does the following things:
This process solves the problem of a non-local %AppData% that isn't supported by the App-V Client VFS driver. However, the data stored in this new location isn't 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 process does the following things:
1. Shuts down the App-V application, which also shuts down the virtual environment.
2. Compresses the local cache of the roaming AppData location and store it in a .zip file.
@ -324,7 +324,7 @@ This process solves the problem of a non-local %AppData% that is not supported b
4. Records the time stamp in the HKEY\_CURRENT\_USER\\Software\\Microsoft\\AppV\\Client\\Packages\\&lt;GUID&gt;\\AppDataTime registry as the last known AppData time stamp.
5. Calls the folder redirection process to evaluate and initiate the .zip file uploaded to the roaming AppData directory.
The time stamp 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. Here's what happens during the process:
The time stamp is used to determine a “last writer wins” scenario if there's 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. Here's what happens during the process:
1. The user starts an application, which also starts the virtual environment.
2. The application’s virtual environment checks for the most recent time stamped .zip file, if present.
@ -334,7 +334,7 @@ The time stamp is used to determine a “last writer wins” scenario if there i
6. After the .zip file is successfully extracted, the local cache of the roaming AppData directory is renamed and the new data 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 process does the following things:
This process 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 process does the following things:
1. During repair, detects if the path to the user’s roaming AppData directory isn't local.
2. Maps the non-local roaming AppData path targets, recreating the expected roaming and local AppData locations.
@ -344,7 +344,7 @@ This process will recreate both the local and network locations for AppData and
## 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 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 input as PowerShell commands on the computer running the App-V Client.
In an App-V Full Infrastructure, after applications are sequenced, they're 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 input as PowerShell commands 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/download/details.aspx?id=38177).
@ -357,7 +357,7 @@ The publishing refresh process comprises several smaller operations that are per
- **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.
- **Sync-AppVPublishingServer** initiates an App-V Publishing Refresh process manually. This process is also utilized in the scheduled tasks created during configuration of the publishing server.
The following sections will elaborate what goes on during the publishing refresh process.
@ -365,7 +365,7 @@ The following sections will elaborate what goes on during the publishing refresh
Adding an App-V package to the client is the first step of the publishing refresh process. The end result is the same as the **Add-AppVClientPackage** cmdlet in Windows PowerShell, except the publishing refresh add process contacts the configured publishing server and passes a high-level list of applications back to the client to pull more detailed information, rather than just doing a single package add operation.
The process then configures the client for package or connection group additions or updates, then accesses the appv file. Next, the contents of the appv file are expanded and placed on the local operating system in the appropriate locations. The following is a detailed workflow of the process, assuming the package is configured for Fault Streaming.
The process then configures the client for package or connection group additions or updates, then accesses the appv file. Next, the contents of the appv file are expanded and placed on the local operating system in the appropriate locations. The following steps are a detailed workflow of the process, assuming the package is configured for Fault Streaming.
#### How to add an App-V package
@ -373,9 +373,9 @@ The process then configures the client for package or connection group additions
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 more requests to the server for more information on a per-package basis.
2. The Publishing Agent on the App-V Client will evaluate any connection groups that are unpublished or disabled, since package version updates that are part of the connection group cannot be processed.
2. The Publishing Agent on the App-V Client will evaluate any connection groups that are unpublished or disabled, since package version updates that are part of the connection group can't be processed.
3. Configure the packages by identifying the **Add** or **Update** operations.
@ -389,7 +389,7 @@ The process then configures the client for package or connection group additions
- Portable Executable Headers (PE Headers): Targets of extension points that contain the base information about the image need on disk, accessed directly or through file types.
- Scripts: Download scripts directory for use throughout the publishing process.
4. Populate the Package store by doing the following:
4. Populate the Package store by performing the following sub-steps:
1. Create sparse files on disk that represent the extracted package for any directories listed.
@ -409,7 +409,7 @@ The process then configures the client for package or connection group additions
4. Configure Connection Groups by adding and enabling or disabling.
5. Remove objects that are not published to the target (user or machine).
5. Remove objects that aren't published to the target (user or machine).
> [!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).
@ -421,7 +421,7 @@ The process then configures the client for package or connection group additions
> [!NOTE]
>This condition occurs as a product of removal without unpublishing with background addition of the package.
This completes an App-V package add for the publishing refresh process. The next step is publishing the package to a specific target (machine or user).
This process completes an App-V package add for the publishing refresh process. The next step is publishing the package to a specific target (machine or user).
![Package add file and registry data.](images/packageaddfileandregistrydata.png)
@ -452,7 +452,7 @@ During the Publishing Refresh operation, the specific publishing operation, **Pu
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 User Catalog information in the preceding sections for details.
Publishing an App-V Package that is part of a Connection Group is 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 User Catalog information in the preceding sections for details.
![package add file and registry data - global.](images/packageaddfileandregistrydata-global.png)
@ -460,7 +460,7 @@ Publishing an App-V Package that is part of a Connection Group is very similar t
### Application launch
After the Publishing Refresh process, the user launches and then relaunches an App-V application. The App-V Client checks the path to the user catalog for files created during publishing. After establishing rights to launch the package, 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. Once the virtual environment created and configured for the specific package and application, the application starts. This might seem like a lot, but the process in action is actually quite fast, and is optimized to minimize network traffic.
After the Publishing Refresh process, the user launches and then relaunches an App-V application. The App-V Client checks the path to the user catalog for files created during publishing. After establishing rights to launch the package, 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. Once the virtual environment created and configured for the specific package and application, the application starts. This might seem like a lot, but the process in action is fast, and is optimized to minimize network traffic.
#### How to launch App-V applications
@ -471,11 +471,13 @@ After the Publishing Refresh process, the user launches and then relaunches an A
- **UserDeploymentConfiguration.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's 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.
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 process execution 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.
@ -487,7 +489,7 @@ After the Publishing Refresh process, the user launches and then relaunches an A
### Upgrading an App-V package
The current version of App-V's package upgrade process differs from the older versions in its storage optimization. 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. During an upgrade in the new version, only new files are added to the new version store location, and hard links are created for unchanged files. This reduces overall storage by only presenting the file on one disk location, then projecting it into all folders with a file location entry on the disk.
The current version of App-V's package upgrade process differs from the older versions in its storage optimization. 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. During an upgrade in the new version, only new files are added to the new version store location, and hard links are created for unchanged files. Such results reduce overall storage by only presenting the file on one disk location, then projecting it into all folders with a file location entry on the disk.
#### How to upgrade an App-V package
@ -521,7 +523,7 @@ If you try to upgrade a package that is currently in use, the upgrade task is pl
| Task type | Applicable rule |
|---|---|
| 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. |
| User-based tasks, such as publishing a package to a user | The pending task will be performed after the user signs out and then signs back in. |
| 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:
@ -542,19 +544,19 @@ Use the following example scenarios as a guide for updating packages.
| Scenario | Requirements |
|---|---|
| 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 App-V Client sets the operation to "pending," which means that it is queued and will be 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 won't be able to sign in. Users must sign off and then sign back in to initiate the App-V package upgrade.|
| App-V package isn't 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 App-V Client sets the operation to "pending," which means that it's queued and will be carried out later when the package isn't 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 won't be able to sign in. Users must sign off and then sign back in to initiate the App-V package upgrade.|
### Global vs. user publishing
App-V Packages can be published in one of two ways; as user, which entitles an App-V package to a specific user or group of users, or as 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:
App-V Packages can be published in one of two ways; as user, which entitles an App-V package to a specific user or group of users, or as 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 isn't in use, consider the two types of publishing:
- Global publishing is when 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 publishing is when 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 signs in or when it is published again (periodically, ConfigMgr Policy refresh and evaluation, or an App-V periodic publishing/refresh, or explicitly through Windows PowerShell commands).
- User publishing is when 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 signs in or when it's published again (periodically, ConfigMgr Policy refresh and evaluation, or an App-V periodic publishing/refresh, or explicitly through Windows PowerShell commands).
### Removing an App-V package
Removing App-V applications in a Full Infrastructure is an unpublish operation and does not perform a package removal. The process is the same as the publish process above, but instead of adding the removal process reverses the changes that have been made for App-V Packages.
Removing App-V applications in a Full Infrastructure is an unpublish operation and doesn't perform a package removal. The process is the same as the publish process above, but instead of adding the removal process reverses the changes that have been made for App-V Packages.
### Repairing an App-V package
@ -577,12 +579,12 @@ When App-V applications are published to a computer with the App-V Client, some
- 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.
2. Ownership transfers from one App-V package to another when the owning App-V package is unpublished. This transfer won't 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 to integrate the application 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:
The App-V publishing files (manifest and dynamic configuration) provide several extension points to integrate the application 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 aren't 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
@ -598,7 +600,7 @@ The App-V publishing files (manifest and dynamic configuration) provide several
The shortcut is one of the basic elements of integration with the OS and is the interface for direct user launch of an App-V application. During the publishing and unpublishing of App-V applications.
From the package manifest and dynamic configuration XML files, the path to a specific application executable can be found in a section like the following:
From the package manifest and dynamic configuration XML files, the path to a specific application executable can be found in a section as shown in the following example:
```XML
<Extension Category="AppV.Shortcut">
@ -618,7 +620,7 @@ As mentioned previously, the App-V shortcuts are placed by default in the user
### File type associations
Users can use file type invocations or open a file with a specifically registered extension (.docx) to start an App-V application because the App-V Client manages the local operating system File Type Associations during publishing. File type associations are present in the manifest and dynamic configuration files, as shown in the following example:
Users can use file type invocations or open a file with a registered extension (.docx) to start an App-V application because the App-V Client manages the local operating system File Type Associations during publishing. File type associations are present in the manifest and dynamic configuration files, as shown in the following example:
```XML
<Extension Category="AppV.FileTypeAssociation">
@ -665,7 +667,7 @@ Users can use file type invocations or open a file with a specifically registere
### 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.
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 extra setup or configuration on the client to enable the shell extension functionality.
#### Requirements for using shell extensions
@ -679,10 +681,10 @@ 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. |
| Context menu handler | Adds menu items to the context menu. it's 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.|
| 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 more 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.|
| Column handler| Allows creating and displaying custom columns in Windows Explorer *Details view*. It can be used to extend sorting and grouping.|
@ -690,7 +692,7 @@ The following table displays the supported shell extensions.
### 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.
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 more details.
App-V supports registering COM objects from the package to the local operating system with two process types: Out-of-process and In-process. Registering COM objects is accomplished with one or a combination of multiple modes of operation for a specific App-V package that includes Off, Isolated, and Integrated. Integrated mode is configured for either the Out-of-process or In-process type. Configuration of COM modes and types is accomplished with dynamic configuration files (deploymentconfig.xml or userconfig.xml).
@ -698,9 +700,9 @@ For details on App-V integration, see [Microsoft Application Virtualization 5.0
### Software clients and application capabilities
App-V supports specific software clients and application capabilities extension points to register virtualized applications with the operating system's software client. This means users can select default programs for operations like email, instant messaging, and using the media player. This operation is performed in the control panel with **Set Program Access** and **Computer Defaults**, and is configured during sequencing in the manifest or dynamic configuration files. Application capabilities are only supported when the App-V applications are published globally.
App-V supports specific software clients and application capabilities extension points to register virtualized applications with the operating system's software client. This specific support means users can select default programs for operations like email, instant messaging, and using the media player. This operation is performed in the control panel with **Set Program Access** and **Computer Defaults**, and is configured during sequencing in the manifest or dynamic configuration files. Application capabilities are only supported when the App-V applications are published globally.
The following is an example of software client registration of an App-V-based mail client.
The following example illustrates a software client registration of an App-V-based mail client.
```XML
<SoftwareClients Enabled="true">
@ -752,23 +754,23 @@ The following is an example of software client registration of an App-V-based ma
Virtual applications don't always specifically utilize file type invocation. For, example, in an application that supports embedding a mailto: link inside a document or web page, the user selects the link expecting to access their registered mail client. App-V supports URL Protocol handlers that can be registered on a per-package basis with the local operating system. During sequencing, the URL Protocol handlers are automatically added to the package.
For situations where there is more than one application that could register the specific URL Protocol handler, the dynamic configuration files can be utilized to modify the behavior and suppress or disable this feature for an application that should not be the primary application launched.
For situations where there's more than one application that could register the specific URL Protocol handler, the dynamic configuration files can be utilized to modify the behavior and suppress or disable this feature for an application that shouldn't be the primary application launched.
### AppPath
The AppPath extension point supports calling App-V applications directly from the operating system. Administrators can provide access to App-V applications from operating system commands or scripts without calling the specific path to the executable from either the Run or Start Screen, depending on the operating system. It therefore avoids modifying the system path environment variable on all systems, as it is accomplished during publishing.
The AppPath extension point supports calling App-V applications directly from the operating system. Administrators can provide access to App-V applications from operating system commands or scripts without calling the specific path to the executable from either the Run or Start Screen, depending on the operating system. It therefore avoids modifying the system path environment variable on all systems, as it's accomplished during publishing.
The AppPath extension point is configured either in the manifest or in the dynamic configuration files and is stored in the registry on the local machine during publishing for the user. For additional information on AppPath review: [App Paths - A Virtual Application Extension in App-V 5.0](/archive/blogs/virtualworld/app-paths-a-virtual-application-extension-in-app-v-5-0).
The AppPath extension point is configured either in the manifest or in the dynamic configuration files and is stored in the registry on the local machine during publishing for the user. For more information on AppPath review: [App Paths - A Virtual Application Extension in App-V 5.0](/archive/blogs/virtualworld/app-paths-a-virtual-application-extension-in-app-v-5-0).
### Virtual application
This subsystem provides a list of applications captured during sequencing which is usually consumed by other App-V components. Integration of extension points belonging to a specific application can be disabled using dynamic configuration files. For example, if a package contains two applications, you can disable all extension points belonging to one application to only allow integration of extension points for the other application.
This subsystem provides a list of applications captured during sequencing which is consumed by other App-V components. Integration of extension points belonging to a specific application can be disabled using dynamic configuration files. For example, if a package contains two applications, you can disable all extension points belonging to one application to only allow integration of extension points for the other application.
### Extension point rules
The previously described extension points are integrated into the operating system based on how the packages has been published. Global publishing places extension points in public machine locations, where user publishing places extension points in user locations. For example, a shortcut created on the desktop and published globally will result in the file data for the shortcut (%Public%\\Desktop) and the registry data (HKLM\\Software\\Classes). The same shortcut would have file data (%UserProfile%\\Desktop) and registry data (HKCU\\Software\\Classes).
The previously described extension points are integrated into the operating system based on how the packages have been published. Global publishing places extension points in public machine locations, where user publishing places extension points in user locations. For example, a shortcut created on the desktop and published globally will result in the file data for the shortcut (%Public%\\Desktop) and the registry data (HKLM\\Software\\Classes). The same shortcut would have file data (%UserProfile%\\Desktop) and registry data (HKCU\\Software\\Classes).
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.
Extension points aren't 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're delivered. Below is a table that describes these two key rules.
|Virtual Extension|Requires target OS sequencing|Requires global publishing|
|---|:---:|:---:|
@ -791,7 +793,7 @@ Extension points are not all published the same way, where some extension points
## Dynamic configuration processing
Deploying App-V packages to a single machine or user is very simple. However, as organizations deploy App-V applications across business lines and geographic and political boundaries, it becomes impossible to sequence all applications with the same settings. App-V was designed to overcome this problem by capturing specific settings and configurations during sequencing in the Manifest file while also supporting modification with Dynamic Configuration files.
Deploying App-V packages to a single machine or user is simple. However, as organizations deploy App-V applications across business lines and geographic and political boundaries, it becomes impossible to sequence all applications with the same settings. App-V was designed to overcome this problem by capturing specific settings and configurations during sequencing in the Manifest file while also supporting modification with Dynamic Configuration files.
App-V dynamic configuration lets you specify a package policy at either the machine or user levels. Sequencing engineers can use Dynamic Configuration files to modify the configuration of a package post-sequencing to address the needs of individual groups of users or machines. In some instances, it may be necessary to modify the application to provide proper functionality within the App-V environment. For example, you may need to modify the \_\*config.xml files to allow certain actions to be performed at a specified time while executing the application, like disabling a mailto extension to prevent a virtualized application from overwriting that extension from another application.
@ -799,7 +801,7 @@ App-V packages contain the Manifest file inside of the App-V Package file, which
### Examples of dynamic configuration files
The following example 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, not to be a complete description of the specific categories available in each file. For more information, download the [App-V Sequencing Guide](https://www.microsoft.com/download/details.aspx?id=27760).
The following example 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 to show the combination of the files only, not to be a complete description of the specific categories available in each file. For more information, download the [App-V Sequencing Guide](https://www.microsoft.com/download/details.aspx?id=27760).
#### Manifest
@ -871,7 +873,7 @@ The following example shows the combination of the Manifest, Deployment Configur
App-V supports automatic packaging of side-by-side assemblies during sequencing and deployment on the client during virtual application publishing. App-V also supports capturing side-by-side assemblies during sequencing for assemblies not present on the sequencing machine. For assemblies consisting of Visual C++ (Version 8 and newer) or MSXML run-time, the Sequencer will automatically detect and capture these dependencies even if they weren't 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 privatized the assemblies, which limited it to one bit version per package. This behavior resulted in App-V applications being deployed to clients missing the required side-by-side assemblies, which led to application launch failures. This forced the packaging process to document and ensure that all assemblies required for packages were locally installed on the user’s client operating system. This task was both a management and implementation challenge due to the number of assemblies and the lack of application documentation for the required dependencies.
The side-by-side assemblies feature removes the limitations of previous versions of App-V, where the App-V Sequencer didn't capture assemblies already present on the sequencing workstation, and privatized the assemblies, which limited it to a bit version per package. This behavior resulted in App-V applications being deployed to clients missing the required side-by-side assemblies, which led to application launch failures. This failure forced the packaging process to document and ensure that all assemblies required for packages were locally installed on the user’s client operating system. This task was both a management and implementation challenge due to the number of assemblies and the lack of application documentation for the required dependencies.
Side-by-side assembly support in App-V has the following features:
@ -885,13 +887,13 @@ Side-by-side assembly support in App-V has the following features:
During publishing of an App-V package with side-by-side assemblies, the App-V Client will check for the presence of the assembly on the machine. If it doesn't detect an assembly, 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 in the base packages, as the connection groups don't contain any information about assembly installation.
>[!NOTE]
>Unpublishing or removing a package with an assembly does not remove the assemblies for that package.
>Unpublishing or removing a package with an assembly doesn't 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:
There're three specific categories of events recorded:
- **Admin** logs events for configurations applied to the App-V Client and also 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 Client's completed App-V operations.