CertCities.com -- The Ultimate Site for Certified IT Professionals
Listen, See, Win! Register for a Free Tech Library Webcast Share share | bookmark | e-mail
  Microsoft®
  Cisco®
  Security
  Oracle®
  A+/Network+"
  Linux/Unix
  More Certs
  Newsletters
  Salary Surveys
  Forums
  News
  Exam Reviews
  Tips
  Columns
  Features
  PopQuiz
  RSS Feeds
  Press Releases
  Contributors
  About Us
  Search
 

Advanced Search
  Free Newsletter
  Sign-up for the #1 Weekly IT
Certification News
and Advice.
Subscribe to CertCities.com Free Weekly E-mail Newsletter
CertCities.com

See What's New on
Redmondmag.com!

Cover Story: IE8: Behind the 8 Ball

Tech-Ed: Let's (Third) Party!

A Secure Leap into the Cloud

Windows Mobile's New Moves

SQL Speed Secrets


CertCities.com
Let us know what you
think! E-mail us at:



 
 
...Home ... Editorial ... Tips ..Tips Article Friday: April 4, 2014


My 10 Favorite Tips for Increasing Windows 2000 Terminal Server Performance
Get your registry editor ready and open up Win2K Group Policy! Here's 10 things you can do right now to boost your server performance.

by Ron Oglesby

12/18/2000 -- Whether you are new to Microsoft's Windows 2000 Terminal Services or have been around since the idea began with Citrix Systems' Winframe, we are all looking for the same thing: ways to make our servers hummmm. To achieve this is not easy. And to get that extra performance out of your servers is even tougher. Those of us who have been around these multi-user machines for a while know that there are a ton of tricks to help move you into application hosting nirvana. So I am here to let 10 of the technical cats out of the bag, so to speak. These are not unknown tips, and they are by no means the only changes you can make to increase performance, but they are 10 of my favorites.

As always, make a system backup and a backup of the registry prior to implementing any of these changes. And always test changes in a non-production environment first. Now that the technicalities are out of the way, let's get started:

Tip #1: Set the 2nd Level Data Cache in the Registry
Microsoft says that NT/2000 will attempt to detect the amount of L2 cache on the processors from the HAL. If the system is not able to detect the processor cache it will set the following registry entry to a value of 0. This value tells NT and 2000 that the processors in your server have 256K of L2 cache.

HKEY_LOCAL_MACHINE\System\Current Control Set\Control\Session Manager\Memory Management

"SecondLevelDataCache"= 0 REG_DWORD

Meaning that you paid good money for the processors with extra cache but the operating system is not using it. In some of Microsoft's Q articles they state no performance increase will be seen from setting this value correctly. Most of us in the industry wonder, "Why have the entry then?" In almost every case I have seen of a server running hot on the processor side, we were able to increase performance by setting this value to the actual size of the cache in K.

To do this, open the entry in Regedit or Regedt32 (see Figure 1, below, for instructions) and set this entry to the decimal value of your cache in K. For example, if you have 1 MB worth of L2 cache on each processor this needs to be set at 1024. (NOTE: Do not add up all the processors cache as a total -- it should be the value of cache on the individual processors.)

Win2K Regedit

Figure 1, Working with Regedit: The registry can be accessed and edited using Regedit.exe or regedt32.exe. I prefer regedt32 for editing but regedit has search capabilities that are extremely useful. In either case you will need to backup the registry hive you are working on. With regedit, this is done by exporting the key; in regedt32 you should back up the hive.

Tip #2: Disable Paging of the Windows NT Executive
Win2K (and NT, too) uses a swap file. We all know this. It takes blocks of memory, or pages, and writes them out to the hard disk to free up physical RAM for other applications or system processes needing memory. No big deal here.

But the Win2K system will also page out some of its own kernel code and drivers to the hard disk. Sounds funny, doesn't it? This was originally intended for machines with limited amounts of RAM, allowing the system to free up memory for applications to use. But on a system with at least 128 MB, you can stop this from happening. How does this help you? Servers running as terminal servers tend to have large amounts of RAM (well over 128), and will see an increase in operating system performance by stopping this paging of the Windows Executive.

Note that Microsoft articles tend to conflict with each other on this item. In article Q184419, Microsoft states that this may "decrease the response time on systems with large amounts of RAM." Interesting. Compare this to its "Instant Rules of Thumb for Tuning and Sizing NT Server" paper, where it states the exact same procedure will result in a performance increase on servers with large amounts of RAM.

I have almost always seen a performance boost on the operating system side when this is done, and believe it's worth it. To stop paging the NT Executive, set the following registry entry:

HKEY_LOCAL_MACHINE\System\Current Control Set\Control\Session Manager\Memory Management

"DisablePagingExecutive"= 1 REG_DWORD

Tip #3: Stop Unnecessary Processes from Running in Each User's Session
One of the unique things about Terminal Services is that multiple users all log onto the same machine concurrently. The problem here is that applications sometimes tend to load services per-USER instead of per-MACHINE. Take a quad processor server hosting around 70 users. Add one process for each user. Say this process takes about a fourth of a percent of processor time, plus a MB or two of RAM. You now have a server running at about 17 percent of overall processor utilization, using about 140 MB RAM, and none of your users have started any applications.

These services or programs commonly load from the Local Machine hive in the registry, meaning that they run for each and every user that logs on. Some come right from Microsoft, like LOADWC.EXE (Web Check for IE), or from Citrix Systems, ICABAR.EXE (the admin tool bar in MetaFrame). They can also be called from the user's start-up folder, or the All User's profile. But their most likely spot is in the registry. Check out the following registry keys.

HKEY Local Machine\Software\Microsoft\Windows\Current Version\Run or (Load)

HKEY Local Machine\Software\Microsoft\WindwosNT\Current Version\Winlogon\Userinit

These are easy. Remove the calls from this location and they are gone for good.

HKEY Current User\Software\Microsoft\Windows\Current Version\Run

This is a bit trickier. These calls are coming from the user's registry and will need to be removed with a script at user logon. If you catch it before your users have ever logged on, you can make the change to the default user's profile. If not, then I would recommend a simple KIX script or even REGINI.EXE to remove the calls as the users log on.

Tip #4: Turn Off the Processing of Unused GPOs
When using Group Policy Objects in Win2K, you have the ability to keep the server from reading a part of the policy that is unused. A policy is, in effect, editing the registry. If all of your changes were made to the user configuration (HKEY Current User) then why have Windows spend time reading the computer configuration (HKEY Local Machine)? Since, in most cases, the changes made were in the user configuration, you can disable the Computer configuration for the Group Policy, and thereby see an increase in performance. See Figure 2, below, for instructions on how to do this in Win2K.

GPO General Tab

Figure 2, Disabling Computer Configuration or User Configuration in Group Policy: To disable either of these settings, select the Group Policy Object from within the Microsoft Management Console. Right-click the GPO and select properties. The settings can be disabled at the bottom of the General tab (shown in graphic).

Tip #5: Reduce Amount of Graphical Changes in a User's Session
In a Terminal Services environment, the user is really running a remote control type connection. This means that only video changes are sent from the server to the client to update the client's GUI. Because of this, the more graphical changes present in a session, the more video updates on the client, and the more video updates the client receives, the slower application appears to run.

By tweaking/verifying the proper graphic settings, you can increase the end user's application performance. This is done by setting WinStation User Overrides in the following location.

HKEY_LOCAL_MACHINE\System\Current Control Set\Control\Terminal Server\WinStations\RDP-tcp\

Create a key called "UserOverride" in the connection key you are using. If using Microsoft's RDP over TCP/IP, it would be in the "RDP-tcp" key. If you are using Citrix Systems' ICA protocol over TCP, then the sub-key under WinStations would be "ICA-tcp."

In the following examples we are using Microsoft's RDP over TCP/IP and are creating sub-keys under "UserOverride."

The first sub-key under UserOverride is "Control Panel\Desktop" with the following registry entries:

HKEY_LOCAL_MACHINE\System\Current Control Set\Control\Terminal Server\WinStations\

RDP-tcp\Control Panel\Desktop

"AutoEndTasks"="1" REG_SZ

"CursorBlinkRate"="-1" REG_SZ

"DragFullWindows"="0" REG_SZ

"MenuShowDelay"="10" REG_SZ

"SmoothScroll"=0 REG_Dword

"WaitToKillAppTimeout"= "20000" REG_SZ

"Wallpaper="="(none)" REG_SZ (none=no value specified)

The second sub-key is under the newly created "Control Panel\Desktop" and is called "WindowMetrics":

HKEY_LOCAL_MACHINE\System\Current Control Set\Control\Terminal Server\WinStations\

RDP-tcp\Control Panel\Desktop\WindowMetrics

"MinAnimate"="0" REG_SZ

To see a graphical representation of these changes, see Figure 3, below.

Override Key

Figure 3, Creating a 'User Override Key': These settings will reduce some of the repetitive graphical changes that the users see and improve their end-user performance.

Tip# 6: Ensure Profile Size and Stability
In a majority of desktop environments, the user's profile is kept locally on the machine. In almost every Terminal Services environment with more than one server, the profile becomes an NT roaming profile. This in and of itself is not surprising. The problem is that most common applications (Internet Explorer, Office 2000, Lotus Smart Suite etc.) tend to save or cache their files in the user's profile, which can become a serious issue for logon and log off speeds as the profiles grow in size. I had one customer that had users with more than 50 MB in temporary Internet files alone. Needless to say their logon took eight or so minutes and their log off would generally fail in the copy phase and cause profile corruption.

First, let's limit the profile size with a group policy. You don't want to get crazy and restrict the profile size to 10K or anything like that, but using a policy to limit the size of the profile to five or 10 MB would not be out of hand at all.

In Win2K this can be accomplished through the Group Policy Object (GPO) attached to the Users OU or the Terminal Server's OU. Access the GPO through the MMC. You will find the Limit Profile Size option under User Configuration, Administrative Templates, System, Logon/Logoff. Enable this object and set your size limitation in KB (see Figure 4, below).

Limit Profile Size

Figure 4, Limiting Profile Size: To do this, access Group Policy, User Configuration, Administrative, Templates, System, Logon/Logoff.

With the profile limited in size we now need to keep applications such as IE, Word 2000 and others from writing/saving information there.

In Win2K, a GPO will allow you to redirect the user's My Documents folder. This is where most of your users will save their documents and is the default location for Microsoft Office products. This change is a must for profile stability and will help to keep documents, spreadsheets and other files in their home directory and out of their profile (callout). By accessing the GPO we can make this change under User Configuration, Windows Settings, Folder Redirection. Here you should enable the My Documents and Application Data objects and set their paths to a UNC that matches the location of the user's home directories (see Figure 5, below). The settings for these objects will even allow you to move their current folders out of their profile and into the new location.

Security Group

Figure 5, Folder Redirection: For applications that do not save to My Documents, you will have to either implement an NT 4.0 style .ADM file or change the application's registry settings with a script at login.

For Internet Explorer, we need to redirect the temporary Internet files to a directory on the local Terminal Server. I find it easiest to set the user's IE cache location by editing the default user's profile on the Win2K Terminal Server prior to users logging on for the first time. But in larger environments or on servers that the users already have established profiles, this may be accomplished at login by using a script. I prefer KIXtart or WSH scripts for this purpose, but third-party vendors such as Script Logic (www.scriptlogic.com) can provide a GUI based application to make this easier.

To edit the Default User's profile prior to the log on, use regedt32.exe and load the Default User's ntuser.dat as a hive (found in the Documents and Settings directory on the system drive). The entry that needs to be changed to redirect the cache is located in the following registry key.

HKEY Current User\Software\Microsoft\Windows\Current Version\Explorer\User Shell Folders\

"Cache"="%systemdrive%\Inettemp" REG_EXPAND_SZ

Once the value is changed you need to unload the hive so that users can access it again.

Default User Logon

Figure 6, Editing Default User Logon: Using the system drive variable will create a directory on the local machine where all temporary Internet files will be stored.

Change the default value of this entry to reflect your environment (see Figure 6, above). I use %systemdrive%\Inettemp in my installations, but this can be changed to reflect your needs. Using the system drive variable will create a directory on the local machine where all temporary Internet files will be stored The directory should have permissions set so users can read and write to it and a schedule should be set up to delete these files on a regular basis. Changing this to a fixed directory on the machine instead of their home directory will accomplish a couple of things. First, it will keep these temporary files out of the user's profile. Second, it will keep the files out of the Home Directory and help to reduce the space used by home directories. This way you are killing two birds with one stone.

Other applications tend to write their info into the profile also. These applications will need to be looked at on a case-by-case basis to determine the following:

  1. Is it saving data to the profile? And, if so, is it affecting the profile size?
  2. If you answered yes to the first question, can this be changed? Are the settings for this application stored in the registry, an INI file or is it "hard-coded" so that it cannot be changed?

If the information is stored in the registry you will need to track the registry settings with a utility like REGMON (www.sysinternals.com) and make the appropriate changes as specified above. If it is stored in an INI file, you will need to determine if the program is reading a machine or user-specific INI file, and if you can make changes to it. Sometimes, contacting the application vendor for this information can prove extremely useful and help to speed up the process.

Tip #7: When Using Office 97 or 2000, Disable Background Grammar Checking
This may not be something that will make some users extremely happy, but if your company uses Office on a consistent basis, it may really improve performance. Some scalability tests have shown that background grammar checking can cut your number of users in half.

I recommend changing these with a script at logon, but you can also make these changes on new installation to the default user so that every new user automatically has them (see Figure 7, below).

For Office 97 the registry entry is as follows:

HKEY_CURRENT_USER\Software\Microsoft\Office\8.0\Word\Options

"AutoGrammar"="0"

For Office 2000:

HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Options

"AutoGrammar"=0 REG_DWORD

Disabling AutoGrammar

Figure 7, Disabling AutoGrammar: Setting the AutoGrammar settings in the registry is basically changing this setting for the user.

Tip #8: Optimize Partition Cluster Size
During install, Win2K will create the NTFS partition with a 512 byte cluster size. This is considered, by most admins, to be too small. To increase the size of the cluster, format your partition prior to the install by mounting the drive in another NT machine and manually formatting it within the running operating system. On a standard system, partitions with a 4096 byte cluster size is generally optimal. You can use disk administrator to do this or run a manual format with the format command.

Format : /FS:NTFS /A:

Tip #9: Increase the SMB Size for Applications that do Copy/Move Functions
When running applications that use a lot of copy or move functions to a remote server, the speed at which this function completes is determined by network speed (of course) and by the SMB size. NT/2000 negotiates the SMB size and will generally set this to 4K blocks for functions that are moving or copying data to a remote server. By increasing this block size, you will allow the server to complete its file copies faster. This will increase the performance of the application making the copy/move calls.

The maximum value this can be set at is 64K. For most Ethernet environments, a size of around 14k or 14,596 bytes is optimal. Setting this to the maximum of 65,535 bytes is not suggested, however. This setting is located in the registry at:

HKEY_LOCAL_MACHINE\System\Current Control Set\Services\LanmanServer\Paramerters

"SizReqBuf"= 14596 REG_DWORD

For more information on the SMB size negotiation, see MS article Q223140.

Tip #10: Configure the Page File, Early and Properly
In NT 4.0, the page file is set to the amount of physical RAM + 12 MB. In Win2K terminal servers, this is considered too low. The default recommended page file is 1.5 times the amount of RAM in the server. This can vary between 1.5 times the amount of RAM all the way to 2.5 times the amount of RAM. Most Windows and NT gurus consider this unusual. But in other application hosting environments this is almost the standard. (Example: Sun Microsystems recommends the swap space be set at 2.2 times the amount of RAM for its Solaris 7 OS.)

For maximum performance, set the page file to two times the amount of RAM and move it off of the OS partition. Moving the page file is done not only for performance reasons but it will also keep that enormous pagefile.sys from crowding your system partition. Imagine trying to fit a 4 GB page file on your current system partition -- Ouch!

See Figure 8, below, for instructions:

Virtual Memory

Figure 8, Setting Virtual Memory: In Windows 2000, the Page File Properties can be configured by going into the properties of My Computer, selecting the Advanced tab, Performance, then selecting the change option in the Virtual Memory box.

With your basic NT skills, a good Internet connection, and this list in hand you should be well on your way to terminal services nirvana. Enjoy.


Ron Oglesby is the Citrix and Terminal Services team leader at Progressive Network Solutions in Downers Grove, Illinois. When he is not hacking the registry on his Windows 2000 server he is busy trying to finish his computer lab in his basement. He can be reached at .
More articles by Ron Oglesby:


There are 64 CertCities.com user Comments for “My 10 Favorite Tips for Increasing Windows 2000 Terminal Server Performance ”
Page 1 of 7
12/27/00: Mark says: Item 10 page file. I don't see the need to move it from the OS partition. Because of crowding. I have the pagefile set at the max size (4GB) and have no problem. The SYS partition size is set up at 17GB. Which gives me more room then I need. The system seems to run just fine this way.
12/29/00: Tony says: Re Mark Carey's comment: "Item 10 page file. I don't see the need to move it from the OS partition. Because of crowding. I have the pagefile set at the max size (4GB) and have no problem. The SYS partition size is set up at 17GB. Which gives me more room then I need. The system seems to run just fine this way." I agree with Ron (Author) with a big nod. Regardless of the OS partition size, fragmentation will still occur (even with lots of room) and the disk seeker head will still come under process competition if all files are on one physical disk. Definite performance enhancements and much better OS stability come from separate, dedicated, smaller (4-9GBs) physical disks. A separate disk for the OS (4 GB will be plenty for the OS for quite a while), then 2 or more separate disks to spread out the pagefile (an internal OS algorithm will use all pagefiles or prioritize which pagefile is least active and use it), then a separate disk for the logfiles for W2K DCs and Exchange servers (sequential log writing will be at warp speed when having a separate dedicated area), and then a separate disk for the RAID partition for applications on a Microsoft Terminal Server (MTS). Again, smaller but additional disks for better read performance. I keep observing these 36 GB and 72 GB drives coming out and the only thing they are good for are massive datacenters with archiving requirements of graphic files and such. Also, setting the pagefile to a definitive size: MIN and MAX = 2.5 times of RAM also will help (the OS will never dedicated any resources for pagefile dynamics). This perhaps sounds expensive with several smaller disks vs a larger, single disk. But for MTS, most deployments for a planned 30 or more concurrent users, the server is a dual or quad processor with a decent capacity drive cage (6 or more drives). Somehow, get the money from management and the ROI will occur much sooner and all users will look up when you walk in the room. Later, Tony, MCSE+I
1/2/01: Ron says: Thanks for the input Tony. You are correct at setting the pagefile size min and max at 2.5xRAM. I personaly am a big fan of 2.0x the ammount of RAM but with certain apps/setups 2.5 will increase performance. Obviously in a perfect world i would love to have a separate disk for the pagefile all together. But we all know that in large installations the customer will generally not pay for an extra drive in each of 30 or 40 servers.... My primary concern here was to get newbies to understand that due to the large amounts of ram these servers generaly have and the page file equation for MTS (generaly 2xRAM)they will more than likely crowd the system partition or wind up with a performance problem. Thanks for the comments
2/14/01: andy says: moving page files, log files off to different spindles has the single largest performance increase on the same hardware you can get....Look for SCSI drives that support scatter/gather disconnect operations/ So many times, I see a server with a 3 drive raid partitioned into drive volumes and page & log files are distributed to those extra volumes.... this accomplishes nothing towards performance, in fact it probably slows performance due to directory caching and head movement... Great comments from everyone..
3/19/01: Douglas says: It is doubtful that Item #1 is of any value, except perhaps on a Pentium I. The following is taken from Microsoft article Q183063 (Detailed Explanation of SecondLevelDataCache): "This is not related to the hardware; it is only useful for computers with direct-mapped L2 caches. Pentium II and later processors do not have direct- mapped L2 caches."
3/19/01: Jim says: While the article is good, the web page has some real problems. 1. The screen shots suck! Can't read them. 2. (for the Webmaster) Print This Page link includes the navigation at the left, and chops off right side of the text. If you are going to bother with a Print This Page link, at least compose the HTML in a printable form, without extraneous stuff.
3/19/01: John says: Sometimes if you look you can find older, smaller (1 - 2 GB)disks, that no one wants nowadays that are suitable for use as a dedicated backing store in an otherwise unused mount. If so you have an opportunity to improve performance ane benefit from a sunk cost.
3/19/01: Mike says: Thanks Ron for the tips. I learned some common sense ideas reguarding computer performance 15 years ago that still hold true. 1. Don't waste the CPU's time with unneeded tasks. 2. When transfering data between any two forms of storage with differing speeds, there needs to be intermediate storage installed when the speed difference is 3 to 10 times or greater. Whether or not these numbers are correct or not isn't as important as the reasoning behind it. Say for example you need to upgrade the memory in a server from 256MB to 1GB. You should consider the impact on not only pagefile size but disk troughput and L2 cache. You may not only need to double the L2 cache but also double the CPU speed or number of CPUs as well as install a caching disk controller. I have had customers ask things like whether or not they could replace their 2 aging file servers with 1 new higher performance server. Once all the technical issues were resolved, it became a data transfer issue. First thing to do is to design a replacement with the same performance as the 2 servers and then improve upon that system to actually improve server throughput. The good new system starting point would be doubled CPU speed, the amount of RAM should be greater than the sum of the amount in the old servers, hard disk storage would be doubled and thus a 4 times increase in hard disk troughput is needed, 2 NICs, tape drive capacity needs to be doubled as well as possibly needing 4 times the throughput, and so on... Running through changes like this will help prevent unwelcome surprises like not being able to complete a successful backup and defrag of the hard disk between 6pm and 7am. Now imagine taking a cluster of 32 servers and reducing it to 4 servers! Hint: Disk and tape throughput may need to be (32/4)^2=64 times faster!
3/20/01: Becky says: Jim -- Sorry about the graphics; it's a technical problem I thought was fixed! I'll work on it ASAP. -- Becky Nagel, Web Editor, CertCities.com
3/22/01: Mike says: So what's up with the updates on the screen shots and the "print this page" link. I sure would like to get this printed out sometime for my review.
First Page   Next Page   Last Page
Your comment about: “My 10 Favorite Tips for Increasing Windows 2000 Terminal Server Performance ”
Name: (optional)
Location: (optional)
E-mail Address: (optional)
Comment:
   

-- advertisement (story continued below) --

top