When you create an App-V package using the App-V Sequencing tool that Microsoft provides, as well as the actual App-V package, itself (‘PackageName.appv’), you also get a couple of external files named PackageName.DeploymentConfig.xml and PackageName.UserConfig.xml. These default template files can be modified to influence the behaviour of your package in subtle and interesting ways without the need for any resequencing. This applies either at a machine or user context level, respectively.

Start here for Microsoft’s documentation on all the interesting things you can do with these files. https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/appv-v5/about-app-v-50-dynamic-configuration

Until recently, however, when deploying your App-V packages with Citrix XenApp in ‘Single Admin’ mode, no account of these dynamic configuration files was made and we could only publish the .appv package file on its own. XenApp 7.16 added some support for using Dynamic Deployment Configuration files. With XenApp 7.18, we now have support for Dynamic User Configuration files as well; plugging an important gap for many users.

This article describes what you need to do to have XenApp take account of your Dynamic Configuration files, what you can expect and where the limitations lie.

How does it work?

It’s simple, really! Everything (well, almost everything) that happens on the VDA to manage App-V packages is ultimately done via the Microsoft App-V PowerShell API. So, at its heart, this is simply a case of modifying the two API calls made at the appropriate times.Add-AppvClientPackage -Path \\AppVShare.my.org\PackageName.appvto readAdd-AppvClientPackage -Path \\AppVShare.my.org\PackageName.appv -DynamicDeploymentConfiguration \\AppVShare.my.org\PackageName_DeploymentConfig.xmlandPublish-AppvClientPackage -PackageId Guid -VersionId Guidto readPublish-AppvClientPackage -PackageId Guid -VersionId Guid -DynamicUserConfigurationPath \\AppVShare.my.org\PackageName_UserConfig.xml

Of course, the devil is in the subtle details! How do we know which file to apply  and when, to which user and how do we detect and react to a changes in the config files?

It’s all in the name

It is important to note here that XenApp will not try to manage your configuration files. We will simply apply them as we find them. The Citrix App-V publishing components on the VDA will look for configuration files next to, and named the same as the package to which they apply. As this is what you get by default from the App-V Sequencer it should fit most scenarios. If you don’t want these files applied, simply remove them or rename them in a way that will cause XenApp to ignore them.

For the Deployment Configuration the is only one option PackageName_DeploymentConfig.xml.

But for the User Configuration, you may have different requirements for different users and we need to figure out which file to apply during the publishing. If no other suitable file is found according to the rules outlined below, the default file PackageName_UserConfig.xml will be applied for all users. To have a specific file apply to an individual or group of users, you can user either of these file name formats

  • PackageName_[option]_UserConfig.xml
  • PackageName_UserConfig_[option].xml

where the [option] is one of these

  • User SID
  • User Name
  • AD Group SID
  • AD Group Name

The publishing command will prefer files for a given user in the order listed above, I.e. the most specific first. So you could have a generic catch-all file with the default name, a more specific one for a particular AD Group and another which applies only to an individual user in that group. The correct file will be applied to the publishing command according to which user’s session is making the launch request on the VDA.

For example, your package’s directory may look something like this:

Custom Configuration Mapping

Perhaps the above naming conventions don’t match what you have already created in your environment, or you manage your configuration files in a different directory structure, away from the actual package files. Well you have another option. If no Deployment and/or User Configuration file is found next to the package, instead we will look up the directory hierarchy to the root for a file named ctxAppVDynamicConfigurations.cfg

Inside this file we will expect to find records for Deployment Config files with the format… packageGuid : PathToDeploymentConfig or for a User Config… packageGuid_[option] : PathToUserConfigWhere the option is the same as before. Note that in this case, however, the first line that matches the current user and package combination will be the one that is applied, so it is important to arrange the file with the most specific records first.

What to apply when?

As administrators modify configuration files on the file share, you will expect those changes to be applied to the package the next time the user launches the application using XenApp. We will try to do this but it is not always possible.

  • To have a Deployment Configuration file take effect, the package must be removed and re-added to the machine. This can only be done if the package is not in use by any user.
  • To have a User Configuration file take affect the package must be unpublished and re-published for the current user. This can only be done if the user in question does not have the package running, but other users could be using the package at the time.

We will never fail a launch because we could not perform these steps, or kill an active virtual process so that we can reapply Dynamic Configuration files. If it can’t be done, a message will be written to the CDF trace and the process will be skipped. Another attempt will be made on the next and subsequent launches until it is successful.

So how do we know when a file has changed? Simply by looking at the LastWriteTime on the files. If the one on the network share is newer than the one that was used to add or publish the package we use the new one. The following rules apply…

  • A newer file will be re-applied in the presence of an older one
  • If a file is defined but not applied, it will be applied
  • If a file is applied but not defined it will be removed

Limitations

Aside from the constraints mentioned above when applying changes to configuration files whilst packages are in use; the main known limitation is in the modification of shortcuts. Dynamic Deployment and User Configuration files can be used to add or modify the shortcuts that are provided by the package. Because XenApp publishes App-V applications from the AppLibrary, only those applications and shortcuts which the AppLibrary knows about (i.e. those discovered from the AppManifest) are available for publishing in Storefront. XenApp knows nothing about extra shortcuts added ‘after the fact’.

However, if the user has access to the desktop session where packages have been published in this way, those extra shortcuts should appear as expected and can be interacted with directly, just the same as if the package had been published with its dynamic configuration via any other mechanism.

Of course we will welcome your feedback on what successes (or otherwise) you have with the use of Dynamic Deployment and Configuration files in XenApp 7.18.

Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more TechBytes and subscribe.

Want specific TechBytes? Let us know! tech-content-feedback@citrix.com