App-V 5: On Dynamic Configuration

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.


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.)


Comments (5)

  1. Bruce says:

    How do you set the default key value for a registry key using your dynamic config xml file? So we understand each other .. in a .reg file that would be written like this:

    @=”hello world”

    a reg.exe command would be like this: reg.exe HKCU\Software\Foo /d “bar”

    In App-v config I have tried a half dozen ideas and cannot get the magic handshake to work. Using the @ symbol does not work, using nothing does not work, actually using Name=”(Default)” etc. How do you set the default value for the key?


    1. Bruce says:

      I seem to have been wrong – going with Value=”” does work for setting the default value of a registry key, i.e. in the machine config:

      so .. never mind!

  2. keerthi says:

    Nice article!
    Consider a scenario utilising AppV 5.0 SP3 where Global Publishing refresh scheduled task is removed and only User publishing refresh is configured at logon and regular intervals.

    Using Dynamic Deployment Configuration (not dynamic user configuration), if we utilise the User Configuration Section to implement registry keys (HKCU Keys), will Client be able to create the HKCU Keys?

    I have used below settings in Dynamic Deployment Configuration User Configuration Section
    Registry Enabled="true"
    Key Path="REGISTRYUSERControl PanelInternational"
    Value Type="REG_SZ" Name="sShortDate" Data="yyyy-MM-dd"/

    If yes, Where can we find this registry key creation in native registry.
    Will it be in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientPackagesPackage_GUIDVersionsVersion_GUIDREGISTRYUSER

    I notice that the machine scripts implemented work as expected in this scenario. Publishing is via Full Infrastructure.

  3. Anonymous says:

    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like

  4. Anonymous says:

    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like

Skip to main content