DesktopNow 8 FR4 - When to layer when to merge?

AppSense have recently released the rebranded Management suite as AppSense Desktop now version 8 Feature release 4.
There are a number of great new features a couple of which are discussed here. They are Configuration Layering and Configuration Merging. So what are they and what are the differences and for that matter similarities or are they mutually exclusive? Some of this will be based on only what your use case is, so feel free to disagree but often times functionality gets used in different ways than the use cases it was specifically designed for.
So let’s start with configuration layering.
Layering is done at the console side, and as the name suggests layers one or more configuration over the other. Why would you layer configs?
Say you have multiple sets of administrators, infrastructure admins for server based config and desktop config, and application admins for the application deployment and config. Each of these teams may well develop, test and deploy their own parts of a production config. This can lead to issues about multi concurrent editing of the one configuration, i.e. who has made what changes to it and where, when is it ready to deploy whose changes are in it etc. etc.
Layering allows those teams to independently develop their own parts of the config and when ready come back and layer it over the base config. Once this combined “layered” config is saved it can be deployed as a normal configuration, saving the meticulous checking of a single config that may have been edited independently by numerous administrators to ensure that actions are not duplicitous or contradictory, or that settings have not be overwritten.
In the below example is a Base configuration which contains settings for Windows 7 and Windows 2008 settings applicable to security, look and feel etc. It has been configured by a desktop admin, and it has no application settings. Then an application administrator has separately been developing an application specific config with some process start actions in relation to two new apps being deployed. We are going to layer the application config over the baseline to create a complete baseline plus application config.
So what about Configuration Merging?
Unlike layering which is done at the console side, merging is all done at the end point. It provides the capability to deploy any kind of configuration, and then to send out a second, third etc. config and have the client as the name suggest merge these together, aggregating the actions within both.
So why would you use this?
Again using the same example as above you may have a baseline configuration, or possibly you already have a complete configuration with  all of your application process start actions. But now you have a new application being deployed or updated and you need some new process start actions deployed quickly. If your're a large enterprise you are likely to have to go through some rigorous change control process which is likely to be lengthy if you would traditionally deploy a config to every end point. This could be reduced by reducing the number of in scope end points. Let's say this application was going to 100 people of the total 100,000 endpoints. You could push out a config with just your new process start actions under a quicker change control process and have those actions live quicker. The "to be merged" config can be pushed out using any ESD tool, and the agent will seamlessly combine the new "to be merged" config with the existing config, and your application dependant process start actions are already.
There are many use cases for this, you may want to keep all application settings separate in an Application only config. Or do you need to separate out your business units? They could have a specific config that only relates to them that sits above your baseline config, giving you the ability to distribute them separately.
Configuration Layering Example:
Open your Baseline configuration in the normal way. Whilst your there enable another nice new FR4 feature - "Change Tracking". This is a great new feature that should be a best practice to enable anyway in any and all config's and is seen in a few places that can prove to be helpful later on.
Click on the "Enable Change Tracking" button.

Click on the Manage Layers Tab, then click on the Add Button.

This will then open the "Add a layer" window.

Click on the Down arrow next to the Add button at the bottom. Clicking on the add button directly defaults to opening an .aemp file from disk. The arrow allows you to select opening a config from the mgmt. centre or sccm, and hence if that’s where you're "to be layered" configs are then use this. Select your "to be layered" config as if you were opening any config. 
Select your configuration, as per the Applications config, which will then take you to the Add Layer screen.
Anything underlined is a link. Following the link in the Name column will take open the application config in the EM Console. Any errors reported can be viewed following the link in the Errors column, and if you have enabled change tracking you can view the history of the config you are layering over the top by using History link:
The result is that my base config now has the process start actions from the separately created applications config.

Now I can save this config back to the management centre in the normal process as the next version. Doing this will keep the layer manageable as a separate layer. The layered can be easily rolled back, by clicking on the Rollback button, this shows you the current version that is layered.


Don't think you just click on OK here, this won’t de-layer this current layer, you have to find a previous version. Click on the layer, then click on browse and find a previous version of this config i.e. version 1.

Now it shows you what the current and the rollback version is, it does its analysis and shows any errors, if all good, it rolls back to version 1 of this config.

Clicking on the Manage button allows you fully merge the config in and make it permanent . This then removes the layered concept such that this layer cannot be managed separately it becomes a single config that needs to be saved as per normal.

Configuration Merging Example.
In my example I have already deployed my baseline configuration using our ESD. But now I need to push out an updated small configuration update. Now admittedly I could just update the baseline config and deploy that, but as per the example given above that may not always be the best option.

So first thing you need is an 8 FR 4 version of the agent. Secondly you need an accompanying manifext.xml file that configures the merge process. To do that you need to use the manifestgen tool. The console help file said that this was in %programdata%\AppSense\Environment Manager\MergeConfigs, however it may have just been me but I could only find it actually on the personalisation server in %programfiles%\AppSense\Environment Manager\Console\ManifestGen.exe

I copied this locally to an endpoint into %programdata%\AppSense\Environment Manager\MergeConfigs and ran it from there. But there are switches meaning you can run it from anywhere and add the options to make it work once the manifest.xml is generated and deployed with the configuration.aemp file to the same local location on the endpoint that I have manually run it in for this example. I suggest you look at the help on this command and see the options that are available.

Thirdly you need to be aware that the merged config has to be an .aemp file, it can’t be another MSI of the config, so you will need to "Save As" your config in the console to disk, then use your  ESD to deploy this with your manifext file, into  %programdata%\AppSense\Environment Manager\MergeConfigs on your endpoint. You can not use the Management Centre to distribute this to be merged configuration file. Maybe this will become an option of the management centre in a later realease.

If you have auditing enabled add events 948x to alert on all merge actions.
To start I have a normal configuration deployed as normal. I have additionally created an applications.aemp file and saved it to disk. Now I need my manifest xml file. If this file is created remotely it needs to be deployed with the applications .aemp file. In this example I have already placed the applications.aemp file in the \mergedconfigs folder on the end point.
Now on the endpoint open an elevated command prompt and enter your manifestgen command. Here is where you need to review the helpfile for the various options available to you. This example will just use the simplest command. But you can specify output locations of you were running this on a personalisation server in preparation to deploy the manifest, you can likewise define what config is your base etc.
I have run "manifestgen *.aemp".

This merges all *.aemp files in the \mergedconfigs folder with the existing configuration. This will create a new merged_configuration.aemp in %programdata%\AppSense\Environment Manager which is now effectively the new config file, which includes what was in the original configuration.aemp file and now the merged applications.aemp.
 In addition the agent creates a file called last_merge_manifest.xml that when opened shows the result of the last successful config merge attempt.

If the merge fails it will created a "failed_merge_manifest.xml" file, and likewise write to the event log defined in auditing.
So there you have two examples of many were you could use either merging or layering, or both.


Popular posts from this blog

Reassign a WVD Personal Session Host

AVD and Azure Active Directory Domain Join public preview

How to deploy a Windows Virtual Desktop host pool using Infrastructure as code from Azure DevOps