The Trials And Tribulations Of Windows Terminal Servers (Part 1)
My employer made the decision to move to thin client computing several years ago, and I wanted to share with people some of the lessons learned and best practices for using Windows Terminal Services. In addition, I want to let people know what will not work (as best I can tell). I've experienced a lot of frustrations, but as we have overcome problems we have documented and studied. Without further ado, here's what I know.
Terminal Services Profiles
First off, Terminal Services Roaming Profiles suck. We use a load balancer to distribute our users across 12-14 terminal servers, and to make that work properly you have to use Terminal Services roaming profiles. They're simple to configure, but a basic configuration is rarely optimal.
By default, everything that would normally be in your "Documents and Settings" folder on XP is stored in your profile, with the exception of the "Local Settings" hidden folder. When you log on to a terminal server, the profile is copied from a file server location on the network. When you log off, the profile is copied back to the file server location.
Here are some of the problems with how roaming profiles work in terminal services. I'll discuss several concerns in detail over the next few paragraphs, and hopefully save you some of the pain and agony that we have gone through.
First, without lots of tweaking, the user registry hive will not unload in time while logging off to be copied back to the file server location. This can be fixed using the User Profile Hive Cleanup Service, but that is not well documented anywhere. You must install the UPHC on every terminal server and reboot before it will work properly. It helps a lot, but is still not perfect. Sometimes hung applications cannot be cleaned up by UPHC and they will corrupt the user's registry hive; if this happens the user's profile has to be recreated from scratch (at least, I have not found another solution).
By default, the "My Documents" and "Desktop" folders are also contained inside of the profile. This means that after some time of users saving files in those locations, their log on times grind slower and slower while waiting to copy all of their data. You can mitigate this by implementing folder redirection along with loopback policy processing. You'll learn very quickly in a terminal services environment that Group Policies are INDISPENSABLE. By placing your terminal servers into their own Organizational Unit within Active Directory, you can then apply group policies to that group of servers. Within the computer policy, if you enable "Loopback Policy Processing", you can apply user level policies to users which only take effect when that user log on to a terminal server but not when they log on to a desktop. Our best results have been with redirecting folders to the user's home directory folder on the file server. We usually redirect the "My Documents" and the "Desktop" folder, but I recommend against redirecting the "Application Data" folder due to performance problems.
In the next installment, I will discuss some of the performance tweaks you can implement and what they accomplish. Also, if you have comments or suggestions, feel free to comment below!!
Terminal Services Profiles
First off, Terminal Services Roaming Profiles suck. We use a load balancer to distribute our users across 12-14 terminal servers, and to make that work properly you have to use Terminal Services roaming profiles. They're simple to configure, but a basic configuration is rarely optimal.
By default, everything that would normally be in your "Documents and Settings" folder on XP is stored in your profile, with the exception of the "Local Settings" hidden folder. When you log on to a terminal server, the profile is copied from a file server location on the network. When you log off, the profile is copied back to the file server location.
Here are some of the problems with how roaming profiles work in terminal services. I'll discuss several concerns in detail over the next few paragraphs, and hopefully save you some of the pain and agony that we have gone through.
First, without lots of tweaking, the user registry hive will not unload in time while logging off to be copied back to the file server location. This can be fixed using the User Profile Hive Cleanup Service, but that is not well documented anywhere. You must install the UPHC on every terminal server and reboot before it will work properly. It helps a lot, but is still not perfect. Sometimes hung applications cannot be cleaned up by UPHC and they will corrupt the user's registry hive; if this happens the user's profile has to be recreated from scratch (at least, I have not found another solution).
By default, the "My Documents" and "Desktop" folders are also contained inside of the profile. This means that after some time of users saving files in those locations, their log on times grind slower and slower while waiting to copy all of their data. You can mitigate this by implementing folder redirection along with loopback policy processing. You'll learn very quickly in a terminal services environment that Group Policies are INDISPENSABLE. By placing your terminal servers into their own Organizational Unit within Active Directory, you can then apply group policies to that group of servers. Within the computer policy, if you enable "Loopback Policy Processing", you can apply user level policies to users which only take effect when that user log on to a terminal server but not when they log on to a desktop. Our best results have been with redirecting folders to the user's home directory folder on the file server. We usually redirect the "My Documents" and the "Desktop" folder, but I recommend against redirecting the "Application Data" folder due to performance problems.
In the next installment, I will discuss some of the performance tweaks you can implement and what they accomplish. Also, if you have comments or suggestions, feel free to comment below!!
Comments