Windows 2003 user profiles allow customization and configuration of your users' environment. A "profile" is a collection of settings, configurations, and personal files that are unique to each user. Profiles permit multiple users to have different environments, even if they're all connected to the same server at the same time.
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 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 in Terminal Server environments, let's see how they work.
How User Profiles Work
A user that logs on to any Windows NT, 2000, XP, or 2003 computer uses some form of a Windows user profile. This user profile is made up of two parts:
The files and folders that make up a Windows user profile allow each user to have his own unique environment. One user's "My Documents" folder can be different from another user's "My Documents" folder. 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 Terminal Server 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. 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 his session. (Remember from Chapter 5 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 Terminal Server. This means that each user also has his own ntuser.dat file to permanently store his settings.
What about the few remaining 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 his own copy 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 Chapter 5 for more information on install mode.)
When 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 .INI file in the user profile, not the one in the common Windows folder. This allows each user to maintain 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 a sample. Figure 6.1 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
-
ntuser.ini: Contains a list of directories excluded from the roaming profile and the last state of the profile upload to the network location
-
Application Data: User specific application configuration information
-
Cookies: Internet Explorer cookies
-
Desktop: Contents of the Windows Desktop
-
Favorites: Windows Favorites shortcuts
-
Local Settings: Contains Temp, Temporary Internet Files, and History folders for the user
-
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. This directory can also be located in the user's home folder.
Figure 6.1: Elements of a user profile.
It's important to note that every user who logs on to your Terminal Server has some form of user profile, even if that user only runs a single application and not a Windows desktop. This is due to the fact that running an application in an RDP session does not prevent Windows from running a server desktop in the background. Terminal Server 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 four different ways that profiles can be used in Terminal Server environments:
-
Local profiles
-
Roaming profiles
-
Mandatory profiles
-
Flex / Hybrid profiles
Every Terminal Server user profile must be one of these four types. Each type is useful for different situations, and you can mix and match different types on the same server as needed.
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 \%systemdrive%\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 6.2 (next page), whenever a user with a local profile logs on to a Windows 2003 server, 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, 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 his own customized environment is loaded (complete with pink backgrounds and dinosaur cursors).
Figure 6.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 Terminal Servers since each server will contain a different local profile for each user. In an environment with five Terminal Servers, each user would have five different local 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, he might get Server B. From the user's standpoint, each day could bring a different profile with a different Windows background or application settings.
In light of this scenario, it would be helpful if there were a way to store user profiles in a centralized location, allowing the user to get his own profile no matter what Terminal Server he 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 computer, and the profile is loaded into its memory. In this way, each user gets her own environment no matter where she 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 original network share. That way, the next time the user logs on, the environment is exactly as she left it, even if she logs 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 the user's attributes in Active Directory Users and Computers or be configuring a profile path via a GPO.) 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 "master" copy of the roaming profile will be stored.
These two fields are empty by default, 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 6.3 (previous page).
Figure 6.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 receives the user's profile paths. It then 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 Services 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 useful 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 6.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 identical. The only difference is that 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."
Roaming profiles are great for Terminal Server environments, although there are a few things that you need to be careful with. The first is that as users use their profiles, the collective size of all the files that make up the profile will start to grow. Left unchecked, user profiles can potentially grow to several (or even hundreds of) megabytes. This can severely slow down the logon and logoff process since all those files would need to be copied across the network. (This is so important, in fact, that a whole section of this chapter is dedicated to limiting the size of your roaming profiles.)
Another potential problem with roaming profiles occurs when you have multiple groups of Terminal Servers separated by WAN links. On which side of the WAN do you store the profiles for users who need to use servers on both sides? Fortunately, there are tricks you can implement via Terminal Server GPOs that override your users' Terminal Server profile paths. We'll look at user GPO settings that are specific to Terminal Server later in this chapter.
User Profile Type 3. Mandatory Roaming Profiles
If you need strict control over your users, you can implement mandatory profiles. Mandatory profiles are a form of roaming profile. They both operate in the same way, except that with mandatory profiles the user's settings are not saved when they log off. 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.
User Profile Type 4. Flex / Hybrid Profiles
The last profile type is called a "flex" or "hybrid" profile. (These terms are usually interchangeable.) A flex profile is not really a profile type as defined by Microsoft. Instead, it is process that combines the security and control advantages of mandatory profiles with some scripting to achieve the flexibility of roaming profiles. Flex profiles have the advantages of roaming and mandatory profiles without the weaknesses.
Flex profiles allow you to control the user environment while still letting the users have some leeway in what they can and cannot change. The best part about flex profiles is that you can define which parts and settings of the profile are retained the next time the user logs on and which are discarded.
Figure 6.5: The user logoff process with Hybrid profiles
With the flex profile, you configure a mandatory profile for your user's Terminal Server session. This mandatory profile is loaded the first time a user logs on to your Terminal Server. The user works in her environment and modifies her settings as usual (most likely Office settings). When the user logs off, a script runs that calls an executable that saves the configurable settings you specified a file in the user's home folder. This file is usually between 20k and 100k.
Once the settings have been saved, the logoff process continues and the user's profile (which was based on a copy of the mandatory profile) is deleted.
The original mandatory profile is loaded the next time the user logs on. Once it's loaded, a logon script runs that "customizes" the user's environment with the settings that were saved in the home folder from the previous session.
Figure 6.6: The user logon process with Hybrid profiles
The beauty of this system is that you get the speed and stability of mandatory profiles, (not to mention the control they give you as an administrator), while still having the ability to allow users to retain certain settings within from their sessions. On top of that, flex profiles significantly reduce the chance of "profile corruption." Profile corruption usually occurs when large profiles are copied over congested networks. This is a common cause of support calls in Terminal Server environments that make heavy use of roaming profiles when the design hasn't been well-thought through.
The only drawback to flex profiles is that they are not officially supported by anyone. The idea itself has been around for quite some time, but it's implemented in different ways depending on where you find it. Support is generally only available from public web forums and communities. (See the appendix for a complete list.)
The most popular version of the flex profile is available for free. Called the "Flex Profile Kit," this tool was written by Jeroen van de Kamp of Log*in Consultants in The Netherlands. (Visit www.logincosultants.nl to download this kit. Work your way to the "tools" and then to the "downloads" section of the site.)
Van de Kamp's system utilizes a simple logon script that calls proflwiz.exe from the Office XP resource kit. This executable uses a simple INI configuration file to determine which registry settings or directories within the profile should be retained. When setup properly it takes no more than a second or so to run at logon and logoff, which in most cases is much faster than a standard roaming profile after users have been working on the system for awhile.
What's great about van de Kamp's script is that it can also be modified to use the ifmember.exe utility from the resource kit. This lets you configure settings to be retained based on a user's group membership.
Let's assume you have one group of users for whom you wish to retain Office settings and another group for whom you wish to retain only Visio settings. It would be a waste or resources and time to save all the settings for both groups of users if one group only needs Visio and another Office. Therefore, you could create two different configuration files and apply the appropriate one based on group membership. An example of such as script follows.
IfMemeber.exe "BWPTC\Citrix_Office"
if errorlevel 1 C:\ profkit\proflwiz.exe /S
F:\Settings\Office.ops /I C:\profkit\Office.INI /p
IfMemeber.exe "BWPTC\Citrix_Visio"
if errorlevel 1 C:\ profkit\proflwiz.exe /S
F:\Settings\Visio.ops /I C:\profkit\Visio.INI /p
IfMemeber.exe "BWPTC\Citrix_ALL"
if errorlevel 1 C:\ profkit\proflwiz.exe /S
F:\Settings\ALL.ops /I C:\profkit\ALL.INI /p
This single logon script controls the settings which users save based on group membership. Implementing a single script in this manner is often simpler than breaking the script into several individual scripts and applying them via GPOs.
Why should you care about user profile design?
The options you choose when designing the profiles for your Terminal Server environment will impact several areas, including:
Let's take a look at each of these areas.
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 a user logs on to a 32-bit (NT/2000/XP/2003) Windows system, a profile must be created. If this profile is created from scratch, 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, they may try to save their settings only to find that their settings were not retained the next time they log on. Mandatory profiles prevent users from saving any preferences or settings to their application environment. Roaming profiles allow them to save those settings at the cost of increased profile maintenance and logon/logoff times.
Continuity of the Users' Environment
If you use local profiles in an environment where users will try to save the settings from their Terminal Server 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 Terminal 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 a Terminal Server session, he must wait as his profile is copied from its network storage location to the local Terminal Server. If the profile is large or if the network connection is slow, the user will be forced to wait a long time.
Remember that roaming profiles are entirely copied down from the network when the user logs onto a Terminal Server. They're then 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, 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 Terminal Server users, there are many configuration options available. You'll need to provide answers to several design questions:
Will you pre-configure user profiles?
All settings and configuration information contained in a user profile must be configured at some point. You can either preconfigure it so that it's ready to go the first time the user logs on, or you can let users configure their settings after they log on.
When 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. Any changes that you make to the "Default User" profile will be included in each new copy of it, thereby allowing you to modify it to "preconfigure" user profiles.
There are two ways to configure the "Default User" profile. The first is manually:
-
-
-
-
-
-
-
-
Rather than configuring the "Default User" profile manually, there is a shortcut that is much easier to use:
-
-
-
-
-
-
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.
The process above can also be used to create a mandatory profile. Instead of copying the "Profile Template" profile to the Default User, you would simply copy the contents of the profile to the location where you wish to store your mandatory profile.
If you have more than one Terminal Server, 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 Pre-configuring User Profiles
Disadvantages of Pre-configuring User Profiles
Instead of pre-configuring user profiles, you can simply choose to have your user profiles generated from the generic "out of the box" profile. Or, if you have scripting skills, you can use a logon script to configure users' environments the first time they logon. (More information about scripting user environment changes is available later in this chapter)
Advantages of not Modifying the Default User Profile
Disadvantages of not Modifying the Default User Profile
What type of profile will be used?
At some point you must decide whether you will use local, roaming, mandatory, or flex profiles. As you're making this decision, keep in mind that you don't need to have an "all or nothing" solution. You may want to give some users flex profiles, while still restricting another group's ability to change any 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 a single application that does not depend on the user profile at all.
Also, if you're just starting out and you only have one Terminal 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
Disadvantages of Local Profiles
The next option is roaming profiles. Roaming profiles are used most often in real world environments for the convenience they provide over local profiles.
Advantages of Roaming Profiles
Disadvantages of Roaming Profiles
Mandatory profiles are most often used in locked-down environments, although they're not necessary if policies are configured properly.
Advantages of Mandatory Profiles
Disadvantages of Mandatory Profiles
Finally, Flex profiles are most often used in environments where speed, security and user perception are all a concern. (Of course, these are a concern in all environments, which is why this solution is rapidly growing in popularity.)
Advantages of Flex Profiles
Disadvantages of Flex Profiles
Limiting the Size of Roaming Profiles
By default, user profiles contain many files and folders. Because every user's roaming profile is copied to the Terminal Server at logon and copied to the master network share location at logoff, it's 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, she must wait for the entire profile to be copied to the Terminal 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 Terminal Server environments.
There are a few strategies that you can use to limit the size of roaming profiles:
Let's now examine what each of these strategies entails.
Redirect Folders to Locations Outside of the User's Profile
By default, any folders that contain user-specific information are part of the user profile. As you saw back in Figure 6.1, this includes folders that contain configuration information, application settings, and user data. For example, the "My Documents" folder is part of a user profile.
In using your Terminal Server, most of your users will make extensive use of their "My Documents" folder. In roaming profile environments, this can cause the profile to increase in size as users store more and more documents. (Recall that when using roaming profiles, an increase in size is a bad thing.)
To mitigate this size issue, you have the option of redirecting certain profile folders to locations outside of the user's actual profile. (This is part of the Windows IntelliMirror technology.) For example, 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 was taking place.
The advantage to redirection is that the contents of the "My Documents" folder would be stored in one location (like the user's home folder). This content would not be copied to and from the Terminal Server with the rest of the roaming profile. Users would access a single "My Documents" network location no matter what Terminal Server they used.
As an administrator, you'll need to 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 have a lot of flexibility in the implementation of folder redirection, allowing you to evaluate which folders to redirect on a folder-by-folder or user-by-user basis. If a folder contains configuration information that will be accessed in every session then you should probably not redirect it. However, folders containing user data files are good candidates for redirection since 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 Terminal Server session, a user will only actually use a fraction of those documents. There's no reason that all 200 documents should be copied to the Terminal Server every time the user logs on.
In Terminal Server environments, the most common implementation of this strategy is to redirect the "My Documents" and "Application Data" folders, although experimentation in your environment will tell you which folders work best for you.
While it's technically possible to redirect the "Desktop" folder, you should really only redirect this across the network if it's actually necessary. Since the "Desktop" folder corresponds to the actual user's desktop, redirecting it means that the user's desktop is a view to a remote network drive. The problem with this is that as long as the desktop is visible in the session, Windows will continuously refresh the contents of the desktop across the network. This doesn't affect anything in single server environments, but it has the potential to add unneeded traffic to your network when a Terminal Server is full of users whose desktops are redirected.
Advantages of Redirecting Folders
Disadvantages of Redirecting Folders
Procedure for Redirecting Folders
Redirecting folders is a "user" registry setting (in the HKCU hive) of the Terminal Servers. Folder redirection can be set manually with the registry editor or applied via a policy. Windows 2003 lets you redirect any of the 18 default folders.
When specifying a target for the redirected folder, you may enter a UNC name instead of a hard-coded path. If you configure your target path so that it 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.
Registry Location for Redirecting Folders
A user's folders can be redirected in the registry by the following path: HKCU\Software\Microsoft\Windows\Current Vesion\Explorer\UserShell Folders\
This registry key contains a values entry for each profile folder. By default, each folder points to a location in the %USERPROFILE% location. You can change these to point to any path you want. You may use hard-coded paths, UNC paths, and system variables (such as %HOMEDRIVE%).
Group Policy Location for Redirecting Folders
Within the Windows Group Policy MMC snap-in, you can redirect the Application Data, Desktop, My Documents, and Start Menu folders. To do this, navigate to the following path: User Configuration | Windows Settings | Folder Redirection | Right-click on the folder | Properties.
Note that in order to access this option, you must connect to a live Active Directory environment. You can't simply run gpedit.msc.
When configuring your GPO, you can set folder redirection on a group-by-group or a computer-wide basis (all within the same GPO). You can also graphically configure options such as whether you want to redirect all users to a single folder or redirect each user to their own folder.
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 from session to session. 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.
When a user with a roaming profile logs onto a Terminal Server, the entire contents of the roaming profile are copied to the Terminal 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 Terminal 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 Terminal Server up to the master profile location when the user logs off, they will already exist in the master copy, and so 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. You won't need to do this for new users that have never logged on since their master profile will be created on the network only after they log off of a Terminal 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 Terminal 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
Disadvantages of Excluding Certain Folders
Procedure for Excluding Certain Folders
By default, Windows Server 2003 automatically excludes the History, Local Settings, Temp, and Temporary Internet Files folders from roaming profiles. You only need to configure folder exclusion if you identify additional folders that do not need to be part of your users' roaming profiles.
Folder exclusion is a registry setting that can be set manually in a default or mandatory profile or that can be set via a group policy. (Group policies are covered in detail in the next section.)
Registry Location
In the registry, folders can be excluded via the following path:
Key: HKCU\Software\Microsoft\Windows NT\Current Version\Winlogon
Value: ExcludeProfileDirs
Type: REG_SZ
Data: Directory names to be excluded, relative to the root path of the profile. Multiple directories can be separated by semicolons. The default setting is" Local Settings;Temporary Internet Files;History;Temp."
Group Policy Location
For Windows 2003 domains
User Configuration | Administrative Templates | System | User Profiles | Exclude Directories in Roaming Profiles
For Windows 2000 domains
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 Terminal 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 that can be configured:
Advantages of Setting a Profile Size Limit
Disadvantages of Setting a Profile Size Limit
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. Even though 30MB is an extremely large profile, you can set it larger by modifying the ADM file (covered in the policies section of this chapter) as outlined in Microsoft Knowledge Base article 290324.
Group Policy Location
User Configuration | Administrative Templates | System | User Profiles | 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 often not worth the extra effort that goes into managing profiles.
Advantages of Doing Nothing
Disadvantages of Doing Nothing
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 Terminal Servers that he will be using. In the real world this is not always possible, specifically with users that travel or connect to multiple Terminal Servers in multiple locations. Consider the environment illustrated in Figure 6.7.
Figure 6.7: Users often connect to multiple Terminal Servers
In environments such as this, where users logon to Terminal Servers in multiple locations, the decision as to where to store the master roaming profile becomes more difficult. You need to either: (1) choose a location from which the user can copy the profile no matter where they log on; or (2) move to the flex profile system to make the size of the data copied across the network much smaller.
Advanced Profile Customization Options
Now that you understand the basics of profile design, there are some advanced design options to consider for your environment. Think about how you're going to manage cached copies of roaming profiles, and how you can customize the default "all-or-nothing" usage of roaming profiles.
Managing Cached Copies of Local Profiles
When a user with a roaming profile logs on to a Terminal Server, the profile is copied from its network storage location to the local Terminal Server. After the user logs off, the profile is copied from the local Terminal Server back up to the network location. At this point, by default, the Terminal 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 Terminal Server to run out of disk space since there could potentially 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 Terminal Servers so that they do not retain the locally cached copy of roaming profiles. In doing so, whenever a user logs off of a Terminal Server, his profile is copied back up to its master network share location and the local copy is deleted.
Deleting locally cached profiles from Terminal Servers will allow you to save disk space. However, this free space could come at the price of logon speed. By configuring a Terminal Server to delete all locally cached copies of roaming profiles, users' profiles will be copied across the network when they log on without exception. If the Terminal Server had an up-to-date locally cached copy of a user profile, logon speed is faster because the profile wouldn't have to be copied across the network.
Some 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, her profile will be copied to her master profile location when she logs off. 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 locally cached profile is the same as the network version.
However, if she logs back 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 originally copied the profile to the network share, Server B overwrote it later.
In this two server environment, the user has only 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 in which users were logging on to the same workstation every day.
Having the locally cached copy of the profile helps only if the local profile is as new as the remote roaming profile. In Terminal Server 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
Disadvantages of Deleting Cached Copies of Roaming Profiles
Procedure for Deleting Cached Copies of Roaming Profiles
This feature, like so many others, is simply a registry setting on your Terminal Servers. You can configure it manually with the registry editor or you can specify it in a policy.
Registry Location
Key: HKLM\Software\Microsoft\Windows\System\
Value: DeleteRoamingCache
Type: REG_DWORD
Data: 1 (enable)
Group Policy Location
Computer Configuration | Administrative Templates | System | User Profiles | 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 Terminal Servers' system drives are extremely small.
There's no real disadvantage to moving cached profiles to another drive, so 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 Terminal Server and the local profile assumes that the profile is local.
Advantages of Changing Cached Copy Location
Disadvantages of Changing Cached Copy Location
Procedure for Changing Cache Copy Location
When you change the profile path, you can only change the root directory for all profiles. This means that the "Default User" and "All Users" profiles are also moved to the new location.
Registry Location
Key: HKLM\SOFTWARE\Microsoft\Windows NT\Current Vesion\ProfileList
Value: ProfilesDirectory
Type: REG_EXPAND_SZ
Data: The local folder where you want to store user profiles. By default, this is "%SystemDrive%\Documents and Settings."
Selectively Implementing Roaming Profiles
A great new feature of Windows Server 2003 (technically this feature was introduced in Windows XP) is the ability to selectively enable or disable certain roaming profile functionality on a server-by-server basis. You can configure roaming profiles for your environment while excluding their use on certain servers.
This functionality is implemented via policies (which are fully covered in the next section). As you'll learn, you can apply these options locally to individual servers or to entire groups of servers via Group Policy Objects.
Preventing Servers from Downloading Roaming Profiles
If you have certain servers in which you do not want a user's roaming profile to be used, enable the following policy:
Computer Configuration | Administrative Templates | System | User Profiles | Only allow local user profiles
In the real world, this policy is used only when you have multiple types of Terminal Servers hosting different applications. Often there will be some servers that host applications that do not require user profiles (large line-of-business or ERP applications, for example). Why waste network bandwidth and time downloading a remote roaming profile to a server if the application doesn't use it anyway?
Preventing Servers from Uploading Roaming Profiles
In Windows 2003 you can also configure a policy that prevents the changes made to a roaming profile from being uploaded back to the roaming profile's master storage location.
Computer Configuration | Administrative Templates | System | User Profiles | Prevent Roaming Profile changes from propagating to the server
In a way, implementing this option on a server causes that server to treat all roaming profiles as if they were mandatory profiles.
Giving One User Multiple Profiles
In some situations you might want to give a single user multiple roaming profiles. Imagine that users are connecting to two (or more) sets of Terminal Servers separated by a WAN. On each set of servers they need to use a roaming profile to enable their settings to follow them from server to server in the load-balanced cluster. The problem is that if you put the master profiles on a segment near one of the sets of Terminal Servers, the system will have to copy the profile across a WAN link every time the user logs on to the other set of Terminal Servers. It will also have to copy it back across that WAN link every time a user logs off of those servers.
In order to fully appreciate the complexity of this scenario, take a look at Figure 6.8.
Figure 6.8: A situation that might require multiple profiles for each user.
-
-
-
-
-
-
-
-
-
-
-
-
In this scenario, the performance of the sessions on the Chicago severs may be just fine. Nevertheless, the users will complain about slow logon and logoff times due to their profiles being copied back and forth.
To combat this, you can configure some of your servers so that users that log on to them get their roaming profiles from alternate locations. This is commonly called a "user profile override" because the server will override the profile that's specified in the user's AD account object.
You can enable user profile overrides via a policy. (Policies are fully detailed in the next section of this chapter.) There is no real limit to the number of overrides you can implement. (If you have 55 servers, you could technically give a single user account 55 different user profiles—one for each server—if you really wanted to.)
The only downside to configuring multiple profiles per user is that you introduce a situation in which the user's environment changes depending on which Terminal Server he connects to. This is not usually a problem if one server runs a specific application like JDEdwards and the other set runs Microsoft Office, but you could wind up creating a new problem if both servers run Office and users want their settings to be maintained across both servers.
Group Policy Location
Computer Configuration | Administrative Templates | Windows Components | Terminal Services | Set Path for TS Roaming Profiles.
Advantages of Assigning Multiple Profiles to One User
Disadvantages of Assigning Multiple Profiles to One User
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 simple:
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, you won't need to worry as much 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.
Server Location
If all of your Terminal 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 reality, it's usually not that easy. If you have users that log on to Terminal 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.
Yazar ceyhun çamlı
\\ tags: Windows Server 2003, Windows Server 2003 User Profiles
Son Yorumlar