Appsense How to Implement User Profiles Using AppSense Environment Manager

How to implement User Profiles using AppSense Environment Manager

Free 21 day trial of the software available at www.appsense.com/evaluate.

About this Guide/Help

This guide presents a practical approach to profile management using AppSense Environment Manager in conjunction with Microsoft mandatory profiles.

AppSense takes no responsibility for changes made to corporate systems based on recommendations

made in this document

Profile Management

Consistent yet contextual user

environment

Key BenefitsQuick and easy profile creation and maintenance

Combines company policy (mandatory profile) and flexibility (contextual personalization)

Central storage of profile information reduces risk of corruption

Profile size reduced hence logon / off times reduced

Profile stability maximized

AppSense Environment Manager is a component of the AppSense Management Suite that provides consistent and contextual user environments across multiple application delivery mechanisms through management of user profiles. Whether users get their applications via desktop installation, publishing, virtual desktops, blade PC or streaming, AppSense Environment Manager ensures a consistent experience from a centralized management console.

Contents

Introduction 4

Profile Management Process 5

1. Create a mandatory profile 5

(A) - Prepare the profile 6

(B) - Copy the profile to a shared folder 6

(C) - Strip out user specific settings 7

(D) - Assign the mandatory profile to users 7

- Redirect Folders 8

- File & folder manipulation 11

4 - Registry key manipulation 11

Registry Hiving 12

Registry Key and Value setting 15

Profile State Emulation 17

Migrating settings from a Roaming Profile to use the Environment Manager solution 17

Conclusion 19


4

Introduction

On computers running Microsoft Windows Operating Systems, user profiles automatically create and

maintain the desktop settings for each users work environment on the local computer.

Administrators can elect to make use of the local user profile that is created the first time a user logs on

to a computer and is stored on the computers local hard disk. Any changes made to the local user profile

are specific to the computer on which the changes were made and the changes are not reflected on any

other computer that user logs on to.

This personalization can be extended to the wider enterprise by making use of a roaming profile where

the profile is stored centrally on a file server, and copied to the workstation at logon and then back out to

the file server at logoff. The advantage of this is that user settings follow the user to any computer they

have the ability to log on to and hence, the user always has a consistent desktop.

However, roaming profiles can easily grow in size to be 100s of MBs in size, which in itself presents

several issues to the enterprise including huge performance degradation and heavy network utilization.

If an organization delivers application content via a Terminal Server environment then these issues can

be compounded further due to differing servers delivering different types of applications. This can cause

simultaneous attempts to write profile settings out to the file server leading to potential contention in file

overwriting, with a worst case scenario being roaming profiles becoming corrupt.

Another type of profile available for administrators to deploy is a mandatory profile. A mandatory profile

is a profile that is configured so that the user cannot save any changes made to the settings contained in

the profile at logoff in essence, a read-only roaming profile.

Mandatory profiles are fast to load, easy to manage and cannot be corrupted. However, the major

disadvantage is that no personal user settings are retained at logoff and hence user specific changes to

their desktop environment are not preserved between sessions.

Folder redirection can be used to help resolve the personalization issues when using mandatory profiles,

but default Windows methods are limited and do not offer support for personalized registry settings to

be redirected or saved.

This document offers an example of how AppSense Environment Manager can be used to manage

profiles effectively within a Microsoft Windows Server 2003 Terminal Services environment.

In this example we will assume the organization has configured a Windows Server 2003 Active Directory domain.

5Profile Management Process

There are four recommended steps required in order to provide a comprehensive profile management

solution to users using AppSense Environment Manager.

Two optional steps include:

Profile state emulation to offer support for certificates when using mandatory profiles

Migrating roaming profile settings to use the AppSense Environment Manager solution

1. Create a mandatory profile

It is recommended that AppSense Environment Manager be used in conjunction with a mandatory

profile. You will first need to create a mandatory profile that can be used by users logging on to the

Terminal Server environment.

Note: There are a number ways in which a mandatory profile can be created including:

Using a new user account on a server with no applications installed or policies applied.

This is to ensure the mandatory profile does not contain any user specific settings and remains as

small as possible.

Using the Default User profile

This ensures a minimum profile size of 204KB. If you choose to go for a mandatory profile based on

the Default User Profile, be sure to remove any active setup settings. If this is not done, then each

time a users logs on, the operating system will start configuring personalized settings such as those in

Outlook Express and Internet Explorer.

1)

2)


