User Profile Best Practices for MetaFrame Presentation Server

Citrix states in their article: CTX110351

Products: Citrix MetaFrame Presentation Server 3.0 for Microsoft Windows 2000, Citrix MetaFrame Presentation Server 3.0 for Microsoft Windows 2003, Citrix MetaFrame XP 1.0 for Microsoft Windows 2000, Citrix MetaFrame XP 1.0 for Microsoft Windows 2003, Citrix Presentation Server 4.0 for Microsoft Windows 2000, Citrix Presentation Server 4.0 for Microsoft Windows 2003

User Profile Best Practices for

MetaFrame Presentation Server

Citrix Systems, Inc.

Notice

The information in this publication is subject to change without notice.

THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. CITRIX SYSTEMS, INC. (“CITRIX”), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE.

This publication contains information protected by copyright. Except for internal distribution, no part of this publication may be photocopied or reproduced in any form without prior written consent from Citrix.

The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products. Citrix does not warrant products other than its own.

Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.

Copyright © 2003 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009 U.S.A. All rights reserved.

Version History

1.0
Bill Carovano, Citrix Consulting
May 13, 2004

Table of Contents

INTRODUCTION 1

USER PROFILE BACKGROUND 2

Windows User Profiles Defined 2

Additional User Profile Options 2

ANALYZING DESIGN REQUIREMENTS 4

Comparing Profile Options 6

Using Profile Policies 6

Specifying Multiple Profiles 8

FREQUENTLY ASKED QUESTIONS 10

Introduction

An effective design of user profiles can make a significant difference in the performance and manageability of a MetaFrame Presentation Server environment. Many of the issues commonly seen in large or complex MetaFrame Presentation Server environments—including slow logon, loss of user settings, profile corruption, and excessive administration effort--are often the result of sub-optimal user profile designs. A solid design and implementation of user profiles can maintain the integrity of user settings, eliminate issues requiring administrator intervention, and ensure high-performance user logon.

This white paper will present Citrix’s best practices for the design of user profiles in a MetaFrame Presentation Server environment.

User Profile Background

Windows User Profiles Defined

Before discussing the Citrix best practices for user profiles, it is useful to provide background information on the profile types available within Windows Terminal Services environments, and how they apply to MetaFrame Presentation Server.

Microsoft provides several types of profiles that can be used in Windows Terminal Services:

• Local Profiles

• Mandatory Profiles

• Roaming Profiles

Within a MetaFrame Presentation Server environment, these three profile types can be defined as follows:

Local Profiles are stored on each MetaFrame Presentation Server, and are initially created based on the default user profile. Therefore, a user accessing applications in a load-managed MetaFrame Presentation Server farm would create an independent profile on each server. Users are able to retain changes to their local profile on each individual server, but changes will only be accessible for future sessions on that server. Local profiles require no configuration; if a user logging into a MetaFrame Presentation Server does not have a profile path specified, a local profile will be used.

Roaming Profiles are stored in a central location for each user. Roaming profiles differ from local profiles in that the information in the profile (whether it be a printer, a registry setting, or a file stored in “My Documents”) can be made available to all MetaFrame Presentation Servers in the environment. Configuring a user for a roaming profile requires an administrator to specify the user’s Terminal Server Profile Path to a particular location on a file server. The first time the user logs into a MetaFrame Presentation Server, the default user profile will be used to create the user’s roaming profile. During logoff, the profile will be copied to the administrator-specified location.

Mandatory Profiles, sometimes called “roaming mandatory profiles,” are also stored in a central location for each user. They differ from roaming profiles in that the user’s changes are not retained on logoff. Configuring a user for a mandatory profile requires an administrator to create a mandatory profile file (NTUSER.MAN) from an existing roaming or local profile, and assign users’ Terminal Services profile path to the location where the file can be accessed.

Additional User Profile Options

In addition to these basic profile types provided by Microsoft, there are two other profile options that can be applied in a MetaFrame Presentation Server environment. These include:

• Multiple Profiles

• Hybrid Profiles

Multiple Profiles combine two or more of the three basic profile types (local, roaming, or mandatory) for the same user. Multiple profiles are useful in environments with load-managed groups or “application silos.” For example, in a MetaFrame Presentation Server farm with two load-managed groups serving SAP and Microsoft Office, users can be configured to use a mandatory profile for the SAP servers and a roaming profile for the Microsoft Office servers. Multiple profiles are also useful for farms that span WAN connections, so that profiles can be accessed from local file servers instead of having to traverse the WAN. Multiple profiles can be implemented in a number of different ways, and the details of these options will be discussed later in this white paper.

Hybrid Profiles are a cross between mandatory and roaming profiles. Users receive the benefits of a roaming profile, and administrators can control the specific settings that can be saved. Hybrid profiles combine a mandatory profile with custom logon/logoff logic to store and retain specific information. Depending on the needs of particular applications, the logon/logoff logic can be tailored to specific requirements. For the example mentioned above where SAP and Microsoft Office are deployed in separate load-managed groups, the hybrid
profile can be configured to store only specific registry settings for Microsoft Office, but not for any other application (such as SAP). The proper implementation and support of hybrid profiles can be challenging. As such, they are provided exclusively to Citrix customers through the services and tools of Citrix Consulting.

Analyzing Design Requirements

Now that the available profile types have been defined, it must be determined which one is right for use in a particular MetaFrame Presentation Server environment. To make the determination of the appropriate profile type, the requirements of a particular environment need to be carefully analyzed. Questions that need to be answered to define these requirements include:

• Do users need to save their settings?

• Do applications store settings in the registry?

• How will printers be made available, and how will printer settings be handled?

• What is the farm design? Are applications in Load Managed Groups or “silos?”

Now we’ll consider each of these questions, to help determine an effective user profile design.

1. Do users need to save their settings?

User requirements and expectations play a large part in which user profile type to use. If users run applications such as Microsoft Office where particular settings will need to be saved, then a mandatory profile will not be an appropriate solution. If users do not have this requirement, using a mandatory profile solution can ease administration.

2. Do applications store settings in the registry?

If the application(s) being deployed do not reference the HKEY_CURRENT_USER (HKCU) hive in the registry (such as SAP or Siebel), then a mandatory profile solution can be considered. Roaming, hybrid, or multiple profile solutions will allow users to save settings in environments where some or all of the applications require settings to be saved.

3. How will printers be made available, and how will printer settings be handled?

The printing requirements and design have an impact on the user profile design. If auto-created client printing functionality is used and the client-side settings are to be applied to MetaFrame Presentation Server sessions, then mandatory profiles can be used. However, if network printing (when print jobs are spooled directly to a print server without passing through the Presentation Server client) will be used and user settings need to be saved, use of roaming profiles may be required. When configuring printing, the “Update Printer Properties at each Logon” setting in the Presentation Server Console for auto-created printers needs to be considered with the profile type selected. The following chart explains the net result of the design options:

Profile Type
“Update Printer Properties” setting
Resulting Settings

Mandatory
Enabled
Client-side printer driver settings

Mandatory
Disabled
Server-side default printer driver settings

Roaming
Enabled
Client-side printer driver settings

Roaming
Disabled
Server-side printer driver settings stored in the user profile

Note that the client settings inherited only include the public printer driver properties (also called the “public Devmode” settings). For more information on auto-created printer properties and how they apply to MetaFrame Presentation Server sessions, see Citrix knowledgebase article CTX959786. If users will need to be able to retain private printer driver properties, then roaming profiles are required; some printer drivers (such as certain driver versions from HP’s OfficeJet series) store useful settings such as “print quality” in the private printer driver properties.

4. What is the farm design? Are applications in Load Managed Groups or “silos?”

Citrix’s best practice is to logically group servers and applications within a farm into two or more load-managed groups (LMG’s). For example, if an environment will include SAP, Siebel, and Microsoft Office, it is beneficial to segregate these applications on separate servers. In farms employing LMG’s, roaming profile designs increase the likelihood of profile setting loss or profile corruption. For example, users accessing SAP and Microsoft Office at the same time may overwrite roaming profile settings made in the Office session if the user logs off from the Office session before the SAP session. This effect can therefore be termed the “last one wins” condition. For this reason, hybrid or multiple profile designs are considered a best practice for farms that employ LMG’s.

Design Practices

Once the analysis of requirements has been performed, the appropriate profile type(s) needs to be selected. Furthermore, details such as profile policies and the multiple profile configurations need to be specified.

Comparing Profile Options

The following table is useful for comparing the relative benefits of each profile type when analyzing the design requirements:

Profile Type
Benefits
Disadvantages

Local Profile
• Fast Logon

• No requirement for file server for profile storage

• Not susceptible to corruption
• Settings are not consistent across servers and sessions

• Consumes local disk space

Roaming Profile
• Settings are saved across sessions
• Slow login

• Susceptible to settings loss and corruption in load-managed group environments

Mandatory Profile
• Fast Logon

• Not susceptible to corruption
• Settings are not saved across sessions

Multiple Profiles
• Benefits of both mandatory and roaming profiles without the disadvantages of each
• Potential for additional file server space requirements

Hybrid Profile
• Fast Logon

• Allows for the most control over settings

• Not susceptible to corruption or settings loss

• File server space requirements are minimal
• Effort, cost, and skills to install and maintain

Using Profile Policies

Several group policies can be applied to a MetaFrame Presentation Server environment to optimize performance and stability. These group policies can be implemented with or without Active Directory, though the existence of Active Directory does make the administration of the policies simpler and more consistent. Sample policy template (ADM) files for the policies discussed below are provided in the Appendix.

Folder Redirection policies are used with mandatory or roaming profiles to maintain a single, centralized location for profile folders. Especially in published desktop environments, folder redirection policies are important because of the user’s perception that profile folders (such as “My Documents” and “Desktop”) are logical locations to store files. When users store files in these locations, the default behavior is to copy those files from the profile server to the MetaFrame Presentation Server during each logon; during logoff, those files are copied back to the profile server. This default behavior will cause login performance to suffer. With folder redirection policies enabled, the files are kept in a single, administrator-specified location. As a result, user logins proceed as quickly as possible, and the likelihood of profile corruption is reduced.

For some profile
folders, such as “My Documents” and “Desktop,” it is generally best to redirect them to the user’s home directory location, under subdirectories with the same profile folder names (i.e. “Desktop”). For other profile folders, an analysis of application behavior will be necessary. Some applications store files in the “Application Data” folder that are useful to conserve across multiple MetaFrame Presentation Server sessions. In other cases, this may not be useful if the files are only used for a single session.

Folder redirection paths can be in a UNC format (i.e. \\servername\share\%username%\Desktop) or using a drive letter (i.e. H:\Desktop). Use of a drive letter provides flexibility if home directories are stored across multiple file servers.

The Exclude Additional Directories from Roaming Profiles policy ensures that specified profile folders are not saved. Without specifying this policy, the “History,” “Local Settings,” “Temp,” and “Temporary Internet Files” folders are excluded from the roaming profile. If a user or application saves a file to one of these folders, they are not propagated to the roaming profile location during logoff. Specifying additional folders in this policy can be useful if an application creates large cache files to the “Application Data” folder that used in a single session only. In this way, these large files do not need to be copied between the MetaFrame Presentation Server and file server during login and logoff.

The Delete Cached Roaming Profile policy ensures that mandatory or roaming profiles are not cached on each MetaFrame Presentation Server at logoff. This policy ensures a consistent user experience and allows disk space to be utilized efficiently.

It may be beneficial to prevent these policies from applying to certain users, such as administrators. By setting the “deny” right to the “apply group policy” permission, users or groups can be excluded from policy application. The following screen shot provides an example where the “Domain Administrators” group will not have the policies apply:

Specifying Multiple Profiles

As discussed previously, a single user in a MetaFrame Presentation Server environment may be configured to use different profile types depending on what type of server they are using. In a farm employing load-managed groups (LMGs) this can be especially useful. A farm may have three different LMGs and use different profile types within each LMG.

The benefit of this approach is reduction in login time and profile corruption, while maintaining the administrative benefits of LMGs. Multiple profiles can be configured for users in one of several ways, depending on the operating system. The three options are:

• Environment Variables (Windows NT and Windows 2000)

• Force Local Profile (Windows 2000 and Windows Server 2003)

• Profile Path Overrides (Windows Server 2003)

These three methods are described below.

The environment variables method involves setting the users’ profile paths to a value with an environment variable, for example: %profilepath%\%username%. On each server, the %profilepath% environment variable will be created. For a farm with two load-managed groups running Microsoft Office and Lotus Notes, the variables could be specified using the “SETX” utility as follows:

• Microsoft Office servers: %profilepath% = \\fileserver\office-profiles

• Lotus Notes: %profilepath% = \\fileserver\lotus-profiles

When users login to the Microsoft Office servers, profiles will be loaded from \\fileserver\office-profiles\%username% as denoted by the user’s profile path and the value of the environment variable on those servers. This method also allows a user to have multiple mandatory profiles, or a blend of roaming and mandatory profiles by copying a mandatory profile (NTUSER.man file) into each specified profile path for every user.

Note: when implementing persistent environment variables using the “SETX” utility, a reboot may be required.

The force local profile policy prevents a user’s roaming profile from downloading, and instead creates a local profile for the user. This option is especially useful in situations where a “tiered” LMG approach is used, for example when published applications are run within published desktops. The “tier 1” LMG hosts the published desktop with Microsoft Office applications and those servers are configured for a roaming profile. The “tier 2” LMG hosts SAP, where the application is run via a pass-thru ICA connection within the published desktop. The “tier 2” servers would be configured to use a local profile since SAP does not store settings in the profile. The force local profile policy therefore allows a blend of roaming and local profiles to be used. This option is available in Windows 2000 with the hotfix provided in Microsoft knowledgebase article 817361. In Windows Server 2003 this policy is available in Active Directory (under the Computer Configuration->Administrative Templates->System->User Profiles settings) or by use of the following registry key on each server:

HKLM\Software\Policies\Microsoft\Windows\System: LocalProfile (REG_DWORD): 1

Finally, Windows Server 2003 provides the ability to specify profile path overrides at the server or, if using Active Directory for Windows Server 2003, at the OU level. This discards the user configuration in the domain and instead uses the override value. The policy “Set Path for TS Roaming Profiles” (available under Computer Configuration->Administrative Templates->Windows Components->Terminal Services) can be specified, or the following registry key can be configured:

HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services: WFProfilePath (REG_SZ)

Using this technique, users can have different roaming profiles depending on the GPO’s that are applied to specific servers.

Note: This policy works for roaming profiles only, and does not allow a single mandatory profile location to be specified for all users. This is because the policy appends a “\%username% value at the end of the path specified in the policy. As such, if a blend of roaming and mandatory profiles is desired, the NTUSER.man file will need to be copied into each user’s profile location.

Frequently Asked Questions

Q: Why do user profiles fail to unload?

A: This can happen for a number of reasons. Some Windows security patches, including those for the SMB signing vulnerability (329170) and Blaster worms (823980) have introduced issues with profile unloading. Microsoft has released subsequent hotfixes for these problems (see the hotfixes listed later in the FAQ). Sometimes profiles fail to unload due to an application not releasing a handle to a user profile folder or file. Microsoft has provided a tool called UPHCLEAN to rectify this problem. Please reference Microsoft knowledgebase article 837115 to obtain UPHCLEAN.

Q: Why do users get the default settings instead of personal roaming profile settings when logging into certain MetaFrame Presentation Servers?

A: This could be due to the issue described in Microsoft knowledgebase article 297379 entitled “Programs Can Revert to the Default Settings on Terminal Server”

http://support.microsoft.com/?kbid=297379

Q: I have to set user profile paths for several thousands users in my Active Directory. How can I automate this?

A: There are several options to automate the setting of user profile paths. ADSI for Windows 2000 does not provide extensions for the Terminal Services settings, but Windows Server 2003 ADSI providers do expose
these settings. For more information, see the following Microsoft Technet article: http://www.microsoft.com/technet/community/columns/profwin/pw0403.mspx

In addition, several freeware tools are available from a number of public Internet sites, including “TSCMD” which can be integrated into a command-line script. Finally, several utilities are provided by in the student resource CD for the Citrix training course “CTX6101 Citrix MetaFrame Presentation Server Design & Integration.”

Q: Why do logins take so long for some users, but not others?

A: User logins can take a long time with roaming profiles if folder redirection is not enabled. If users save large documents to the “My Documents” or “Desktop” folder, their logins could take several minutes or more. Users not saving files to profile folders won’t see the logon performance degradation. Folder redirection policies alleviate the majority of login performance issues.

Q: How can I delete cached local profiles on my servers?

A: The Windows Server Resource Kit provides a tool called “DELPROF” that will delete cached profiles

Q: Which Microsoft resources address common user profile issues?

