Kirx' Blog - kirxblog.wordpress.com

Deployment Models and Dynamic Configurations in App-V 5 | September 9, 2013


With App-V 5 Microsoft introduced the concept of Dynamic Configurations, allowing to manage and control the way how virtual applications integrate into the base OS or how the virtual packages behave on clients. One of the main benefits of Dynamic Configurations is the ability to apply different settings to different machines or users. However, these Dynamic Configurations are applied differently, depending on the distribution model. In this article we’ll show that the old principle of “A package’s virtual resources are equal regardless of the deployment model’ has changed in App-V 5.

In short: Just having or modifying the XMLs is not enough, in no scenario!

In the ‘all better’ version 4 of App-V, there was an essential and fundamental statement: The content of a virtual application package (we used to call that ‘virtual environment’ before) is always the same, regardless or the deployment method. Ment van der Plas wrote a whitepaper to emphasis this. Essentially, there was the .sft file for the ‘static’ content, and there were .osd files for applying dynamic settings (like run scripts to map group specific network drives, load different configurations for development / test / production back end systems or load group or user specific information). In v4, whatever method you used to deploy the packages (native server, SCCM, MSI, SFTMIME), the .sft and mostly all according .osd files were loaded.

In App-V 5, there is a lot of more flexibility when it comes to dynamic modifications to the virtual package’s runtime behavior. App-V now uses a set of configuration files to determine the actual environment (1).

Configuration Scopes

The package: During sequencing, a lot of settings are captured and stored inside the .appv file. Things like Shortcuts, File Types and many others are referenced in the AppXManifest.xml file, stored inside the .appv file. Usually you don’t modify these definitions. Actually there isn’t even a straight forward way to do so.

The Deployment Configuration (sometimes also called Default Configuration) defines settings that are applied to a target machine and affect all users working on such a machine. On a given machine, only one DeploymentConfig can be active. A deployment config can contain a Machine section (for settings that target the computer, like scripts that install a prerequisite) and a User section (for settings that target the user environment, like user scripts, shortcuts or file type associations). DeploymentConfiguration settings with the User scope affect all users on a system. You can only apply one DeploymentConfig per package per machine (but you can update/modify it).

The User Configuration settings will be applied to users. You can (depending on the deployment model) have different user configurations for a package that you can assign to different users. Of course you cannot modify machine properties with user configurations, but you can adjust (add, remove, change) user specific properties like user scripts, shortcuts and so on.

Because they are located outside the .appv file, we will refer to the combination of DeploymentConfig.xml and UserConfig.xml as external configuration files.

Steve Thomas’ http://blogs.technet.com/b/gladiatormsft/archive/2014/03/18/app-v-5-on-dynamic-configuration.aspx provides some additional info on this.

Let’s see how these dynamic configurations can be leveraged by the major package deployment models of App-V 5.

Deployment Models

Client Powershell

The most flexible and really easy to understand method of dealing with Dynamic Configurations is Powershell.

The Deployment Configuration can be applied as a parameter of the add-appvclientpackage cmdlet.

Add-AppvClientPackage ‘<path to .appv file>’ –DynamicDeploymentConfiguration ‘<path to deploymentconfig.xml>’

To apply updated configurations, run the add-AppvClientPackage command again with the updated DeplyomentConfig.xml or use the set-AppvClientPackage command.

A User Configuration can be applied as a parameter of the publish-appvclientpackage cmdlets

Publish-AppvClientPackage –package <PackageObject> -DynamicUserConfiguration ‘<path to userconfig.xml>’

It is often said that you can apply different user settings to different users or groups with App-V 5. In fact this is true, however there is no built-in method to achieve that. What you’d have to do is to establish a solution that handles the user-to-config-file assignment for you. You could initiate the PoSh based publishing as part of the user logon process and use a script there to make the differentiation. For instance you could create a script that identifies a user’s group membership (like AppvPublish_OperaBrowserDesktopIcon) and point to a respective xml file (<package>_UserConfig_AppvPublish_OperaBrowserDesktopIcon.xml). I do know that this approach isn’t the best, but you should get the idea behind it and improve the concept for your own.

Package Specific MSI

When you are using the MSI, the short answer is: No:

None of the (external) Dynamic Configuration XML files are applied. Only settings inside the .appv file will take effect.

If you want to apply deployment and/or user configurations, you would have to execute the PoSH command from above on top (resp. after) the MSI. And of course you have to ensure that the settings are applied again if the MSI updated the client package. Luckily there is a helper: check out the tools section below.

Note that I have no idea what happens if you install per MSI, activate some dynamic configs, uninstall the MSI and reinstall the MSi again. I’d expect that the dynamic configs are gone, but I haven’t tested it.

App-V Management Server / Management Console and Powershell

When you import an App-V Package into the web-based management console, none of the external configuration files will be imported automatically.

Deployment Settings or User Settings configured in XML files are only applied to a client after they have been imported into the Management Server’s web based console or via Powershell..