The active setup settings are located in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ActiveSetup\InstalledComponents

and

HKEY_CURRENT_USER\Software\Microsoft\ActiveSetup\InstalledComponents

For further information, please see http://support.microsoft.com/kb/238441.

On a server that has all the applications installed

To ensure that the mandatory profile contains as many application settings as possible, although this

will increase the size of the profile and could increase network utilization and user logon speeds.

In this example we shall use method (1).

(A) - Prepare the profile

On a domain controller, create a new user account that has the same permissions as the user or

group for which you want to create a mandatory profile.

Log on to the Terminal Server using the template user account you just created.

A user profile is created on the Terminal Server under the %SystemDrive%\Document and Settings\

folder.

Configure the desktop settings required in the profile including shortcuts, appearance settings and

Start menu options.

Delete all folders and files that are not required.

Once you are happy with the profile, log the template user off the computer.

(B) - Copy the profile to a shared folder

Create a shared folder on the network in which you want to store the new, mandatory profile, for

example \\\

Assign Change permissions to the shared folder.

Assign Read & Execute permissions to this folder for users and groups who will utilise the

mandatory profile

Log on to the domain as an administrative user from the Terminal Server.

Access the System Properties applet and on the Advanced tab, click Settings.

Under Profiles stored on this computer, select the profile created in (A) and click Copy To.

In the Copy profile to field, enter the UNC path to the share created in (A) (for example

\\\\) and click OK.

3)

7Under Permitted to use, click Change and add Authenticated Users and click OK.

On the Terminal Server, navigate to the shared folder that contains the profile that has been

copied.

Rename the file Ntuser.dat to Ntuser.man.

Finally, ensure the ownership of all the files and folders in the folder belongs

to the Administrators group and not the Administrator user. Failure to do this can result in permissions

problems when users attempt to access the mandatory profile at logon.

(C) - Strip out user specific settings

Make a back up copy of Ntuser.man

Open the registry editor.

Navigate to the root key of the HKEY_Users hive.

Choose Load Hive from the File menu.

Select the Ntuser.man file created earlier in (B).

Enter a name, for example Mandatory.

Select the Mandatory tree and expand it.

It is now possible to edit the registry and remove any user specific settings from the mandatory

profile without having to login with that profile. This can be achieved by searching for known

usernames or SIDs.

It is also possible to review and set permissions on specific registry keys.

Once finished, unload Ntuser.man from the registry by selecting the Mandatory tree and choosing

Unload Hive from the File menu.

(D) - Assign the mandatory profile to users

As the administrative user, launch Active Directory Users and Computers from the Start | Programs |

Administrative Tools menu.

Locate the organizational unit that contains the user account whose setting you want to modify,

In the right-hand pane, right-click the user account and click Properties.

Select the Profile tab.

In the Profile path field enter the location of the mandatory profile you wish to assign, for example

\\\ where is the name of the computer where the profile is

stored and is the shared folder that contains the mandatory profile.


8

Click OK.

Log on to the Terminal Server using the account to which you have assigned the mandatory profile

and ensure the mandatory profile has been applied correctly.

Note: We have just set up the user account to access the mandatory profile from a network share. As the

user will be accessing the file from a remote location, this may slow down the user logon process and

increase network utilization.

To resolve these issues, it is recommended you copy the Ntuser.man file from the network share and

store it locally on each Terminal Server on which users will be logging on to.

This can be done manually, using a 3rd party deployment mechanism such as SMS or by using an

AppSense Environment Manager Computer | Startup file copy action. Using Environment Manager to

achieve this results in a single point of control for maintenance of the profile.

The Profile Path within Active Directory Users and Computers can then be changed to point to the local

copy of Ntuser.man.

As a final note, you will need to ensure that any version control mechanism (for the profile) is fully aware

of the local copy of the profile such that where any changes to the mandatory profile are made centrally,

the deployment mechanism of choice is made aware of the changes to ensure that the updated profile is

propagated down to the client machines appropriately.

Note: It is also recommended that the following Group Policy setting be enabled to delete users

cached profiles at logoff:

This will ensure that each loaded user profile, for example C:\Document and Settings\User is removed at

logoff, cleaning up your computer(s).

2 - Redirect Folders

A primary consideration with profile management is the physical size of a users profile. Commonly

used directories such as My Documents and Application Data can grow dramatically over time as more

documents are created and more applications are installed on the Terminal Server. This is one of the main

