Microsoft Windows user profiles allow customization and configuration of your users' environment. Profiles form a collection of settings, configurations, and personal files that are unique to each user. They permit multiple users to have different environments, even if they're all connected to the same server at the same time.
For example, correctly implementing user profiles allows one user to set his Windows background to a picture of his kids, his mouse pointer to a dinosaur, and his menu color to purple-while another user can log on with normal settings.
There are hundreds of components that can be configured via user profiles. Some of these components include:
- Windows desktop configuration and settings.
- Internet connection settings.
- Printers and mapped drive connections.
- Temporary Internet file locations.
- Application settings, such as file paths, options, and preferences.
In addition to the hundreds of Windows components that can be configured with a user profile, every application loaded on a server introduces more of its own settings. (Microsoft Word has hundreds of settings, including file save locations, custom dictionary locations, grammar checking preferences, etc.) In fact, you can use a profile to customize practically any setting stored in the registry.
Before discussing how user profiles are used, let's see how they work.
How User Profiles Work
A user that logs on to any Windows NT or Windows 2000 computer uses some form of a Windows user profile. This user profile is made up of two parts:
- A collection of user-specific files and folders.
- Registry settings.
The files and folders that make up a Windows user profile allow each user to have his or her own unique environment. One user's "My Documents" folder can be different from another user's "My Documents" folder because even though each user sees the folder as "My Documents," they are two separate destinations accessed by two separate paths.
In addition to "My Documents," user profiles also include folders such as Desktop, Temporary Internet Files, Start Menu, and Favorites. (Basically, any folder containing files specific to a user is part of the user profile.) User profiles are important in MetaFrame environments since there can be hundreds of users on the same server at the same time, and each needs access to his own custom folders.
In addition to the collection of folders, a user profile also contains Windows Registry settings that are used to maintain the user's individual application preferences and settings. These include the file save locations in Microsoft Word, the proxy settings for Internet Explorer, the mouse cursor and scroll speed of Windows, and mapped printers and network drives.
Registry settings are stored in each user's profile in a file called ntuser.dat. Then, whenever a user logs on to Windows, his preferences are read from the ntuser.dat file in his user profile and merged into the system registry for the session. (Remember from Chapter 4 that the HKEY_CURRENT_USER registry hive maintains the user's settings during the session.)
Because each user has his own HKCU hive (even when multiple users are logged on at the same time), each can have his own settings on a MetaFrame server. This means that each user also has his own ntuser.dat file to permanently store his settings.
What about the few applications that use .INI configuration files instead of the registry for their configuration information? How do user profiles support different .INI files for different users? Fortunately, the architecture of Terminal Server allows multiple users to each have their own copies of centralized .INI files, even if these .INI files are stored in common locations. This architecture is set up automatically when a server is placed into "install mode" for application installation. (Refer to the previous chapter for more details on install mode.)
Whenever an application is installed while the server is set to "install mode," any .INI configuration files usually written to common folders are instead diverted to the user profile location. For example, if an application installation procedure tries to create a file called application.ini in the c:\windows\ folder, Terminal Server will add a "Windows" folder to the user profile and put the application.ini file in that new folder. Then, whenever the application looks for its application.ini configuration file, it is redirected to the stored in the user profile, not the one in the common Windows folder. This allows each user to have his own unique settings for applications, even if the applications don't properly use the Windows registry.
In order to further understand user profiles, let's examine at a sample one. Figure 5.1 (facing page) lists the files and folders that together make up the "default" user profile. In the real world, all user profiles are different, but this table lists the basics.
File or Folder: Description
- NTUSER.DAT: Registry file containing all HKCU registry settings for that user
- ntuser.dat.LOG: Transaction log file for ntuser.dat
- Application Data: User specific application configuration information
- Cookies: Internet Explorer cookies
- Desktop: Contents of the Windows Desktop
- Favorites: Windows Favorites shortcuts
- Local Settings for the user: Contains Temp, Temporary Internet Files, and History folders
- My Documents: My Documents
- SendTo : Shortcuts for the user's "Send To..." context menu
- Start Menu: Custom shortcuts for the user's Start Menu
- Windows: Any Windows folder components that are specific to that user, usually configuration and log files
Figure 5.1: Elements of a user profile.
It's important to note that every user who logs on to your MetaFrame XP server has some form of user profile, even if that user only runs published applications with no Windows desktop. This is because when you run a published application there is still a Windows desktop executing on the server. MetaFrame XP hides this desktop from the user so that the user can use his own local desktop.
Now that we've reviewed the basics of Windows user profiles, let's take a look at the three different types that there are:
- Local profiles.
- Roaming profiles.
- Mandatory roaming profiles.
Every Windows user profile must be one of these three types. Each is useful in different situations.
User Profile Type 1. Local Profiles
A "local profile" is a user profile stored locally on one computer. Local profiles contain the files, folders, and registry settings for each user as previously discussed. However, local profiles are only applied to the user environment when the user logs on to the computer where the local profile is stored. By default, local profiles are stored in the \%systemroot%\Profiles \%username%\ folder on Windows NT 4.0 computers. For Windows 2000 computers, local profiles are stored in the \Documents and Settings \%username%\ folder.
Because local profiles only apply when the user logs on to the particular computer where the profile is stored, they work best when users are allowed to save their settings and configurations in single-server environments.
As outlined in Figure 5.2, whenever a user with a local profile logs on to a Windows NT or Windows 2000 computer, the system will search its local hard drive to see if the user has an existing local profile. If the user's profile is found, it is loaded into memory and its settings are applied. If the system cannot find an existing local profile for the user, then a new local profile is created by making a copy of a generic profile template. This creates a local profile for the user, and any changes made to the configurations or preferences are stored in the user's new local profile. When the user logs off, the system retains the user's local profile so that the next time the user logs on to that computer own customized environment is loaded (complete with pink background and dinosaur cursors).
Figure 5.2: The user logon process with local profiles
Local profiles work well when users only log on to one server. The main disadvantage of local profiles is that they are always "local" to the computer where they were created. If a user has a local profile on one computer and logs on to another computer, a different local profile will be used or created. There is no way for the second computer to access the profile that the user has created on the first computer.
Obviously, local profiles can cause problems in an environment with multiple MetaFrame XP servers since each server will contain a different local profile for each user. In an environment with five MetaFrame XP servers, each user has five different user profiles. Users would get a different profile depending on which server they logged on to. Confusion would be compounded when users connected to load-balanced applications where they are automatically connected to the least busy server. One day, a user might connect to Server A. The next day, they might get Server B. From the user's standpoint, each day could bring a different profile with a Windows background or different application settings.
In light of this scenario, wouldn't it be great if there was a way to store user profiles in a centralized location, allowing the user to get his own profile no matter what MetaFrame XP server he is logged on to? Roaming profiles accomplish just that.
User Profile Type 2. Roaming Profiles
A roaming profile is a user profile stored on a network share instead of on a local computer. When the user logs on to a computer, the computer checks to see if that user is configured to use a roaming profile. If so, the computer copies the contents of the user's profile from the network share to the local drive, and the profile is loaded into its memory. In this way each user gets his own environment no matter where he logs on. Any changes that the user makes throughout the session are saved in the profile. When the user logs off, the profile is copied back to the network share. That way, the next time the user logs on, the environment is exactly as they left it, even if they log on to a different computer.
For a user to have a roaming profile, you simply specify the network path where the profile will be stored. (Do this by editing user's properties in User Manager for Domains or Active Directory Users and Computers.) When configuring a user's domain account, you will see two profile fields listed in the user's properties. One is labeled "User Profile" and the other is labeled "Terminal Services Profile." Both of these fields allow you to enter the network share path where the roaming profile will be stored. (In Windows NT 4.0 environments, you must use the version of "User Manager for Domains" from a Windows NT 4.0 Terminal Server Edition server. If you use a "User Manager for Domains" from a regular Windows NT Server, you will not see the extra Terminal Server-specific fields in a user's properties.)
By default these two fields are empty, indicating that the user is configured for a local profile. To configure a roaming profile, you must understand the differences between these fields and how they relate to each other. Let's consider what happens when a domain user logs onto a Terminal Server. You can visualize this process with Figure 5.3 (next page).
Figure 5.3: The user logon process with roaming profiles
When a domain user logs on to a Terminal Server, the server contacts a domain controller and attempts to load that user's roaming profile from the network path specified in the "Terminal Services Profile" text field property of the user's account. If that field is blank, the server will attempt to load the roaming profile from the path specified in the "Profile Path" text field. If that field is also blank, the server knows that no roaming profile has been specified, and so it creates or uses a local profile.
If a user logs onto a non-Terminal Server, the system will immediately look for the roaming profile in the "Profile Path" location, bypassing the "Terminal Server Profile" text field. This allows you to specify different profiles for users, depending on whether they log on to a Terminal Server or a regular computer. This is very useful in the real world because profiles on Terminal Servers tend to be different from profiles on regular workstations.
When a user with a roaming profile logs off of a computer, the roaming profile is copied from the computer back up to the roaming profile master location. As a result, the user will access the most up-to-date profile the next time he logs on, including any changes made during his last session.
Figure 5.4: The user logoff process with roaming profiles
Roaming profiles contain the same components, files, and folders as local profiles. In fact, if you were to compare the two types of profiles, you would find them to be 100% identical. The only difference is a profile stored in the network location specified in the user's domain account properties is called a "roaming profile." If the profile is stored locally on a computer not specified in the user account, it's called a "local profile."
User Profile Type 3. Mandatory Roaming Profiles
There's an additional type of user profile that offers stricter control over your users known as the "mandatory profile." Mandatory profiles are a form of roaming profiles. They operate in the same way, except that with mandatory profiles, the user's settings are not saved when they log off. This means that any configurations or settings that the user changes are not retained.
Mandatory profiles allow you to create standard profiles distributed to multiple users. They prevent users from "breaking" anything, since their changes do not get copied back up to the master profile location when they log off. The next time they log on, their mandatory profile is downloaded again, exactly the same as it was the first time.
Why should you care about user profile design?
The options you choose when designing the profiles for your MetaFrame XP environment will impact several areas, including:
- The administrative effort needed to add a server or a user.
- The amount of manual configuration a user must make to begin using MetaFrame XP applications.
- A user's ability to customize his environment.
- The overall continuity of the user's environment.
- The time it takes to launch an application or server session.
Let's detail each of these items that can be affected by the way you design user profiles.
Adding Users or Servers
If user profiles are designed properly, adding a server or user will be as simple as adding it to the domain. You won't have to worry about custom configurations or settings. However, if user profiles are not designed properly, you will need to perform manual customization before bringing new servers or users into your environment.
Amount of User Configuration
The first time that a user logs on to a Windows NT or Windows 2000 system, a profile must be created. If this profile is created from scratch, then the user must manually configure everything himself. That could take a fair amount of time, and there's always the risk that the user won't configure things properly. On the other hand, if you pre-configure the user's profile then the user can begin working immediately. All of the options will be set up properly.
Users' Ability to Customize Their Environment
If you give users mandatory profiles without telling them, then they may try to save their settings, only to find that their settings were not retained the next time they log on. Mandatory profiles will prevent users from saving any preferences or settings to their application environment. Roaming profiles will allow them to save those settings.
Continuity of the Users' Environment
If you use local profiles in an environment where users will try to save the settings from their MetaFrame XP sessions, the users may become confused because their environment could change from day to day as they connect to different servers. This would decrease productivity and increase users' frustration.
If your users use the same roaming profile on their local computer as they do when running sessions on MetaFrame XP servers, configuration settings or data could be lost from one of the sessions, since whichever session is logged off last will overwrite the master profile.
Application Launch and Session Start Time
When a user with a roaming profile logs onto an ICA session on a MetaFrame XP server, he must wait as his profile is copied from its network storage location to the local MetaFrame XP server. If the profile is large or if the network connection is slow, the user will be forced to wait a long time, causing more frustration.
Roaming and mandatory profiles are entirely copied down from the network when the user logs onto a MetaFrame XP server. Roaming profiles are copied back up to the network when the user logs off. Profiles can easily be several or even dozens of megabytes in size. If many users simultaneously log on and try to download their roaming profiles at the same time, it could negatively impact the network. You must consider the size of the profile, the speed of the network, and the number of users logging on or off together to determine if your network can support your users' profiles.
What are the User Profile Design Options?
When creating your strategy for managing the profiles of your MetaFrame XP users, you'll need to provide answers to several design questions. There are many configuration options available:
- Will you pre-configure any user profiles?
- What types of profiles will be used?
- Will you limit the size of roaming profiles?
- Where will roaming profile master copies be stored?
- How will you manage cached copies of roaming profiles?
Will you pre-configure user profiles?
All settings and configuration information contained in a user profile must be configured at some point. It can either be preconfigured by you before the user logs on or configured by the user after they log on.
If you're using local or roaming profiles, a copy is made of the local computer's "Default User" profile whenever a user who does not have a profile already created logs on. As an administrator, you can use this to your advantage because any changes that you make to the "Default User" profile will be included in every new copy of it.
There are two ways to configure the "Default User" profile. The first is manually:
- Open the registry editor. In this case, you must use regedt32.exe not regedit.exe.
- From the menu, choose Registry | Load Hive.
- Browse to the local "Default User" profile folder.
- Load "ntuser.dat" from the default user's profile.
- When the dialog box appears asking for a name for the new hive, enter any name you want. This name is what the newly loaded hive will be called within the Registry Editor. This name is temporary.
- Make any changes to the newly loaded registry hive.
- When you have finished, choose Registry | Unload Hive.
- From Windows Explorer, copy any files and folders that you want to be part of the profile into the "Default User" profile folder.
Rather than configuring the "Default User" profile manually, there is a neat shortcut that is much easier to use:
- Create a dummy user on the MetaFrame XP server called "Profile Template."
- Configure that user with the same rights and options as your new users.
- Log onto the MetaFrame XP server as that "Profile Template" user.
- Configure each option as you'd like the default to be for all of your new users. This could include file "save as" locations, the Internet Explorer home page, or any other desktop or application settings.
- Log out and log back on as the administrator.
- Copy the entire contents of the "Profile Template" user profile folder into the default user profile, overwriting everything.
Either of these methods will update the "Default User" profile, causing new users to receive their profiles based on this modified default user profile. You can make additional changes to the default user profile at any time, but be aware that any changes you make will not affect the current profiles that have already been created.
Also, if you have more than one MetaFrame XP server, then you should copy the "Default User" profile that you modified to all of your servers, since new user profiles are always generated from the local "Default User" path. If you don't copy the profile, you might get users with profiles based on the wrong template, depending on which server they logged on to.
Advantages of Preconfiguring User Profiles
- All users are ensured to receive the proper settings.
- The MetaFrame XP environment will be ready for users as soon as they log on.
Disadvantages of Preconfiguring User Profiles
- Preconfiguration is more work for you.
- All users are forced to get same the profile template.
Instead of preconfiguring user profiles, you can simply choose to have your user profiles generated from the generic "out of the box" profile.
Advantages of not Modifying the Default User Profile
- Allows users to configure things just as they like them.
- Good for environments where nothing will be the same across users.
- Good for environments where policies will be used to enforce settings. (See the next section for information about policies.)
- Less administrative work.
Disadvantages of not Modifying the Default User Profile
- Users must manually configure everything.
- Users might misconfigure a component.
What type of profile will be used?
At some point you must decide whether you will use local, roaming, or mandatory profiles. As you are making this decision, keep in mind that you do not need to have an "all or nothing" solution. You may want to give some users roaming profiles, while still restricting another group's ability to change settings with mandatory profiles.
Local profiles can be used where the settings in the profile don't matter. This is usually the case when you're using policies to define desktop settings or when users are connecting to restricted published applications without connecting to a full desktop.
Also, if you're just starting out and you only have one MetaFrame XP server, you can begin with local profiles. As your environment grows, you can copy the existing local profiles to network share locations; allowing them to be used as roaming profiles.
Advantages of Local Profiles
- They are the default option that works right out of the box.
- No administrative configuration is needed.
- Users can create a full, custom environment.
- Users can configure and change any settings.
Disadvantages of Local Profiles
- Only applied to local servers.
- Users can configure and change (break) any settings.
The next option is roaming profiles. Roaming profiles are used most often in real world environments for the convenience that they provide over local profiles.
Advantages of Roaming Profiles
- The same user profile can be applied across servers.
- Users can create a full, custom environment.
- Users can configure and change any settings.
Disadvantages of Roaming Profiles
- The network share location where the master profile is stored must be close to the MetaFrame XP server where users log on.
- Users can configure and change (break) any settings.
- There is no way to disable a roaming profile for users on specific machines
Finally, mandatory profiles are mostly used in locked-down environments, although they are not necessary if policies are configured properly.
Advantages of Mandatory Profiles
- Good for locked-down environments.
- Users cannot configure or change any settings.
Disadvantages of Mandatory Profiles
- User cannot configure or change any settings.
- No user settings are saved between sessions.
- There is no way to disable a mandatory profile for users on specific machines
Will you limit the size of roaming profiles?
By default, user profiles contain many files and folders. Because every user's roaming profile is copied to the MetaFrame XP server at logon and copied to the master network share location at logoff, it is important to keep the roaming profile as small as possible.
Left unchecked, a user's profile can easily grow to dozens or even hundreds of megabytes. When a user logs on, they must wait for the entire profile to be copied to the MetaFrame XP server from the master network share. If the profile is large, the logon process will be slow. It will seem to "hang" while the profile is copied. This is easily the most frequent cause of slow logons in MetaFrame XP environments.
There are a few strategies that you can use to limit the size of roaming profiles:
- Redirect certain folders to network locations outside the user's profile.
- Exclude certain default folders from the roaming profile.
- Apply an artificial size limit which will not allow the profile to exceed a certain MB size.
Let's take a look at what each of these strategies entails.
Redirect Folders to Network Locations Outside of the User's Profile
By default, any folders that contain user-specific data are part of the user profile. These include folders containing configuration information and application settings and folders containing large amounts of user data, like the "My Documents" folder. If the "My Documents" folder is part of a user's roaming profile, then the profile can grow rather large as the user stores more and more documents in it.
To mitigate this size issue, you have the option of "redirecting" certain folders to locations outside of the user profile. For example, this redirection could allow the "My Documents" folder to point to a static network location that never changes, instead of a folder inside the user's roaming profile. Users with a redirected "My Documents" folder continue to open, save, and browse "My Documents" as usual. They would not be aware that any redirection is taking place.
The advantage to redirection is that the contents of the "My Documents" folder would be stored in one location. This content would not be copied to and from the MetaFrame XP server with the rest of the roaming profile. Users would access a single "My Documents" network location, no matter what MetaFrame XP server they use. Often, these folders are redirected to the user's home drive. (More on home drives in the next section.)
As an administrator, you must choose which folders to redirect from user profiles. Choosing these folders creates a balance between keeping the user profile as small as possible while allowing users to have fast, local access to their data.
You can evaluate which folders to redirect on a folder-by-folder basis. If a folder contains configuration information or data that will be accessed in every session, then you should not redirect it. However, folders containing user data files are good candidates for redirection because not all user files are used during every session. A user's "My Documents" folder might be 50MB, containing 200 Word documents. However, throughout the course of a MetaFrame XP session, a user will only actually use a fraction of those documents. There is no reason that all 200 documents should be copied to the MetaFrame XP server every time the user logs on.
The one exception to this rule is the "Desktop" folder. Users often store files on their Windows desktop, which corresponds to the "Desktop" folder in their user profile. Even though this folder may contain large amounts of user data, you should not redirect the desktop folder to a location outside of the user profile. The desktop folder was designed to be a local folder on each computer. If you redirect it to a remote network location, then the MetaFrame XP server will continually refresh it across the network, adversely affecting the performance of your network and your MetaFrame XP server.
Advantages of Redirecting Folders
- Redirected folders are not part of the roaming profile that is frequently copied across the network.
- Profiles can be smaller, allowing quicker logon times.
Disadvantages of Redirecting Folders
- Redirected folders must be accessed across the network from within MetaFrame XP sessions.
Procedure for Redirecting Folders
Redirecting folders is a "user" registry setting of the MetaFrame XP servers. Folder redirection can be set manually with the registry editor or applied via a policy. There are many folders that can be redirected, including the following partial list:
- Application Data
- Network Neighborhood
- My Documents
- My Pictures
- Start Menu
- Local Settings
When specifying a target for the redirected folder, you may enter a UNC name instead of a hard-coded path. If your target path ends with the %username% variable (example: \\servername\sharename \%username%) then the path will automatically be created, so long as the user has "modify" share and NTFS rights.
A user's folders can be redirected in the registry with the following path: HKCU\Microsoft\Windows\Current Version\Explorer\User Shell Folders\
This registry folder contains several values. When you are editing the registry, you can change the data of any value to point to any path you wish. UNC paths are acceptable.
System Policy Editor Location
The system policy editor for Windows 2000 or Windows NT 4 can also be used to redirect folders. When using the system policy editor, the following folders can be redirected:
- Network Neighborhood
- Start Menu
To configure folder redirection, navigate to the following path: User | Windows NT Shell | Custom Folders.
Group Policy Location
Within the Windows 2000 Group Policy MMC snap-in, you can redirect the following folders:
- Application Data
- My Documents
- My Pictures
- Start Menu
Within the group policy snap-in, navigate to the following path: User Configuration | Windows Settings | Folder Redirection.
Exclude Certain Folders from Being Copied to the Roaming Profile
You may determine that some folders in a user's profile contain data not worth saving. In order to further decrease the size of roaming profiles, you can choose to exclude those folders from the roaming profiles altogether. Excluding folders causes them not to be copied up to the master profile network share after a user logs off.
In Windows 2000, by default, the Local Settings, Temporary Internet Files, History, and Temp folders are excluded from a user's roaming profile. If you choose to exclude any additional folders or any folders in Windows NT 4, you should do this before you go live with your MetaFrame XP environment.
When a user with a roaming profile logs onto a MetaFrame XP server, the entire contents of the roaming profile are copied to the MetaFrame XP server from the user's master profile network share, regardless of whether you have excluded certain directories.
Directory exclusion only affects roaming profiles as they are copied from the MetaFrame XP server back to the master profile network share, after the user logs off. This only indirectly affects the size of the profile at the master location, because if you implement directory exclusion after a user has established a roaming profile with a master copy stored on the network share, the directory exclusion will not make the profile any smaller.
The reason for this is that the excluded folders will already be part of the user's master roaming profile on the network share. They were put there when the user logged off with a roaming profile before you configured the directory exclusion. Even though the newly-excluded directories will never be copied from the MetaFrame XP server up to the master profile location when the user logs off, they will already exist in the master copy, and so they will be copied down every time a user logs on.
If you want to exclude directories from the roaming profiles of existing users with established roaming profiles, you need to manually delete the folders from their roaming profile master locations. Of course you won't need to do this for new users that have never logged on, because their master profile will be created on the network only after they log off of a MetaFrame XP server that has the exclusion applied.
If you choose to exclude directories from roaming profiles, be sure to set the same exclusions on each of your MetaFrame XP servers. Even one server without set exclusions would cause the unwanted folders to be copied to the master profile network share, becoming a permanent part of the user profile copied down every time a user logs on. You would then need to manually delete the folders from the master profile.
Advantages of Excluding Certain Folders
- Reduces the size of the roaming profile.
Disadvantages of Excluding Certain Folders
- Information in the excluded folders is not retained between sessions.
Procedure for Excluding Certain Folders
User profile folder exclusion requires at least Windows NT 4.0 Service Pack 4, although this shouldn't be a problem since MetaFrame XP requires Windows NT 4.0 Service Pack 5. Folder exclusion is a registry setting that can be set manually or set via a user policy. (User policies are covered in detail in the next section.)
In the registry, folders can be excluded via the following path:
Key: HKCU\Software\Microsoft\Windows NT\Current Version\Winlogon
Data: Directory names to be excluded, relative to the root path of the profile. Multiple directories can be separated by semicolons. (Example: temp;local settings\temporary internet files)
System Policy Editor Location
Note: Many of the design options listed in this section can be implemented via a system policy or a group policy (in addition to the manual registry setting). System and group policies are fully discussed in the next section of this book, but the references are made here so that you'll know where to implement these profile settings once you read about policies.
User | Windows NT User Profiles | Exclude directories in roaming profile.
Group Policy Location
User Configuration | Administrative Templates | System | Logon / Logoff | Exclude Directories in Roaming Profile.
Apply an Artificial Size Limit
In addition to the various methods by which roaming profile size is kept under control, there is another method that can be used as a last resort if other methods fail. As an administrator, you can specify the maximum size, in kilobytes, of roaming profiles on MetaFrame XP servers. This size limit acts as a sort of "circuit breaker," kicking in when the profile gets too large.
In addition to the actual size limit specification, there are several other options you can configure:
- Should the user's registry file be included in the calculation of the profile size?
- Should users be notified when their profile exceeds the maximum?
- Do you want them to be notified with a custom message?
- How often should that message be displayed?
Advantages of Setting a Profile Size Limit
- Guarantees that a profile won't get too big.
- Works in concert with other methods.
Disadvantages of Setting a Profile Size Limit
- Should not be used as a surrogate for other methods.
- Can cause user confusion when the limit is reached.
Procedure for Setting a Profile Size Limit
Limiting the size of a roaming profile can be accomplished by configuring a series of registry keys manually or through a policy. The artificial limit can be set up to 30MB. If you would like to set a limit larger than 30 MB, refer to the Microsoft Knowledge Base article Q290324.
System Policy Editor Location
User | Windows NT User Profiles | Limit Profile Size.
Group Policy Location
User Configuration | Administrative Templates | System | Logon / Logoff | Limit Profile Size.
Choosing Not to Limit the Roaming Profile Size
Even after reviewing the options available for limiting the size of user profiles, you might make the decision not to limit the size. In small environments, it is not worth the extra effort that goes in to managing profiles.
Advantages of Doing Nothing
- Least amount of work.
Disadvantages of Doing Nothing
- Logons can be slow.
- MetaFrame XP servers can run out of disk space.
- If the environment grows, you will need to address profile size at some point.
Where will roaming profile master copies be stored?
The convenience of using roaming profiles produces one side effect: the roaming profile must be copied over the network when the user logs on and logs off. In a perfect world, you would always be able to store the master copy of a user's roaming profile near the MetaFrame XP servers that they will be using. In the real world, this is not always possible, specifically with users that travel or connect to multiple MetaFrame XP servers in multiple locations. Consider the environment illustrated in Figure 5.5 (next page).
Figure 5.5: Users often connect to multiple MetaFrame XP servers
In environments such as this, where users log into multiple locations, the location of the master roaming profile becomes more difficult. You need to choose a location from which the user can copy the profile no matter where they log on.
How will you manage cached copies of roaming profiles?
When a user with a roaming profile logs on to a MetaFrame XP server, the profile is copied from its network storage location to the local MetaFrame XP server. After the user logs off, the profile is copied from the local MetaFrame XP server back up to the network location. At this point, by default, the MetaFrame XP server retains a local copy of the user's profile. This copy is saved locally so that if the user logs onto that server again before the roaming profile changes, the roaming profile does not need to be copied across the network, saving time and bandwidth.
However, in large environments, this profile "caching" could cause the MetaFrame XP servers to run out of disk space, sincethere could be hundreds of user profiles saved locally. After all, any user that logs on once will have a locally cached profile taking up space. Plus, the more servers you have, the less likely it is that a user will actually connect to the same physical server twice in a row.
To combat this, you can configure your MetaFrame XP servers not to retain the locally cached copy of roaming profiles. In doing so, whenever a user logs off of a MetaFrame XP server, his profile is copied back up to its master network share location and the local copy is deleted.
You can save server hard drive space by deleting locally cached profiles from MetaFrame XP servers. However, this hard drive space could come at the price of logon speed. By configuring MetaFrame XP servers to delete all locally cached copies of roaming profiles, every user's profile will be copied across the network when they log on, without exception. If the MetaFrame XP server had an up-to-date locally cached copy of the user profile, logon speed is faster because the profile would not have to be copied across the network.
Many people wonder if it is worth trading hard drive space for logon speed. Consider this situation:
If a user with a session on Server A logs off, her profile will be copied to her master network profile location. Her locally cached profile on Server A will have the same timestamp as the roaming master copy.
If the user then runs a session on Server B, when she logs off, her profile will be copied to her master profile location. Her locally cached profile on Server B will now have the same timestamp as the roaming master copy. At the next logon, if she logs on to Server B, no network copy will be needed because the local cached profile is the same as the network version. However, sif he logs on to Server A, the network copy will take place because the master profile has been updated since she last logged onto Server A. Even though Server A copied the profile to the network share, Server B overwrote it later. In this two server environment, the user only has a 50% chance that she will log on to the server that has the same profile as the network, thus saving the network transfer time. If there were ten servers, she would only have a one in ten chance. Twenty servers would be one in twenty.
Saving locally cached copies of roaming profiles was designed for traditional (non-Terminal Server) environments, where users were logging on to the same workstation every day.
Having the locally cached copy of the profile only helps if the local profile is as new as the remote roaming profile. In MetaFrame XP environments, the hard disk space is usually more important than the chance of good network speed, causing most administrators to configure their servers to delete locally cached roaming user profiles.
Advantages of Deleting Cached Copies of Roaming Profiles
- Saves drive space.
Disadvantages of Deleting Cached Copies of Roaming Profiles
- Could cause slower logons.
Procedure for Deleting Cached Copies of Roaming Profiles
This feature, like so many others, is simply a registry setting on your MetaFrame XP servers. That means you can configure it manually with the registry editor or you can specify it in a policy.
Key: HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\
Data: 1 (enable)
System Policy Editor Location
Computer | Windows NT User Profiles | Delete cached copies of roaming profiles.
Group Policy Location
Computer Configuration | Administrative Templates | System | Logon | Delete cached copies of roaming profiles.
Instead of deleting user profiles to save storage space, some people choose to store them in a location other than the default system drive. This allows the profiles to be stored on a large drive, since many of the MetaFrame XP servers' system drives are extremely small.
There is no real disadvantage to moving cached profiles to another drive, as long as that drive is local. If you try to put cached profiles on a remote drive or network share, you will get extremely poor performance. All session interaction between the MetaFrame XP server and the local profile assumes that the profile is local.
Advantages of Changing Cached Copy Location
- Often MetaFrame XP servers have large drives other than the system drive.
- Get the performance of cached profiles without the risk of running out of disk space.
Disadvantages of Changing Cached Copy Location
- Cached drive must be local to each server.
Procedure for Changing Cache Copy Location
When you change the profile path, you can only change the profile root directory, which means that the "Default User" and "All Users" profiles are also moved to the new location.
Key: HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\ProfileList
Data: The new folder (Windows 2000 default is %SystemDrive%\ Documents and Settings.)
Considerations when Designing User Profiles
Now that we've reviewed all of the options available when choosing how to apply user profiles, let's consider the questions that you need to answer. Answering these questions should make your design pretty simple:
- Are users authenticating individually?
- Does each user need his own customized environment?
- How much network bandwidth is available?
- What are the locations of servers that users will log on to?
User Connections and User Authentication
If users are connecting anonymously, then they're not logging in with a unique domain account that will need to support individualized profiles. You can, however, configure a user profile that will be used by the anonymous accounts so that all anonymous users have any needed custom settings. On the other hand, if users are connecting explicitly, then you can support them with whatever type of user profile meets your needs. (See Chapter 15 for more information about explicit and anonymous applications.)
Custom User Environments
If all of your users will share the same environment, then your profile design job is straightforward-you won't need to worry about custom profiles for each user. If users do need custom environments, then you will need to spend time thinking about how user profiles will be used.
Network Bandwidth Availability
If bandwidth is plentiful, then you won't need to worry about the location of the master roaming profile network share or the size of roaming profiles. If bandwidth is scarce, you may spend significant time designing these components.
If all of your MetaFrame servers are in the same location then it's relatively simple to decide on the location of the server that will contain master roaming profiles. Of course in the real world, it's usually not that easy. If you have users that log onto MetaFrame XP servers in different physical locations or across WAN links, the decision of the master profile server location becomes difficult. You need to balance profile size and functionality with loading speed and network bandwidth availability.