Ivanti Environment Manager is one of the most powerful solutions available for managing user profiles. With a powerful solution such as this there are always complications and nuances. I have discovered some unexpected behaviors in Ivanti Environment Manager. Knowing what to expect when importing Windows Setting Groups with registry exclusions and when using the file/folder import process can save you a great deal of heartache.

Background

Environment Manager Personalization captures user settings in the form of registry and folder items and stores them in a central database so that they can be made available whenever and wherever a user needs them. Personalization stores these settings in either an Application Group or a Windows Settings Group.

Application Groups are intended for personalizing settings that are tied to a specific application. When the application in question is started, Personalization injects the applicable file and registry items from the virtual cache that it creates on each import. These file and registry items are never imported into the actual registry or filesystem on the endpoint, they’re only visible to the application for which they are personalized.

In contrast, Windows Settings Groups import registry and file items from the database at logon and can be configured to synchronize with the database at logoff, session lock, and session disconnect. The intended use for Windows Settings Group is to store items that need to be accessed by the entire profile, although theoretically you could store items related to a specific application as well, should the need arise. As with anything in Personalization, you can create inclusions and exclusions within the settings but there’s a particular nuance with exclusions that I’m going to discuss today.

Registry Exclusions

Registry exclusions are useful if you want to prevent Personalization from capturing a specific application setting. This can be useful if there’s a setting that shouldn’t roam from one endpoint to another, or if the setting should be configured programmatically (such as with Environment Manager Policy) rather than being left up to user preference.

The pitfall of excluding registry items in Windows Settings Groups is this: when a registry key is imported into the registry as part of a Windows Settings Group, Personalization deletes the existing key prior to importing the key from the Personalization Database. Personalization does not merge the contents of the Personalization Database with anything that may already be present in the local endpoint’s registry. This can lead to serious problems if the end goal is to prevent a setting from roaming from one endpoint to another as this will lead to missing settings and may impact application functionality.

File/Folder Exclusions

Conversely, the file/folder import process merges the contents of the local folder in question with the contents of the Personalization Database. So theoretically you could exclude certain files such as application config files without causing any problems for the application. As long as the file exists on the endpoint, Personalization will not take any action to delete it.

Real-World Example

So, say you wanted a user to choose whether or not to enable Outlook Cached Exchange Mode (CEM) on a per-endpoint basis. In other words, if a user is assigned multiple workstations then the desired functionality is for them to be able to enable CEM on one computer and have it remain disabled on another (these would, of course, be physical workstations because you’d never want CEM enabled in VDI).

CEM settings are stored in the user’s Outlook profile. Specifically, in Outlook 2016, they’re stored in the following registry value:

HKEY_CURRENT_USER\Software\Office\16.0\outlook\Profiles\<profile name>\<guid>\00036601

To prevent this setting from roaming you can add an exclusion to your Outlook Profile Windows Setting that looks like this:

One would think that this would simply preserve whatever value for CEM was already on the endpoint. Because of the functionality explained above, this is not the case. When the Outlook Profile is imported at logon it will delete any existing 00036601 value, causing the Outlook profile to be corrupted and preventing the user from even configuring CEM until the value is created manually.

Conclusion

Hopefully this article will serve as a warning for some and as a reminder for others. Extreme caution is needed when making any changes to the Personalization configuration, especially when working with exclusions in Windows Setting Registry Items as this can lead to missing settings and possibly impact application functionality.