Welcome back AskPerf! After our Windows 7 / Windows Server 2008 R2 Launch Series, it’s time to get back to business as usual. Before our series I wrote a post touching on User Profile issues on Terminal Servers. At the end of that post, I promised we’d come back and discuss some things you can do to speed up logons. So, without further ado, let’s dive right in …
One of the most dreaded calls for Helpdesk staff is, “It’s taking a really long time to log on. Can you fix it?” When the problem is restricted to just one desktop, the problem is fairly manageable. However, when the problem exists on a Terminal Server, the situations become a bit more complex because of the number of variables involved. One of the unwanted side effects of slow logons on a Terminal Server is that users become reluctant to ever log off! Beyond the additional system overhead of the idle sessions, there are other possible unwanted consequences. Users with idle sessions may have inadvertently left files open in their session that are needed by other users (think shared Excel spreadsheets etc). Since the session is still open (but idle), the files are locked.
Obviously you can set up policies to disconnect or terminate idle sessions after a certain amount of inactivity (and you should do so anyways), but that doesn’t always make for the best user experience (especially if you get over-zealous)! If you can address the slow logon issues, thereby improving the user experience, users are more likely to log off, knowing that getting back into a session is not a painful experience.
We’ve already discussed how Folder Redirection can help you in terms of providing a consistent user experience, but they can also help speed up logon and logoff times. Some other things to look at include using Group Policy to:
- Cache roaming profiles
- Use small profiles by setting a limit on the size of a user profile
- Delete unused cached profiles
Let’s talk about each of these, beginning with Roaming Profiles. Terminal Servers normally attempt to retrieve roaming profiles from the central location where the profiles are stored. If you have a network with slow links (or high latency links) between the Terminal Server and the Profile server, this can cause significant delays in logging on. If the users were able to log on with a locally cached copy of the profile when the network connection between the Terminal Server and Profile slow was slow or unreliable then that can provide some relief. One thing to note is that if you do cache the profile on the Terminal Server, that cached copy is only used if the original roaming profile is not available. Now, there is a tradeoff for caching the profiles – namely hard disk space. One definite caveat is that new users may not be able to log on if the space allocated to cached profiles gets filled up. In addition, cached profiles that are not being used, should be removed to free up disk space. On Windows Server 2003 systems, you can use the User Profile Deletion Utility (see the link below for the download location). Use this utility as opposed to simply removing the files from Windows Explorer. If you use Windows Explorer to remove the files, the registry information for those profiles is not deleted. You can also use group policies on the terminal servers to delete profiles that have not been used in a specified amount of time (we’ll go over this in a second).
Moving on to profile sizes, one of the biggest problems that we see is that profiles have gotten bloated. Remember that when a user logs on to the terminal server, their roaming profile has to be copied to that server, and then when they log off, the profile has to be copied back to the central network location. Writing profiles back to the storage space does not just involve the delta between the starting profile and the ending profile – but in effect the entire profile. If you don’t have folder redirection enabled for the user folders like Documents, Pictures etc. think about what might happen if a user saved 15GB of data into his Documents folder. This user might log on and have to go to lunch before his profile is copied down. Now expand the scenario to 30 users – and everyone tries to log on right when they come in at 9:00 AM. Your network bandwidth would start to disappear fairly rapidly. By using a combination of folder redirection (to prevent profile bloat and slow logon / logoff times) and group policies to limit the size of the roaming profile you can help to optimize the user experience. The policy setting is located under User Configuration\Administrative Templates\System\User Profiles, and is called Limit Profile Size. If you are combining this setting with folder redirection, you’ll want to take note of the size of the NTUSER.DAT file when setting your group policy setting.
OK – getting back to those cached profiles, I mentioned the User Profile Deletion utility above to remove old cached profiles. But, you can perform the same sort of management via Group Policy. There are two settings to be aware of (both under Computer Configuration\Administrative Templates\System\User Profiles):
- Delete Cached Copies of Roaming Profiles: If you enable this, then the cached copy of a user’s roaming profile is deleted as soon as they log off. However, since the cached profile does provide a fallback mechanism in the event that the user can’t get to their roaming profile, the user will get a temporary profile in this scenario – and any changes that they make to the profile will not be saved
- Delete User Profiles Older than a Specified Number of Days on System Restart: If you enable this setting, then cached profiles that are older than the threshold that you specify are deleted. But – there is a caveat – the deletion only occurs at system restart. So, if you don’t reboot your terminal servers regularly, then this setting might not help you out
OK – that will do it for today’s post. As always, please test any changes in a non-production environment to gauge their impact and usefulness before you go live! Until next time …