Roaming user profiles tend to grow over time, which is sometimes referred to as profile bloat. In and by itself, profile growth is not a problem. Users of desktop PCs who log on the the same machine every day will not even notice that they have huge profiles ready to follow them around the network. Their locally cached copy of the roaming profile is always current. No need to fetch anything from a file server during logon.
Terminal servers, on the other hand, are usually configured to delete cached copies of roaming profiles after logoff. That makes perfectly sense, since the chances that a user is going to end up on the same server the next time he logs on are the smaller the larger the farm is. Although practically a necessity, the deletion of cached profiles poses entirely new problems: profile sizes have to be restricted somehow or logon times will shoot through the roof.
How not to do it
It may seem tempting to simply put file system quotas on the profile directories on the file servers. But that would lead not to smaller but to incomplete profiles. Once the quota on the file server is reached, the terminal server logging off the user will simply stop copying files over. Files that did not make it to the sanctuary of the roaming profile will mercilessly be deleted by the terminal server. The result is data loss.
Reducing the size #1: Profile Quotas
The correct way to enforce a maximum profile size is via group policy. The relevant setting is located here:
User Configuration\Administrative Templates\System\User Profiles\Limit profile size
If you enable it an additional process will be created per session: Proquota.exe watches over a user’s profile size. In case it grows larger than the configured maximum profile size a warning message is displayed which reappears after a configurable interval. But the most important thing is that users cannot log off until they have reduced the size of their profile somehow.
This approach has one major disadvantage: The task of managing the profile is burdened on the end user who does not have the skill to perform it. Instead, users will become frustrated and simply disconnect the session instead of logging off properly.
Probably for that reason profile quota behavior was changed in Vista and Server 2008: Instead of blocking logoff, Windows will not synchronize large profiles to the network upon logoff. With that, however, we are back at square one, file system quotas on the file servers (see above).
Reducing the size #2: Exclude Folders from Roaming
Specific folders in a user profile can be marked as non-roaming. These folders will be skipped when the profile is copied back to the file server during logoff. Again, this is configured via group policy:
User Configuration\Administrative Templates\System\User Profiles\Exclude directories in roaming profile
If this setting is not configured via policy, the system uses the default exclusion list stored in the registry:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs [REG_SZ]
The following folders are exluded by default on Windows XP and Server 2003:
- Local Settings
- Temporary Internet Files
The following folders are excluded by default on Windows Vista and Server 2008:
Although excluding folders is a first step towards true profile management, it has severe limitations: Only folders along with all their subfolders can be excluded. If only a single file within a folder needs to roam with your users, that folder cannot be excluded. If you consider that for a moment you may find that even the default selection of excluded folders is problematic. If you have only one misbehaving application that stores its settings in “Local Settings” or “AppData\Local”, respectively, you have a problem.
Reducing the size #3: Redirect Folders from the Profile to the Home Directory
Folder redirection, also configured via group policies, is certainly one of the better methods for keeping profiles small. Put simply, it changes the contents of the "User Shell Folders" registry key which are used by the system to determine the location of various user-specific folders:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Again, this comes at a price. Every read and write to a redirected folder must go over the network to a file server. Depending on how your applications access files, folder redirection may cause significant delays and put heavy load on the file servers. Additionally, only a select number of folders can be redirected. Though the list has been extended in Vista / Server 2008 with regards to their predecessors, folder redirection suffers from the same basic problem as folder exclusion (see above): There is no way to have a subfolder of a redirected folder remain on the local disk.