Further to our Boston connection, Ryan Cobb’s blog around how to publish individual applications inside a package to different users found here, a few people have been asking me how that data configuration actually works.
Let’s take this example whereby we publish Office to an AD group and customise the deployment:
We click Grant Access, change the Assigned Configuration to Custom and then chose Edit
Here we can apply a custom configuration to apply to this deployed package for this specific user group. Here I am going to choose to exclude Excel from being published to this group by un-ticking it. There are a range of other things we can change here from Shortcuts to FTAs and more but we will leave these settings for another blog post! All that’s left to do is to right-click publish the package:
Now on the App-V client machine we have the Office package excluding Excel:
So how is this actually working? Let’s go behind the scenes….
Well essentially whenever we apply a custom configuration, a new xml configuration is being created which applies itself at the time of publishing. This is stored within the App-V Database in the PackageEntitlements table:
Here we can see each package, who it is entitled to and also if there is any custom configuration applied. The last package is this list is our Office package, the SSID of the user group the package is published to and then under UserConfigurationContent is the complete xml configuration file, we can paste this out to notepad and view the entire contents, here I have found the location where it specifies Excel is disabled:
Pasting into Notepad isn’t the best way to view this custom configuration as you can probably appreciate from the screenshot, luckily the Management Server Interface gives us an easy way to export the configuration from the same place we configured it:
Opening up this file allows us to get better formatted view of this file and clearly see where Excel is explicitly disabled:
This export functionality is great if we want to replicate the deployment and/or slightly adjust it for another set of users. So how does the client know to use this custom configuration? This is handled by the Publishing Server and if we hit the URL for the Publishing Server from the client machine we can expose the applications that are published to the user:
Here we can see the applications published and for the Microsoft Office 2013 package we can clearly see there is an additional reference to the custom configuration with an ID that equals 17 as stored in the database! I hope that explains how custom user configurations actually work!
To read about how conflicting configurations are handled click here
Great Post. Very Interesting. How easy would this to apply to none microsft applications which require a different set of shortcuts for a differnt set of ODBC Settings depending on AD group?