reasons why mandatory profiles are preferred over roaming profiles as the time it takes to transfer and

9load a mandatory profile, rather than roaming profile, is significantly shorter.

However, as a mandatory profile does not save any new data that has been made during the session

when the user logs off, documents and application settings are lost if they are not catered for in some

other way.

Folder redirection allows the users personal files and settings to be saved to another location, most

commonly to the users home drive, which is outside of the profile itself. This means that personal files

are retained at logoff and as these are no longer part of the profile, loading times during the logon

process are significantly improved.

Folders can be redirected to any available location including a local folder, a network drive, a user home

drive or to a Terminal Server profile path location.

In this example, we are going to redirect folders to the users home drive so that user specific files

and application data can be backed up each evening by the managed backup solution in place in the

organization. Another benefit is that by redirecting the Desktop folder to the user home drive, this can

be included in the quota policy, where applicable, which prevents the user from having too many large

documents on the desktop.

We are going to assume that the home drive has previously been set up by the administrator within the

Active Directory User and Computers console, although it is possible to configure this using Environment

Manager.

Redirecting folders to the user home drive

Navigate to the User | Logon node.

Select the Add a new sub node option.

Select the (New sub node) node that has been created and rename to Redirect Folders.

In the Rule and Actions pane click the New button.

Select Folder Redirection and click the OK button.

Select the folder you wish to redirect in the drop down Folder list

Use the drop down Target list to select the location where you wish to redirect the folder, browse

to the folder location you wish to use or manually enter the folder path.

Click OK to complete the Folder Redirection action.

You will need to repeat this process for each folder you wish to redirect.


10

In this example, we will configure the following folder redirection settings:

Where H: is the user home drive.

As the redirected folders will be visible to the user within their home directory, it is recommended that

the redirected folders that are system or application specific, for example AppData, be hidden from the

user.

If the redirected folders are located on the computer on which the AppSense Environment Manager

agent is running, then this can be achieved using the Set Attribute option from within the File Action

wizard.

However, if the redirected folders are located on a remote network share, then this will have to be done

manually by the administrator.

Note: Redirecting the Application Data folder to a network share may cause fileserver performance

issues. This is because certain applications may require the ability to regularly read from and write to

the Application Data folder.

As an alternative, the Application Data folder can be copied out to a network share at user logoff

(using AppSense Environment Manager file copy actions) and then copied back in at user logon.

However, depending on the network speed, this may have the knock-on effect of increasing the user

logon time, so the administrator must make an important decision with respect to how they control

the Application Data folder.

11

3 - File & folder manipulation

Once folder redirection has been configured, the need to manipulate specific files and folders is reduced

dramatically. However, it is still possible to control the contents of both the redirected folders and the

folders remaining within the profile directory.

For example, the administrator may want to delete a specific user file if it grows larger than a certain size

or alternatively create a new folder in the users profile area to hold specific data.

This can be achieved by utilizing the Environment Manager File Action and Folder Action.

File Actions include the ability to move, copy, delete, rename or modify the attributes of a file.

Folder Actions include the ability to create, copy or delete a folder.

For further details on File Actions and Folder Actions, please see the AppSense Environment Manager

Getting Started Guide or the Environment Manager online help files.

4 - Registry key manipulation

The Windows registry is divided into five separate keys:

HKEY_CLASSES_ROOT

Contains information relating to file associations and for object linking and embedding.

HKEY_CURRENT_USER

Contains the profile settings for the current user.

HKEY_LOCAL_MACHINE

Contains configuration settings for the computer itself

HKEY_USERS

Contains all the actively loaded user profiles on the computer.

HKEY_CURRENT_CONFIG

Contains settings related to installed software and device drivers

Whenever a user makes any changes to their personal settings, that information is stored in the HKEY_

CURRENT_USER (HKCU) hive area of the registry. Therefore, if we use AppSense Environment Manager

to save out those registry settings when the user logs off and re-import them the next time the user logs

on, we are allowing that users personal settings to roam with them, even if they are using a mandatory

profile.

This is achieved using the Hive Registry Action within AppSense Environment Manager.


1

Registry Hiving

As an administrative user, navigate to the User | Logoff node within the Environment Manager

console.


Select the (New sub node) node that has been created and rename to Export Registry Settings.


Select Hive Registry and click the OK button.

Enter a Title, for example, User Profile Settings.

Browse to the Location where the settings will be saved, preferably on a network share so that

settings can be accessed from multiple computers, for example \\\. It is