A: Microsoft support articles or hotfixes can address a number of common problems. These include (but are not limited to:

Windows NT 4.0 Terminal Server Edition

191834 - Network Problems That Occur When Logging Off May Corrupt Roaming Profiles

297379 - Programs Can Revert to the Default Settings on Terminal Server

Windows 2000

817171 - Roaming Profiles are not unloaded on a computer that is running Terminal Services

827825 - "Windows Cannot Unload Your Registry Class File" Error Message When You Log Off Terminal Services

297379 - Programs Can Revert to the Default Settings on Terminal Server

294268 - Roaming Profiles Are Not Unloaded on a Computer That Is Running Terminal Services When GPOs Are Applied

327612 - User Profile Unload Failure When You Start, Quit, or Log Off NetMeeting

828153 - UsrClasses hive does not unload during logoff because of an intermittent handle leak in Spoolsv.exe

331627 - Terminal Services Client Cannot Obtain Terminal Services User Configuration from Domain Controller During Logon

327462 - Windows XP SP1 and Windows 2000 SP4 checks for existing roaming user profile folders when a roaming user profile is created

289564 - Issues When Windows 2000 Loads and Unloads Profile

Windows Server 2003

833409 -The roaming profile is not loaded after the user uses Terminal Services to log on to Windows Server 2003

832088 - Windows Server 2003 Terminal Server ignores the idle disconnect settings in a user profile

829109 - Terminal Server Profile Path Is Ignored If the User Who Is Logging On Does Not Have Query Information Permissions on the RDP-TCP Connection

828153 - UsrClasses hive does not unload during logoff because of an intermittent handle leak in Spoolsv.exe

327259 - Windows Server 2003 Checks for Pre-Created Roaming Profile Folders When You Make a Roaming User Profile

833781 - "Windows cannot unload your registry class file" error message when you log off from a Terminal Services session that is running on a Windows Server 2003 computer

829109 - Terminal Server Profile Path Is Ignored If the User Who Is Logging On Does Not Have Query Information Permissions on the RDP-TCP Connection

833409 - The roaming profile is not loaded after the user uses Terminal Services to log on to Windows Server 2003

821929 - User Cannot Create a Terminal Server Roaming Profile Path If a User with the Same Name Has Logged On from Another Domain

Q: Where can I obtain more information about Hybrid Profiles?

A: Contact the Citrix Consulting office in your region:

http://citrix.com/site/SS/supportThird.asp?slID=4758&tlID=10052



Primary links

Custom Search

Who's new

  • maczugaher
  • locksgydff
  • isotheces
  • ahundredyears7
  • Jacomijntjefu

Who's online

There are currently 0 users and 5 guests online.

KrissysCorner.com RuthSwensonLaw.com CreativeLizardProductions.com

DISCLAIMER:

None of this has anything to do with us, someone else is responsible for the entire thing, and we have no idea who or why. We do not know anything about it. It may be alien life forms for all we know: we haven't a clue. You cannot blame us for anything that may result from your visit. That was entirely your own personal choice, made by you of your own volition, and without our knowledge. We do not, after all, have any control over you and cannot by any stretch of the imagination be expected to accept or acknowledge, be it legally or morally, any accountability for decisions made by you on an independent basis, utilizing your own free will, and without our intervention. We are therefore in no way, shape, or form answerable to anyone for any consequences arising from the aforementioned or indeed any other actions, similar or otherwise, because it was not us that did, or did not do anything. It is not even remotely our fault, and we are in no way prepared or willing to accept any liability, not even slightly, ever. We are, in fact completely and utterly blameless, in that it is definitely not our concern, and no blame can possibly be laid at our doorstep, even if we had one, the possession of which we hereby reserve as being entirely our own free choice. The onus is not on us at all, and furthermore, never has been. The entire matter is wholly beyond our control, and completely out of our hands, each of which are washed scrupulously clean of the whole business. We are not accountable for anything at all, and we hereby categorically deny all responsibility for all that has ever, or will ever happen. Our innocence is therefore wholly beyond doubt and absolutely unimpeachable, and so cannot, under even the remotest or unlikeliest circumstances, be brought into question. By clicking either on a link on this site, clicking on a link that leads to this site, or by arriving at this site by natural or supernatural means, you are in effect accepting responsibility for the fact that it is all entirely your own fault, down to the most miniscule detail, and that you are wholly accountable for whatever outcome may arise as a consequence of the aforementioned action or actions insofar as they were undertaken personally by you on an entirely voluntary basis and without any persuasion, coercion or influence from any party or parties other than yourself. Don't come sniveling to us, we are only figments of your imagination. I also agree that if I am ever with a contributor to this website during mealtimes I agree to pay for any super-sizing of their meal, or at least a nice dessert or one of those foo-foo drinks with an umbrella or a monkey. By admitting to have seen the worthless spineless drivel on this website (also known as content)

I Agree Wholeheartedly and Without Reservation to the above. (Except maybe for that part about the monkey.)

All Your Base Are Belong To Us.

Soylent Green Is People!

Never make a bet with a Sicilian when Death is on the Line!

No. Really, I do agree.