App-V integration with Configuration Manager 2012 SP1 and R2 is better than it has ever been. With App-V applications now a fully respected member of the application model, with features such as virtual environments and supersedence it makes for an altogether more polished solution.
One thing I often get asked about is how does Configuration Manager (CM) handle App-V configuration .xml files when we need to customise our deployments compared to the App-V Management Server.
Now the first thing to highlight is CM will not successfully import a package as App-V 5.0 if it doesn’t find the either the deploymentconfig.xml or userconfig.xml, it needs both at time of import.
Another important thing to know is when there are multiple .xml configs to choose from CM will automatically pick the latest time stamped files. Naming doesn’t matter here as shown below:
The “- Newer Copy” file is the one that gets pulled in during import as shown purely because it has a newer time stamp.
So that’s great if all you need to happen is that at time of import the latest .xml configs are pulled in, however most of you will want more control than this concerning multiple configurations.
Multiple Dynamic Configuration .xmls
The options for deploying different configs to different targets are shown below:
Basically you have two options both which start by first creating mutlple directories per instance of config .xml.
Create Multiple Directories
So whichever approach you are going to take first you need to put your content into multiple directories. The easiest way to do this is to keep the root directory for your App-V application in your source clear from files and create sub directories for each type of deployment which holds copies of your entire content with the specific configs .xml files:
You shouldn’t have any concerns about storage on your distribution points as CM will leverage single instance storage to ensure that only unique files will be replicated however in terms of your source location storage you will need to take this into consideration.
Create Multiple Applications
This is the first option you have for getting your applications out there and it basically entails you creating a separate application per sub directory. Essentially importing each sub directory individually as an application in its own right, there is more info on this process here. You end up with something like this as a result:
You can then of course go ahead and target these applications at whatever collections you like based on your customisations.
Create Multiple Deployments
This is your second option and it only requires you to create your application once, this would be the default configuration you required. It is then up to you to leverage multiple deployment types unique to each different config .xml.
For every new deployment type you create you can specify the new sub directory housing your different configurations.
We can then use the CM requirements feature to dictate which type of objects will qualify for this deployment type.
For example above I have created a requirement that the machines that qualify for my RDS deployment type for my package have to reside within the RDS organisational unit in my Active Directory structure.
Requirements can be generated against any of CMs Global Conditions for users (to identify a primary device) or computers, additionally custom queries can be leveraged when the built in conditions are not sufficient. In many ways this is more powerful than any other method for delivering dynamic configuration as the assessment is not static, it assessed at the time of deployment for conditions other than group membership or collections, such as above with OU membership, total physical RAM, available disk space and many other conditions.
Once you have created your deployment types what you will end up with is a single application with multiple deployment types:
Pay attention to the priorities as your CM client will assess eligibility for each deployment sequentially so the first deployment it meets the conditions for will be the one it gets alongwith the customer .xml configuration.
For that reason it is a good idea to put your most open/unrestricted deployment type at the end of the list with the least priority giving the more specific deployment types a chance to catch your target machines/users!
What about updates?
So everything mentioned above is all well and good, as long as we adequately manage our content directories and either multiple applications or multiple deployments per configuration…..but what about updates?
Well the story is good provided you update the whole package alongwith editing the configs .xml files, i.e the package goes through the sequencing process and is saved with a new version ID. Next time CM delivers the updated package to a client, regardless of whether the previous version is already there or not, the new deploymentconfig.xml will be applied at add time and the new userconfig.xml will be applied at publish time, no stress!
However the story isn’t as good if you just want to update the config .xml for a package that has already been deployed without changing the .appv itself or going through the packaging process. There are three options of which two rely on using the Compliance feature of CM alongwith scripts to interrogate which .xml configurations are currently on the client and the third which requires the deployment type itself be a script deployment type essentially leveraging standalone functionality. In my opinion from a manageability stand point in most instances it would be easier to update the whole package in the sequencer and either re-import it as a new application or new deployment type as discussed in this post.
All of these techniques and more are discussed in detail in the Integrating Virtual Application Management with App-V 5 and Configuration Manager 2012 SP1 Whitepaper which can be downloaded here.