To begin, it is important to understand the SMB 1.0 limitation that has been present since we first started implementing Terminal Server deployments back in the good old days of NT and MetaFrame. There have already been a lot of good SMB tuning articles out there that discuss this in detail, so I will not go into too much of an extensive discussion here, but I will summarize.

When a client computer using SMB 1.0 (NT 4.0, 2000, XP, 2003, etc…) attempts to connect to a Windows file server, it will query the file server and ask how many concurrent network (SMB) commands it can have submitted and open simultaneously. The file server will respond with a number and the network redirector on the client computer will limit itself to the number provided by the file server. The number that the file server provides is controlled by the SMB value for Max Mpx Count, which is set by the following registry entry on Windows file servers:

“HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\MaxMpxCt”

By default, this value does not exist on a Windows Server. If it does not exist, the Operating System uses a default value of 50.

This means that an individual client computer will not be able to have more than 50 simultaneous SMB commands to the file server. An SMB command can be anything from a directory listing, file creation, deletion, ACL manipulation, etc… basically, any kind of file or directory access.

The 50 command limitation quickly becomes a problem on a Terminal Server because there is only one redirector that is shared by all users on the server. In a typical Terminal Server environment, often users will all connect to the same file server for home directories, roaming profiles and redirected folders. This means that each user could easily be generating multiple SMB commands to a single file server. Once you start loading 50+ users on the server, you can easily have more than 50 outstanding SMB commands that need to be serviced, especially if folder redirection is being used. Since only 50 get serviced at one time, the rest of the commands begin to queue up and wait for servicing. This can cause poor performance or even application failures as applications make file requests that time out waiting to be serviced.

A workstation or SMB Client may make a request to have more than 50 SMB commands simultaneously open to a file server; however, if the file server has not been tuned, the client will not use more than the Max Mpx Count returned by the file server. The maximum number of simultaneous requests that a workstation will attempt to use is controlled by the Maximum Commands SMB setting defined by the following registry entry on the client:

“HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\MaxCmds”

By default this value is also 50 if it is not defined. So to properly tune an environment for maximum density of Terminal Server/XenApp users, you must add the MaxCmds key to all Terminal Serves and the MaxMpxCt key to all file servers. We have typically recommended increasing these entries to a decimal value of 2048.

Microsoft has a good article (324446) that has been around since Windows 2000 that discusses this issue and recommends the follow registry keys that should be implemented on file servers being accessed by Terminal Servers:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\MaxMpxCt
“MaxWorkItems”=dword:00002000 (decimal 8192)
“MaxMpxCt”=dword:00000800 (decimal 2048)
“MaxRawWorkItems”=dword:00000200 (decimal 512)
“MaxFreeConnections”=dword:00000064 (decimal 100)
“MinFreeConnections”=dword:00000020 (decimal 32)

Click here to read the full article