The client will receive only settings as they are defined internally in the .App-V file. The good thing is, that the management console allows you the following

  • – You can access a few settings via the ‘Edit Default Configuration’ property of a package. Here you can
    • Enable or disable individual applications (affecting their shortcuts, file type associations and other integration points)
    • See (but not modify) file type associations
    • Modify shortcuts- You can load/import a DeplyomentConfig.xml file as an ‘advanced’ operation for a package
  • – You can access a few settings vie the “Edit Active Directory” property of a package. This leads you to a list of AD (Group) assignments. For each entry in that list you can select to use a ‘Custom’ Assigned Configuration.
    • Enable or disable individual applications (affecting their shortcuts, file type associations and other integration points)
    • See (but not modify) file type associations
    • Modify shortcuts- You can load/import specific UserConfig.xml files as an ‘advanced’ operation for an AD Assignment entry.

Note that you can do both: use the web console’s GUI to adjust Shortcuts and import xml files. However, importing an XML overrides changes done via the GUI. As a best practice, export the settings first before you import anything. If you want to do both, Import Settings and adjust them in the GUI, first Import the XML file before you adfjust the shortcuts using the web console.

On the App-V Management Server, there are also several Powershell cmdlets that allow you to manipulate, import or export deployment configurations and user configurations.

Set-appvserverpackage with the parameters –DynamicDeploymentCOnfigurationPath <Path> and/or –DynamicUserConfigurationPath <Path> –Groups <Groups> are the ones to look at. Note that get-appvserverpackage allows to export the current settings.

System Center Configuration Manager

In ConfigMgr 2012 SP1, importing an .appv file automatically imports exactly one DeploymentConfig and one UserConfig xml file in the same location.

If multiple files are detected in the folder during import, ConfigManger chooses the newest one of each kind.

If you want to leverage different configuration files (of the same scope) for a package, you could create X subfolders, each having the same .appv file and the specific dynamic configuration xml. Then, there are two basic options

  • Create X applications in ConfigMgr, Import each folder separately and create a deployment type for each of the X applications
  • Import one application and create X deployment types based on SCCM Global Conditions

Every update of the App-V package in ConfigManager causes the Dynamic Configurations to be re-applied.

The Whitepaper Integrating Virtual Application Management with App-V 5 and Configuration Manager 2012 SP1 explains more details and it contains advanced update scenarios. Note that SCCM’s Single Instance Storage avoids X times space consumptions for identical .appv files

Tools

There are several tools or methods to modify the two external occurrences of Dynamic Configurations. Any text editor may be used to modify the XML files. Indeed editors that specifically target XML files should be preferred over text editors, because they offer features like attribute highlighting and basic error indications. There is also a freeware tool, VirtualEngine’s App-V Configuration Editor. ACE allows to modify settings that are required by most implementations. While it is a little bit less flexible than text editing, it ensures well-formatted XML files and correct spelling of App-V specific attributes and values.

To modify configurations inside an App-V Package, the Sequencer itself can be used to a certain extend. It monitors and collects all relevant changes during the monitoring phase, but only allows to adjust shortcuts and file type associations with its graphical interface. Though it always creates a folder for scripts inside the package it does not offer any user friendly method (actually no method at all) to point to these scripts. Modifications are only possible after the package has been saved… again only through external files.

The one solution that can modify both, internal and external configurations with a single, graphical user interface is Gridmetric’s Application Virtualization Explorer (I recently wrote a little bit about AVE here). It also supports to edit multiply configurations files (like UserConfig XML files) along a single package.

Furthermore, Dan Gough created a handy MST that integrates the config file deployment seemlessly into the MSI deployment process – without the need for additional scripting. Get the ApplyDynamicConfig MST.

Conclusion

With the exception of ConfigManager 2012 SP1 integration, every App-V package deployment model requires extended or additional steps to apply Dynamic Configuration XML files to App-V packages. Because Dynamic Configurations may or may not be applied automatically, and because the content of the XML files may or may not reflect the actually applied configuration, proper documentation, detailed task advices and perhaps even additional scripting is required to thoroughly manage Dynamic Configurations across an organization’s App-V deployment. Unlike in previous version, there is a clear impact of the deployment model and its defined processes on the resulting virtual application execution environment on the client.

Special care has to be taken!

To modify Dynamic Configuration Files, use AVE, ACE, or an XML editor.

(1) I’m always tending to call that a ‘virtual environment’ as we did in v4, but because the ConfigManager team decided to call their implementation of Application Connection Groups as Virtual Environments, this would cause confusions.

Advertisements

Posted in App-V, Client, Management
Tags: , ,

2 Comments »

  1. […] more information about Dynamic Configurations please read  Deployment Models and Dynamic Configurations in App-V 5 by Falko […]

    Pingback by Microsoft App-V: Dynamic Configurations or RES Workspace Manager? » Ingmar Verheij - The dutch IT guy — January 22, 2014 @ 16:02

  2. Packageology.com published a generic MST to streamline the config file deployment in MSI based scenarios: http://packageology.com/2014/03/applying-dynamic-config-app-v-5-msi-packages/

    Comment by kirxblog — March 7, 2014 @ 07:38


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: