How To Improve Windows Server Based Computing Performance

Whether you use Terminal Services, Citrix, 2X, ProPalms or something else, the core of performance optimisation is based in Windows.  There’s a Microsoft KB article that details some basic steps that will help you get the most out of your servers. 

It starts with getting the hardware right.  If you’re buying now you’ll get 64 bit processors.  That’s a good start:

• Dual CPU’s with Dual Core or Quad Core support.
• Memory – 2-4 GB RAM.
• Optional: DVD + Floppy.
• Raid Adapter with at least 128 RAM, that support Raid 1 with Hot Spare disk.
• Backup Battery for Raid Adapter.
• Three disks of at least 74 GB Ultra SCSI 3 15000 RPM or 74 GB SAS 15000 RPM (Raid 1 + Hotspare).
• Dual Power Supply.
• Remote Management Adapter.
• Dual Network Adapter 1-10 GB (Server Adapter) with an option for "Teaming" (Fiber Channel Network Adapters recommended).

A quick note here.  Memory is a very interesting subject and it’s usually the bottleneck on deciding how many users you can load onto a Terminal Server.  Note that 32 bit applications are very memory inefficient on 64 bit operating systems.  64 bit operating systems are capable of addressing serving much more RAM.  Have a read of Bernhard Tritsch’s (Terminal Services author and MVP) "Big Iron Test". 

Next up is is operating system.  Obviously you go with Windows 2003 now.  Windows Longhorn will offer some serious upgrades which may accelerate it’s deployment.  Do you go 32 bit or 64 bit. Having a 64bit CPU give you the option of either.  As always, do some testing:

• Are the applications that will be used on the Terminal Server supported when running under x64 runtime or WOW32 under x64 runtime?  Remember that 16 bit applications will not run on a 64 bit OS.
• Did tests show any improvement or degradation in the server performance when you ran them on a 64 bit OS?
• Does the current server hardware support 32-Bit runtime and/or x64 runtime?

You’ll also want to make sure that you run the latest service pack, currently SP1 for Windows 2003.  Some optimisations include:

• Use a dedicated server for Terminal Server tasks.  Don’t think "I’ve got a server with loads of RAM and CPU – why not install SQL on it".  That will kill the server.  You bought that hardware to replace PC’s, not other servers.
• Verify that third party products are supported under Terminal Server environment.  Watch out for dodgy applications – they sometimes require "application silos" where servers are dedicated to particular applications.
• Consider using "User Profile Hive Cleanup Service".
• look at using a large page file.  You will want to know how to overcome the 4,095 MB paging file size limit in Windows.
• You should also look into how to determine the appropriate page file size for 64-bit versions of Windows Server 2003.
• Optimsise graphics performance (Control Panel -> "System" -> "Advanced") and change "Visual Effects" and "Adjust for best performance of:" and "Memory usage".
• Optimise memory management by editing "boot.ini" file.
• Use the latest Client … RDP, Citrix, termanal OS, etc.
• Consider implementing QoS (Quality of Services) or Class of Service to boost RDP sessions over the network.
• Use low resolution for RDP display and consider disabling RDP features such as Auto Network drive mapping, Audio etc.
• Use as few GPO’s (Group Policy Object) as possible.  Check out loop back processing … very useful if you have users who have both full and thin client requirements and need differing policies depending where they have logged in.
• Do not use batch technology scripts.  Powershell, VBS, WMI, Windows Power Tools offer more options and better performance.
• Use printers drivers signed by Microsoft.
• If at all possible, only redirect the primary printer on full clients.  Try to configure printer mapping so that it logons do not wait for them.
• Look at pritner optimisation technology such as Riverbed, ThinPrint, etc, when printers are across a WAN from the Terminal Servers.  Some Citrix alternative technologies include optimisation solutions.
• If you enable NLB (Network Load Balancing), check that the current network equipment can handle NLB traffic.
• Do not use remote "Roaming Profiles" for Terminal Server access.  In fact, it might be worth not using roaming profiles at all.  Check out a free alternative called Flex Profiles.
• Disable unnecessary services/options in the user GUI (Graphical User Interface) such as Wallpaper, Active Desktop, Screen Saver, etc.
• Use a Terminal License Server that is local to the Terminal Servers.  MS PSS call #1: make sure you configure the right type of CAL in the TS configuration on the Terminal Services and that it matches the CAL’s on the Terminal License Server.
• There’s a recommendation to consider disabling the use of web browsers.  That’s not all that realistic.  What you can do is use a proxy filter to prevent unwanted bandwith eaters.

Test, test, test.  Even when you go into production, you should retain a test environment.  You may even need a development environment if you have internally developed applications.