not necessary to create separate folders for each user as Environment Manager will separate the user

information being saved using the following format:

__

Select the Export the hive from the registry to file radio button.

Click the Browse button.

Use the Registry Browser window to select which areas of the HKCU registry you wish to hive out.

This can be from the local computer registry or a registry on another machine.

Click OK.

Repeat the Browse process for each registry key you would like to hive out.

Click OK when you have completed the required settings

1

You should now see a Save User Profile Settings Hive Registry action within the Actions list of the Rule

and Actions pane:

In this example we will hive out the following registry settings:

You may want to hive out further personalized settings from applications such as Microsoft Office, Adobe

Acrobat or the SAP Client to name but a few. This can be done by editing the same Registry Hive action

created earlier and adding them to this single action or by creating separate Registry Hive actions for each

individual application.


14

One you have completed the Registry Hive actions that will apply at logoff, you will now need to configure

Environment Manager to import these registry settings when the user next logs on.

Navigate to the User | Logon node within the Environment Manager console.


Select the (New sub node) node that has been created and rename to Import Registry Settings.

Navigate back to the User | Logoff | Export Registry Settings created earlier.

Right click on the Hive Registry action displayed under the Actions list and select Copy.

Navigate back to the User | Logon | Import Registry Settings node.

Right click in the Actions list with the Rule and Actions pane and select Paste.

Double click the Hive Registry action that has just been copied.

Select the Import the hive from file to the registry radio button and click OK.

You should now see a Load User Profile Settings Hive Registry action within the Actions list of the Rule and

Actions pane:

Applying Rules to cope with server silo environments

Sometimes it is necessary for administrators to create dedicated application servers (or server silos) that have

specific applications installed for specific tasks. This could be because of application compatibility issues, to

simplify application upgrades and to reduce server maintenance downtime.

In this scenario, it is possible to assign specific rules in AppSense Environment Manager when saving out and

restoring registry settings so that users who are logged on to multiple servers in a farm do not experience

profile contention when the user logs off and the profile settings are saved.

15

For example, Server A is installed with a specific application, App X, but also has Microsoft Office installed

because App X relies on it.

Server B only has Microsoft Office installed as this is the main application server where the majority of

users will be accessing Microsoft Office from.

If a user logs off from Server B their Microsoft Office settings are saved out.

If the same user then logs off from Server A, both their App X and Microsoft Office settings are saved

out, but their original Microsoft Office settings from Server B are overwritten.

To alleviate this it is possible to assign a rule within AppSense Environment Manager based on the

published application name, or published desktop name.

This will ensure that if the user logs on to Server A, then Server As settings are restored. If the user logs

on to Server B then Server Bs settings are restored instead.

Registry Key and Value setting

Once registry hiving has been configured, the need to manipulate specific registry settings is reduced

dramatically. However, it is still possible to control the contents of both existing and restored registry keys

and values.

For example, the administrator may want to ensure that an Internet Explorer toolbar is always shown

when the application starts up or that a specific process, such as Adobe Update Manager is always run

when the user logs on.

Note: When utilizing registry actions and registry hiving, it is recommended that the registry actions

wait until the registry hiving has taken place. This can be achieved by making a subnode containing

the registry actions dependent on a subnode containing the hive registry actions. Alternatively, both


1

the registry actions and hive registry actions can be located within the same node and the Execute in

Sequence option can be used to ensure order of execution.

This can be achieved by utilizing the Environment Manager Registry Action Wizard.

Registry Actions include the ability to create or delete registry keys and set, create, delete or set a default

value for registry keys.

For further details on the Registry Action Wizard, please see the AppSense Environment Manager Getting

Started Guide or the Environment Manager online help files.

Windows Appearance Settings

Certain Windows Appearance Settings for the user may not applied as expected when registry actions

and hive registry actions are utilized. This is due to the way the Windows Operating System functions.

Certain registry keys are only loaded at computer startup, which therefore requires a reboot for them to

take effect especially those involving the control panel settings.

The following list details those registry keys that may not be applied as expected when a user logs on:

AppSense has available a utility that refreshes the settings stored beneath the HKCU\Control Panel

registry keys, RefreshTool.exe.

This utility can be used by configuring an Execute Action, during the user logon process.

Navigate to the User | Logon node within the Environment Manager console.

Select the subnode in which you wish to add the Execute Action, in this example the Import

Registry Settings node.


17

Select Execute and click the OK button.

