The Trials And Tribulations Of Windows Terminal Servers (Part 2)
In the first segment I wrote on Terminal Services I discussed Terminal Services roaming profiles, their difficulties and some best practices. In this article I want to cover the various performance improvements you can make on your network to improve the overall responsiveness of terminal services. Be aware that while most of these are from well tested documents, making changes to the Windows registry is never guaranteed to turn out well . . . You have been warned.
Let's begin with some simple tweaks which do not require the black arts of registry hacking. Log on to your terminal server(s) and open up the system properties control panel, either by right-clicking on "My Computer" and selecting "Properties" or by opening it up in the "Control Panel". Click on the "Advanced" tab. Click the "Settings" button which is under the "Performance" heading. Click on the "Advanced" tab in the new dialog which opens. For your terminal servers you should have the "Processor Scheduling" set to favor "Programs" and you should have the "Memory usage" set to favor "Programs" as well. This is telling Windows that the kernel should give resource priority to interactive applications instead of server services. In addition, you should create a swap file that is at least 4GB and if at all possible place the swap file on a different physical disk. If you're using a RAID array or a SAN, putting this on a different logical drive will not make much difference.
In a Terminal Services environment, unless you only have a single terminal server, your terminal performance very much tied to how the rest of your network servers are performing. With roaming profiles and redirected folders, if your file server is not at it's peak; your users will let you know about it. So, I recommend following a wonderfully detailed document published by IBM about tuning Windows servers. The file can be downloaded HERE. Read through it carefully and try to apply what you know about how your network is organized and how your users function to determine the best settings for your network.
When using Internet Explorer inside of a terminal session, you will notice in many cases that animations (flash, gifs, etc..) will cause the terminal server to work very hard on encoding the screen changes and transmitting them to the client. This can cause high CPU load and higher bandwidth use on your network. There are several Group Policy settings which you can use to prevent animations from taking up precious CPU resources, but I have found that using Mozilla Firefox (>=3.0) with the "FlashBlock" and "AdBlock" extensions work better than anything. Many legitimate web sites require the use of flash, and the group policies for Internet Explorer are more like a fireman's axe than a surgeons' knife for eliminating unwanted content. By using FlashBlock you can disable flash animations by default, but still allow them to run and load if the user needs them. Score one for Open Source!!
One of the more annoying applications which users need access to tends to be Adobe Acrobat. Acrobat version 9, while better than previous versions in many ways, still tends to overuse the CPU of a terminal server. In addition, the Adobe applications tend to lock files in the "Application Data" folder and thus cause problems with roaming profiles. There are several ways to alleviate this issue. One way is to not use Adobe Acrobat, but instead a 3rd party PDF reader like Evince. It does not have as many features as Adobe's product, but it works far better on a terminal server.
The biggest headache I have run across in a Terminal Services environment is the problem of printers. Terminal Servers do not deal well with printers, and I have long ago learned that offloading the printing work to a print server helps. Beyond that, offloading the print drivers to a separate server seems to be the best practice. It is possible, with some print server configurations, to have the print server present all printers using a generic PostScript interface and driver. This ensures that only a single print driver is required on the Terminal Servers, and it is a very reliable and well tested driver. The specifics of how to build such a print server are beyond the scope of this document, but check the links below for suggestions on how to get started.
References:
CUPS Print Server
Performance Tuning For Terminal Services
Let's begin with some simple tweaks which do not require the black arts of registry hacking. Log on to your terminal server(s) and open up the system properties control panel, either by right-clicking on "My Computer" and selecting "Properties" or by opening it up in the "Control Panel". Click on the "Advanced" tab. Click the "Settings" button which is under the "Performance" heading. Click on the "Advanced" tab in the new dialog which opens. For your terminal servers you should have the "Processor Scheduling" set to favor "Programs" and you should have the "Memory usage" set to favor "Programs" as well. This is telling Windows that the kernel should give resource priority to interactive applications instead of server services. In addition, you should create a swap file that is at least 4GB and if at all possible place the swap file on a different physical disk. If you're using a RAID array or a SAN, putting this on a different logical drive will not make much difference.
In a Terminal Services environment, unless you only have a single terminal server, your terminal performance very much tied to how the rest of your network servers are performing. With roaming profiles and redirected folders, if your file server is not at it's peak; your users will let you know about it. So, I recommend following a wonderfully detailed document published by IBM about tuning Windows servers. The file can be downloaded HERE. Read through it carefully and try to apply what you know about how your network is organized and how your users function to determine the best settings for your network.
When using Internet Explorer inside of a terminal session, you will notice in many cases that animations (flash, gifs, etc..) will cause the terminal server to work very hard on encoding the screen changes and transmitting them to the client. This can cause high CPU load and higher bandwidth use on your network. There are several Group Policy settings which you can use to prevent animations from taking up precious CPU resources, but I have found that using Mozilla Firefox (>=3.0) with the "FlashBlock" and "AdBlock" extensions work better than anything. Many legitimate web sites require the use of flash, and the group policies for Internet Explorer are more like a fireman's axe than a surgeons' knife for eliminating unwanted content. By using FlashBlock you can disable flash animations by default, but still allow them to run and load if the user needs them. Score one for Open Source!!
One of the more annoying applications which users need access to tends to be Adobe Acrobat. Acrobat version 9, while better than previous versions in many ways, still tends to overuse the CPU of a terminal server. In addition, the Adobe applications tend to lock files in the "Application Data" folder and thus cause problems with roaming profiles. There are several ways to alleviate this issue. One way is to not use Adobe Acrobat, but instead a 3rd party PDF reader like Evince. It does not have as many features as Adobe's product, but it works far better on a terminal server.
The biggest headache I have run across in a Terminal Services environment is the problem of printers. Terminal Servers do not deal well with printers, and I have long ago learned that offloading the printing work to a print server helps. Beyond that, offloading the print drivers to a separate server seems to be the best practice. It is possible, with some print server configurations, to have the print server present all printers using a generic PostScript interface and driver. This ensures that only a single print driver is required on the Terminal Servers, and it is a very reliable and well tested driver. The specifics of how to build such a print server are beyond the scope of this document, but check the links below for suggestions on how to get started.
References:
CUPS Print Server
Comments