Friday, 11 December 2015

AppSense Environment Manager Policy Best Practices

This post contains best practice guidance for implementing Environment Manager. More specifically, the policy component of Environment Manager. It is not intended to be definitive guidance and is open to interpretation. This guide should be used as intended... as a guideline for building and maintaining Environment Manager.

This post will contain the following sections:
  • General Guidance - providing some high level guidance
  • Logon Trigger - basic guidelines around using the new logon triggers introduced in EM 8.5
  • Conditions - Guidance around various built in conditions
  • Actions - Guidance around various built in actions
  • Conclusion

General Guidelines

As with all AppSense Products, the most planning that goes into deployment the quicker and more successful the deployment will be. There is no point cutting corners because it will only come back and bite you at some point in the future. The old 6P's saying definitely applies to Environment Manager. 

Whilst not essential, it is recommended that you develop a framework for your configuration which includes a simple, yet effective, naming convention for your conditions, nodes, etc. This will not only simplify implementation it will also make managing and maintaining the environment a lot quicker and easier. Remember... you most likely won't be the person supporting the environment which makes this even more important. A good configuration is one that someone with very little AppSense Environment Manager could read and quickly determine what it is doing and what it is intended to do. 

Take care to avoid any race conditions within your configuration as these account for almost all odd behaviour where sometimes something works and sometimes it doesn't work. The screen shot below illustrates a simple example where a customer had introduced a race condition into the configuration by setting the ADMX Policy setting Prohibiting users from manually redirecting profile folders and attempting to redirect Profile Folders in a parallel node. In this example some folders would redirect yet others wouldn't. A better solution would have been to have created a sub-node underneath the Folder Redirection node for the ADMX Policy setting.  

Always create and use environment variables (or session variables) to identify file servers to minimise the number of actions required. Imagine a scenario where you have 20 or 30 drive mapping actions each mapping to \\FILESERVER1\SHARE and you decide to change \\FILESERVER1 to \\FILESERVER2 or a DFS root. It means changing 20 or 30 actions or using the Find and Replace tool and then manually validating 20 or 30 actions. Using an environment variable you could easily just create a single variable and then reference that for each of your actions. 

Logon Triggers

Environment Manager 8.5 introduced new logon triggers, namely:
  • Pre-Session
  • Pre-Desktop
  • Desktop Created
When building your policy configuration it is important to remember that Personalization starts immediately after the Pre-Session trigger allowing Administrators to define Personalization related settings (e.g. Personalization Server ADMX setting) within the Pre-Session trigger.

The following actions are typically recommended for each trigger:

Pre-Session - Environment Variables, Personalization Server Settings, DataNow Settings and also DPI settings if these need to be set using policy.

Pre-Desktop - Folder Redirection, Session related ADM/ADMX settings (e.g. Control Panel applets, Shell Settings, etc), Session related file and folder actions and Session related registry actions. 

Desktop Created - Network Drive Mapping, Network Printer Mapping, Longer running actions (e.g. App-V publishing scripts, etc) and Core application policy settings (e.g. Microsoft Office, Internet Explorer, etc)

Application Start - Non-Core application policy settings


As a general rule of thumb, any condition used two or more times within a configuration should be configured as a reusable condition. This will mean that the configuration can be evaluated once and the result re-used instead of being evaluated multiple times within a configuration. 

When configuring user group conditions its important to ensure that LSA Support is configured for each group condition. This effectively causes the user groups security identifier (SID) to be stored within the configuration and the SID then matched against the users locally stored token instead of querying active directory to determine membership of the group. This also allows user group membership to be evaluated when the laptop is offline (e.g. Laptop and Tablet devices.) When migrating a configuration from an environment to another where the SID may be different the SID Refresh option must be used to ensure the SID within the configuration is current.

When building configurations the following conditions are referred to as expensive conditions and should be avoided wherever possible:
  • User Organizational Unit (OU)
  • Computer Group
  • Computer Organizational Unit
Stop Subnodes on Fail (Stop If Fails) should be used with care. As the name suggests, this option will stop any subnodes from running if the condition fails. This is especially important to remember when configuring If Else groups because Stop Subnodes on Fail will be enabled for each condition within the If Else Group. I personally only use Stop Subnodes on fail on my top level conditions as seen in the screen shot below where Stop Subnodes on Fail is only enabled on the PD_1_AppSense Enabled node:


Wherever possible, separate ADM / ADMX actions into individual actions. Whilst this doesn't offer any real performance gain over grouping all actions into a single action it does make reading the configuration easier and also makes supporting and troubleshooting the environment significantly easier. Administrators can also easily disable a single policy setting without having to search a long list of policy actions and then remove the setting. 

In addition to the above it is typically recommended to leave computer related ADMX settings within Microsoft Active Directory and use Environment Manager Policy to manage User related settings. The reason for this is because Active Directory will typically refresh its policy set regularly whereas Environment Manager requires a trigger to fire (e.g. Computer Startup) in order to refresh its settings. 

Folder redirection should always be done to an environment variable which in turn should reference a UNC path. Using drive letters (e.g. H:) is unsupported by Microsoft and is likely to result in application compatibility issues. AppData(Roaming) should NEVER be redirected and instead customers should adopt Environment Manager Personalization for managing application settings stored within AppData(Roaming).

Folder redirection has been known to cause performance issues where the file servers are not sized adequately. Always ensure the following is true for your file servers:
  • File servers have the fastest available network adapters
  • File servers are not oversubscribed
  • File servers have adequate CPU and Memory
Wherever possible implement data synchronization solutions (e.g. DataNow, OneDrive, etc) to avoid having to redirect Profile Folders to a network file server. 

When implementing File and Folder copy actions take care not to implement large copy actions on the Logon trigger. These will impact user logon and in turn provide the end user with a poor experience which is what you are trying to avoid by purchasing Environment Manager. As mentioned previously, use variables for your file servers to simplify the configuration and ensure any large or unnecessary files (e.g. tmp, log, pst, etc) are excluded from the file and folder copy actions unless required.

With regards to Network Drive and Printer mappings always ensure environment variables are used. Ensure these are mapped using the Desktop Created trigger and when managing these as well as personalizing them ensure the "unmap at logoff" option is selected. This will ensure the action is unmapped at logoff so only user mapped drives will be managed within Personalization Server.

When configuring registry actions there is no need to modify permissions to the HKLM hive to use Environment Manager. Environment Manager can write to HKLM keys irrespective of whether the action is performed on the User or Computer trigger points. Registry keys do not need to be pre-created as the action will create the full path if this does not exist. 

In addition, registry actions are often used to complement Personalization. Applications that write large amounts of registry data or are used by other applications can be "hived" using registry hiving actions. This also allows these keys to be roamed without the need to configure and implement Personalization Server (if required).

Finally Self-Healing is a process that ensures a file, registry value, process or service is in a known good state. This is done by taking a copy of the item when the trigger the action is configured on fires (e.g. Computer Startup) and polls this item every 5 seconds thereafter. In the event that the item differs from the original copy the original will be restored. Self Healing should be used with caution as this has been known to introduce performance issues where large folders, files, etc are self healed. If required this should be as granular as possible and should only include small items. E.g. Hosts file, Run key, etc. 


As with all best practice, it does not fit all scenarios. There are cases where customers will need to deviate from best practice. These should act merely be used as a guideline where, in a perfect world, all would be adopted. 

If you would like to discuss any of the items above or have any items to add to the list please get in touch with me and I will gladly add them to the list.