Enter the Filename path to where the RefreshTool.exe file exists

Note: The RefreshTool.exe file must be located in a folder that all users have access to execute

from.

Click OK.

Finally, select the Execute In Sequence option under the Options section of the Rule and Actions

pane. This will ensure the Hive Registry action applies first before the Execute action is processed.

Profile State Emulation

When it comes to using mandatory profiles, a significant issue for some administrators is that digital

certificates cannot be stored within the profile.

An unsupported workaround is to emulate a roaming profile during the logon process and revert back

to a mandatory profile at logoff. This will allow the user to add certificates within their session.

Emulating the profile state can be achieved by changing the value in

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Profilelist\\State

to 133.

When this is applied the operating system believes that the profile in use is a roaming profile.

It is then possible to restore the users certificate key settings which can be found in the HKCU registry

key.

At user logoff these keys can be saved out again and then the profile state can be restored back to

mandatory (256) to avoid the operating system attempting to update the mandatory profile.

This can be achieved using an AppSense Environment Manager Custom Action utilizing VBscript

capabilities.

Migrating settings from a Roaming Profile to use the Environment Manager solution

Implementing the solution as described above is simple in a Greenfield scenario. However, within

organizations that currently have their user profiles created, it will be necessary to migrate parts of the

existing profile to the new profile solution so that users do not lose any of their current personalized

settings. This migration phase should be carried out before any of the processes outlined above.

A temporary migration scenario can be created whereby Environment Manager is configured to copy

existing profile folders from the current Roaming Profile to the location where you wish your folders to be

redirected to in our example from earlier, this will be the user home drive H:.


18

Also personalized registry settings can be saved out to a network share, using the Environment Manager

Hive Registry action. At this stage there is no need to configure Environment Manager to restore the

registry settings when the user logs on, since the users are still working with a roaming profile and their

personalized settings will be retained.

Users can now be slowly migrated, at the administrators desired pace, to the new profile solution without

losing the contents from the Favorites folder or their personal settings in Microsoft Word for example.

This transitional phase could last for a period of days or weeks prior to the migration, ensuring that all

users have saved their personalized settings at logoff.

In the example above, a rule has been assigned to the actions within the node, based on Active Directory

membership ensuring the administrator can switch all users to the new solution at the same time.

The export of registry settings at user logoff (as described earlier in the Registry Hiving section) can also

be configured at this stage:

Once this transitional phase has run for a few days or weeks, all the administrator has to do to complete

migration is to alter the group membership settings in Active Directory and configure the users to use the

Mandatory Profile and the Environment Manager configuration as described earlier in this document.

19

Conclusion

As can be seen there are many elements involved with managing user profiles, and only when they are all

brought together do they get close to representing a comprehensive profile management solution.

AppSense Environment Manager can be used to resolve roaming profile issues that are often

encountered within the enterprise. By using a mandatory profile, AppSense Environment Manager may

be optimally configured to save out different portions of the users profile at logoff, such as registry

settings and files, and restore them when the user next logs on. This has the added benefit of minimizing

network bandwidth consumption, saving and loading relevant areas of a users profile, rather than

transferring the whole profile across the network.

This solution therefore enables the stability and control offered by a mandatory profile, whilst allowing

the flexibility and personalization available with a roaming profile.

Furthermore, user profile corruption becomes a thing of the past since no longer is there file copy

contention during the logoff process, leaving IT support teams to spend their valuable time on other,

more pressing projects or initiatives.

Existing roaming profile implementations can be seamlessly migrated to use Environment Managers

profile management solution, which also offers the added benefit of being able to centrally manage

and maintain the lockdown of application and operating system content and self healing of critical files,

processes, services and registry keys.

By leveraging the power of the AppSense Management Center, administrators can also ensure that

enterprise-wide deployment of Environment Manager software and configurations is completely taken

care of, regardless of computer location.

The information contained in this document (the Material) is believed to be accurate at the time of printing, but no representation or warranty is given (express or implied) as to its accuracy, completeness or correctness. Neither AppSense nor the publisher accepts any liability whatsoever for any direct, indirect or consequential loss or damage arising in any way from any use of or reliance placed on this Material for any purpose.

2000-2007 APPSENSE LIMITED. ALL RIGHTS RESERVED

AppSense, Security from within, Management made easy and Performance for everyone are registered trademarks of AppSense Ltd. All other brands or product names are trademarks or registered trademarks of their respective companies.