Best Practices for Configuration

This section outlines the key points for consideration when setting up your Environment Manager configuration.

In this section:

Mandatory vs Local Profiles

During design and implementation stages, consideration should be given to the type of profile which needs to be used as the base to be loaded for the user before Environment Manager Personalization overlays the user’s actual settings.

Typically, Mandatory profiles are used which are very light weight and contribute to faster logon times for users. This profile is ideal for environments where all users are accessing devices which are permanently online.

If users also use laptops to work offline, then you need to look at how their account is managed when the laptop is offline; do they:

  • Use an Active Directory account?

  • Use a Local Profile and provide Active Directory credentials when accessing company resources?

In these instances, it may be easier to leave the user profile path within Active Directory blank and allow users to load a local profile as a base. The cached copy of the local profile must be deleted using the Microsoft utility, DELPROF.

Another solution is to create the MAN file for the Mandatory profile, placed within the location of %SYSTEMDRIVE%\Default User.

This allows two benefits:

  • You do not have to specify a path within the User properties of Active Directory

  • As it is a Mandatory profile, the Windows operating system will flush this automatically.

This will require some time to copy to each managed device.

Applications that use INI Files

Some applications that are used within an environment require the use of INI files or files of this type to keep certain settings for the user.

If the INI file is kept within the user’s profile this is typically not a problem for Environment Manager Personalization.

When the INI file is not kept within the user’s profile, but in another location, for example, C:\Windows, then you may not want Environment Manager Personalization to capture information from this location, due to the nature and the amount of files in that location.

At this point, you can use Environment Manager Policy actions to copy down the file or folder to the location during either a Logon or a Process Start trigger for the application and then copy the file or folder back up to the user’s home directory during a Logoff or Process Stop trigger.

Personalization Membership Performance

Each condition evaluates matches and queries at different speeds providing different response times. These differences could be due to some conditions evaluating against local data and therefore providing rapid response times. Other conditions may require connection to the network thereby increasing response times and relying on connection speeds.

The conditions in the tables below have been rated by performance speed for carrying out matches and queries. By creating configurations with these response times in mind, performance can be optimized. For example, if a configuration contains OR conditions, place them in order of response time with the quickest evaluating first. If the first condition matches, the configuration is not held up by the slower response time of the second condition.

Directory Services Expressions

Condition Match Query
Site Membership Fast N/A
Computer OU Membership Slow Slow
User OU Membership Slow Slow

User Expressions

Condition Match Query
Is Administrator Fast N/A
User Name Fast Fast
User Group Name Fast Medium

Computer Expressions

Condition Match Query
Computer IP Address Fast Fast
Computer Domain Membership Fast Fast
Computer NETBios Name Fast Fast
Computer Group Fast Medium
Computer Name Slow Slow

Enabling Reverse DNS Lookup on the server increases the performance of the Computer Name condition.

Printer Settings for Personalization

If printer settings are required to be kept by the user, then the following keys need to be added to Windows Settings within the Personalization Server:


HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Devices

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

Masquerading Applications

To enable managed applications to share user Personalization settings, it is necessary to create an application group. For example, this could be a Microsoft Office group containing Word, Excel, Outlook and PowerPoint.

It may, however, be useful to use a Masquerading Application to allow an application access to another application’s personalization data without having to create an application group. For example, running mlcfg32.cpl against Outlook’s personalization data to view its registry settings on the client.

To do this, create an entry in the Advanced Settings dialog:

  • Name: MasqueradingApps

  • Value: rundll32.exe;office12\mlcfg32.cpl;outlook.exe;

This value equates to:

<RealExe>;<RealExe Commandline>;<TargetExe>;<TargetExeVersion>:

For this example, mlcfg32.cpl is grouped with Outlook to share its personalization data.

<TargetExeVersion> matches the version configured in the database for Outlook. If it is set to a wildcard (.*), any version can be supplied here.
These entries can be chained together to provide multiple settings.

Client Specific Masquerading

The MasqueradingApps setting is global and as such, applies on all managed end-point devices. However, to achieve the same behavior, applications can be launched on individual client machines with a special command-line argument: /APPSENSESPECIAL.

The syntax on the client is:

<RealExe> /appsensespecial:<TargetExe>:<TargetExeVersion>

Some applications such as regedit.exe, do not work correctly with extra command-line arguments. These applications should be launched using a command shell which has been run with the APPSENSESPECIAL switch.

For example, cmd.exe /appsensespecial:notepad.exe: would launch with the command shell sharing the personalization settings of Notepad. Regedit.exe can now be launched from within the command shell and will have access to Notepad’s settings.

In the above scenario, ensure that regedit.exe is not already defined as a managed application or blacklisted.
There should be no other instances of cmd.exe or regedit.exe running.

Create Personalization Caches Based on Environment Variables

The Advanced setting, MasqueradeAppByEnvVar allows the Personalization cache used by Environment Manager to be changed based on the existence of an environment variable on the end point.

This allows greater flexibility where Personalization is required for the same version of an application, across multiple machines where one instance of the application is using different plug-ins.

For example, if Microsoft Excel 2007 is run on three Windows 7 devices, by design it would share Personalization settings between all three. If one of those devices was running different plug-ins to the others, it could be useful for this version of Excel to use separate Personalization settings.

Configure Personalization Caches Based on Environment Variables

The following steps show how to configure the user interface using the Excel scenario.

  1. Create the following entry in the Advanced Settings dialog:

    • Name: MasqueradeAppByEnvVar
    • Value: TargetExe>%ENV_VAR%

    For the Excel scenario, the value would be Excel.exe>%MASQ%.

    MASQ is an environment variable set on the client.

  2. Create the following managed applications:

    Name Executable OS RegEx Version RegEx
    Excel Excel.exe .* .*
    Excel MASQ Excel.exe.masq .* .*

The Excel.exe.masq executable entry provides an alternative to excel.exe using a different cache to allow separate Personalization to be used for the same application.

Client Configuration

Add the environment variable called MASQ with a value of masq.

When Excel is run, its Personalization settings go into a cache called Excel MASQ.

If the MASQ variable is removed, Excel settings will go into a cache called Excel.