Share via

App-V 5: On Dynamic Configuration

  • Article

When you create a package using the App-V sequencer, everything that you will need for the package will be self-contained inside the .APPV package file. In addition to the file and registry assets, the APPV file also maintains XML metadata that governs the operating system integration configuration and extension points. This configuration is referred to as the manifest configuration. Most of the key information revolving around this information is found in the AppxManifest.xml and [Content_Types].xml files inside the package. You can view these files by renaming the extension of the App-V file to .ZIP and browse the contents using Windows Explorer.

In many deployment situations, you may require some slight adjustments to specific configurations and/or certain operating system extension points. It would be very cumbersome and unrealistic to have to open these packages up in the sequencer to make simple minor changes that affect only this metadata.

Dynamic Configuration is what allows Administrators to make these modifications to an App-V package without having to make any changes to the AppV package itself. Dynamic Configuration are XML files similar to the legacy OSD files in previous versions of AppV and Softgrid. Unlike the OSD files, the dynamic configuration files are technically optional. Unlike the SFT package with earlier versions of App-V and Softgrid, the APPV file is technically all you need to publish and App-V package in version 5.

But let’s say we want to adjust the deployment configuration or other user-specific settings. We have two type of dynamic configuration files:

  • The Dynamic Deployment Configuration file: <PACKAGE_NAME>_DeploymentConfig.xml
  • The Dynamic User Configuration: <PACKAGE_NAME_UserConfig.xml

We can use these configuration files to do a number of things, including:

  • Assign scripts to run during specific package\application events

  • Enable or disable a virtual subsystem

  • Override Shortcut Configuration

Dynamic User Configuration

The Dynamic User Configuration (<PACKAGE_NAME>_UserConfig.xml) file contains information that applies configuration for the package to the individual user. For example, if you supply shortcut configuration within this file, this will override the shortcut configuration that is contained within the package manifest. Also note, that if a Dynamic Deployment Configuration exists for the package, Dynamic User Configuration replaces the “User Configuration” section.

Dynamic Deployment Configuration

The Dynamic Deployment Configuration (<PACKAGE_NAME>_DeploymentConfig.xml) file contains information that applies to all users of that machine. It can have a “User Configuration” section which can be overridden by dynamic user configuration.

Example:

Let’s say you have a package deployed with the following extension point configuration:

  • Package Manifest: Contains two shortcuts
  • Dynamic Deployment Configuration: Has the shortcut subsystem enabled and two extra shortcuts targeted to users. Shortcut 3 and 4.
  • Dynamic User Configuration: Also has the shortcut subsystem enabled and one extra shortcut. Shortcut 5

In the example above, there are five shortcuts across all of the configuration files. To determine the effective configuration, we use the following formula:

  • If no dynamic deployment configuration or dynamic deployment configuration provided, Shortcut 1 and Shortcut 2 are integrated
  • If dynamic deployment configuration is provided, only Shortcuts 3 and 4 are integrated
  • If dynamic user configuration is provided, only Shortcut 5 is integrated
  • If both dynamic deployment configuration and dynamic user configuration are provided, only Shortcut 5 is integrated

 

Package Events and the Application of Dynamic Configuration

Dynamic Configuration can be applied using the Add-AppVClientPackage and Publish-AppVClientPackage package events. Dynamic Deployment Configuration can be optionally applied using the following syntax:

Add-AppvClientPackage <path to package> [- DynamicDeploymentConfiguration <path to file>]

While the configuration is added and downloaded, it will not take effect until the Publish Package event. At this time, optional dynamic user configuration can also be applied using the following syntax:

Publish-AppvClientPackage … [- DynamicUserConfigurationPath <path to file>] [-Global]

If Dynamic Deployment Configuration is provided on package add  and/or Dynamic User Configuration is provided on package publish (to user), they will be used during publishing integration. The [UserConfiguration] section (if available) from Deployment Configuration only is used during global publishing (thus targeting all users.) If the –DynamicUserConfigurationPath is specified using the Publish-AppVClientPackage cmdlet with the –Global switch, then the command will error out. The UserConfiguration section (if available) from the dynamic deployment configuration file is used if no explicit dynamic user configuration file is specified during Publish package operation.

Once the package has been deployed and the configuration has been applied, it is cached locally in the following locations:

  • Deployment Configuration:  %ProgramData%\Microsoft\AppV\Client\Catalog Packages\<PkgGuid>\<VerGuid>\DeploymentConfiguration.xml
  • Dynamic user configuration file (if published to user) in both %AppData%\Microsoft\AppV\Client\Catalog \Packages\<PkgGuid>\<VerGuid>\UserConfiguration.xml

and %ProgramData%\Microsoft\AppV\Client\Catalog \Packages\<PkgGuid>\<VerGuid>\UserConfiguration.xml

But What if you are using a Publishing Server?

Since the publishing agent on the App-V client combines Package Add and Package Publish into a special event (Configure Package.) The default configuration will still be the configuration within the manifest, however, if you added optional deployment and user configuration data, it too will be downloaded with the package configuration. The App-V Client publishing agent can also optimize dynamic configuration content download and subsequent add/publish if client already has matching package with dynamic configuration. Bear in mind if you run into a potential conflict where you may have the same package deployed from multiple publishing servers with different dynamic configuration, the last configuration to download will override and become the effective configuration (last writer wins.)