Merging Configurations
Once a manifest is created and the component configurations are present on the endpoints, you can trigger the merge and create a new configuration.
A merge is triggered when a merge_manifest.xml is detected in the MergeConfigs directory which should contain all the configurations you want to merge.
If the manifest lists configurations which are not in the MergeConfigs directory, the merge will be delayed until all configurations are present. The base configuration and all component configurations in a merge must be version 10.0 of Environment Manager. Upgrade any older version configurations before merging.
To upgrade a configuration, open it in the required version of the Environment Manager and save. For example, open an 8.6 configuration in the10.0 console to upgrade.
Note ,if you use cache roaming and merging configuration functionality you will need to set the PreventUnapplyOnConfigChange registry key on all endpoints. Refer to Cache Roaming for further information.
Using the -nw tag, a manifest can be created which will fail a merge if all configurations are not present.
In this section:
Empty Manifest
Adding an empty manifest to the MergeConfigs directory automatically merges all AEMP configurations within that directory. It will merge all configurations in alphabetical order and set the base as the Configuration.aemp found in:
%ProgramData%\AppSense\Environment Manager
If this AEMP is not present, the merge will fail.
To create an empty manifest, open a new file in a text editor, create a zero-byte file and save as merge_manifest.xml.
The same merge can be achieved using a manifest that, whilst not totally empty, does not include details of the AEMP files to be merged:
<MergeManifest UseSystemBase="true"
<MergeFiles>
</MergeFiles>
</MergeManifest>
This provides the same results as a blank manifest but allows you to use the UseSystemBase attribute. If you set this to "false" the merge will use the configuration which is first alphabetically in the MergeConfigs directory, as the base.
Successful Merges
If the manifest is correct and the configurations listed are present in the MergeConfigs directory, the Merged_Configuration.aemp is created and used as the live configuration on the endpoint.
In addition to the new configuration (Merged_Configuration.aemp) a copy of the successful manifest is created, renamed as last_merge_manifest.xml, to provide a record of the merge and a backup of the manifest. If present, the original merge_manifest.aemp file is deleted when the merge is complete.
The Configuration.aemp file is not altered during a merge and is no longer used by the agent unless updated or the Merged_Configuration.aemp is not present.
Unsuccessful Merges
If an error occurs during the merge, it will fail and a new configuration file will not be created. Merges can fail if:
- The checksums specified in the manifest do not match those of the actual configurations and WaitForConfigs is set to "false"
- The manifest includes the -nw command and one or more configurations listed in the manifest are not present in the MergeConfigs directory when it is added
- Friendly names in the Run As Library are the same in two of the configurations being merged.
- UseSystemBase is set to "true" and a base Configuration.aemp is not present when the merge is triggered.
- A manifest is invalid.
- One or more configurations are corrupt.
Following an unsuccessful merge, the merge_manifest.xml file is deleted and a copy of the unsuccessful manifest (failed_merge_manifest.xml) is added to the directory.
Merged Behavior
The table below lists the areas of a configuration and gives an explanation of their behavior during a merge.
| Area | Merged | Behavior |
|---|---|---|
| Nodes | Yes | The merged configuration contains all the nodes from each of the component configurations. If two nodes which affect the same application exist in the same trigger, they will run in parallel. The contents of individual nodes are not merged. |
| Action and Conditions | Yes | Actions and conditions are not analyzed - the merged configuration will contain all actions and conditions from the merged configuration. If two configurations both contain actions which affect the same registry key for example, the merged configuration will contain both actions. For such conflicts, last write wins. This is standard conflict behavior in Environment Manager. |
| Auditing | No | The events from the base are used in the merged configuration whilst the events from the component configurations are ignored. |
| Custom Settings | No | Merged configurations inherit their Custom Settings from the base configuration. Settings from any component configuration in the merge are discarded. It is therefore important that the Custom Settings you require in the merged configuration are added to the base configuration. This includes the BaseConfigMergeBehavior Custom Setting. See Live Configuration Update Behavior. |
| Run As Library | Yes | Entries in the Run As libraries for all configurations are added to the merged configuration to create a single list. All friendly names must be unique. If two configurations in the merge contain a user with the same friendly name, the merge will fail. |
| Block Message Library | Yes | The Block Message libraries from all configurations are merged. The merged configuration contains all messages from the base and merged configurations including any duplicates. |
| Pre-triggers | Yes | When configurations are merged the pre-trigger actions from all configurations are added to the merged configuration. There is no validation for pre-triggers enabling duplicate and conflicting actions to be merged. |
| Personalization Settings | No | Personalization settings, such as the server list, are not merged. The merged configuration takes these settings from the base configuration. Therefore any Personalization settings required in the merged configuration should be defined in the base configuration. |