I am currently running Samba v2.0.7 on a Sun Ultra-2 dual cpu Solaris 8 server, serving a couple hundred PCs running NT4 and W2K, and about 160 users on four NT4 Terminal Servers with Citrix Metaframe. I have 135 printers configured on the Samba server, and several shared file systems. In order to make Samba work with the Terminal Servers, I used the registry entry: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters] "MultipleUsersOnConnection"=dword:00000000 However, even with this registry entry, printing to printers shared from the Samba server would cause the spool service on the Terminal Servers to hang up, and this problem could only be solved with a reboot of the Terminal Server. To fix this issue I put the "nt smb support = no" parameter in the smb.conf file. In my experience, the MultipleUsersOnConnection value of zero didn't work to force a separate connection for each user, only the "nt smb support = no" parameter would do this. The "nt smb support = no" creates problems of its own. First, AutoCAD on a Terminal Server has problems opening and saving files to Samba shares when this parameter is set. Several attempts must be made to get past errors about the file only being available read only. Another problem with using "nt smb support = no" involves W2K Terminal Server. Our Terminal Server users all have roaming profiles so we can use load balancing across the servers. However, roaming profiles will not work with W2K Terminal Server from a Samba share when "nt smb support = no" is set in the configuration. A message appears on logon saying the network profile cannot be loaded and a local version will be used instead. Without this parameter in the smb.conf file, the network profile loads on logon and saves on logoff properly. I recently upgraded to Samba 2.2.0 and tested whether the "nt smb support = no" was still required, since there have been a few NT4 WTSE service packs and Samba versions since I originally ran into problems. The problems came right back without the configuration parameter. I'm hoping the Samba team is aware of all these issues and that they will be addressed in the future. If anyone has input on workarounds for these issues that I haven't listed, I would be very interested in hearing them. Thank you. -- --------------------------------------------------------------------- Jay D. Anderson John Deere Davenport Works Jay@Deere.com P.O. Box 4198 Phone: 563.388.4268 Fax: 563.388.4159 Davenport, Iowa 52808 http://www.dw.deere.com/~hz01930 http://jayanderson.cjb.net
Hi Jay, Well, I don't understand why MultipleUsersOnConnection = 0 in the registry of an NT 4.0 Terminal server doesn't do it for you. I have tested this all the way from SP3 - SP6, and it has ALWAYS worked for me; With this value set to 0, and a reboot of TS after I set it, then every ts client that comes to samba thru that TS gets it's own separate instance of SMBD.... So you shouldn't give up on that parameter - it DOES work. Someone else on the list had a problem with it as well, and we went over and over it; he eventually reset it again, and rebooted, and this time it worked... What can I say? But for W2K Terminal Servers, Microsoft has removed the code that handles this registry entry - effectively, this registry entry does not exist for W2k, and they (M$) have so far been adament that there is no need for this registry 'hack' anymore on Wk2, because they have increased a number of limits that used to make this an issue for ts clients. And they have not been interested in addressing this for Samba. Sorry I don't have better news. Don -----Original Message----- From: Jay D. Anderson [mailto:jay.anderson@dw.deere.com] Sent: Monday, April 23, 2001 11:32 AM To: samba@lists.samba.org Subject: Samba and Terminal Server issues I am currently running Samba v2.0.7 on a Sun Ultra-2 dual cpu Solaris 8 server, serving a couple hundred PCs running NT4 and W2K, and about 160 users on four NT4 Terminal Servers with Citrix Metaframe. I have 135 printers configured on the Samba server, and several shared file systems. In order to make Samba work with the Terminal Servers, I used the registry entry: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters] "MultipleUsersOnConnection"=dword:00000000 However, even with this registry entry, printing to printers shared from the Samba server would cause the spool service on the Terminal Servers to hang up, and this problem could only be solved with a reboot of the Terminal Server. To fix this issue I put the "nt smb support = no" parameter in the smb.conf file. In my experience, the MultipleUsersOnConnection value of zero didn't work to force a separate connection for each user, only the "nt smb support = no" parameter would do this. The "nt smb support = no" creates problems of its own. First, AutoCAD on a Terminal Server has problems opening and saving files to Samba shares when this parameter is set. Several attempts must be made to get past errors about the file only being available read only. Another problem with using "nt smb support = no" involves W2K Terminal Server. Our Terminal Server users all have roaming profiles so we can use load balancing across the servers. However, roaming profiles will not work with W2K Terminal Server from a Samba share when "nt smb support = no" is set in the configuration. A message appears on logon saying the network profile cannot be loaded and a local version will be used instead. Without this parameter in the smb.conf file, the network profile loads on logon and saves on logoff properly. I recently upgraded to Samba 2.2.0 and tested whether the "nt smb support = no" was still required, since there have been a few NT4 WTSE service packs and Samba versions since I originally ran into problems. The problems came right back without the configuration parameter. I'm hoping the Samba team is aware of all these issues and that they will be addressed in the future. If anyone has input on workarounds for these issues that I haven't listed, I would be very interested in hearing them. Thank you. -- --------------------------------------------------------------------- Jay D. Anderson John Deere Davenport Works Jay@Deere.com P.O. Box 4198 Phone: 563.388.4268 Fax: 563.388.4159 Davenport, Iowa 52808 http://www.dw.deere.com/~hz01930 http://jayanderson.cjb.net -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
I saw this on the CitrixSE forum about Win2K SMB scalability...
(citrixse@yahoogroups.com)
Of course, they want you to get the fix thru "official" channels ;)
That you have to pay for :(
-Thor Johnson
www.acpthinclient.com
---
MaxMpxCt and MaxCmds Limits in Windows 2000
----------------------------------------------------------------------
----------
The information in this article applies to:
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
----------------------------------------------------------------------
----------
SYMPTOMS
Windows 2000-based clients that attempt multiple simultaneous long-
term requests against a file server may receive error code 56 ("The
network BIOS command limit has been reached") even if larger MaxCmds
or MaxMpxCt values have been specified in the registry. One example
of a long-term request is a client using the
FindFirstChangeNotification call to monitor a server for changes.
CAUSE
The maximum number of concurrent outstanding network requests between
a Server Message Block (SMB) client and server is determined when a
session between the client and server is negotiated. The maximum
value that a client supports should be determined by the
LanmanWorkstation MaxCmds parameter. The maximum value a server
supports is determined by the LanmanServer MaxMpxCt parameter. For a
given client and server pair, the limit should be the lower of these
two values.
A problem with the Windows 2000 redirector causes the MaxCmds
parameter to be ignored. Instead of using this parameter, the Windows
2000 redirector uses a default, hard-coded limit of 50. In addition,
the maximum permitted MaxMpxCt value in Windows 2000 is 125.
Therefore, Windows 2000-based clients cannot support more than 50
concurrent commands, whether the server is running Windows 2000 or an
earlier operating system (such as Microsoft Windows NT). Also,
Windows 2000-based servers cannot support more than 125 concurrent
commands per client, whether the clients are running Windows 2000 or
an earlier operating system such as Windows NT.
These limits are lower than they are in Windows NT 4.0. One reason
for lowering the limit is that clients that are running Microsoft
Windows 95 or Microsoft Windows 98 cannot function correctly when
larger values are negotiated.
RESOLUTION
A supported fix is now available from Microsoft, but it is only
intended to correct the problem described in this article and should
be applied only to systems experiencing this specific problem. This
fix may receive additional testing at a later time, to further ensure
product quality. Therefore, if you are not severely affected by this
problem, Microsoft recommends that you wait for the next Windows 2000
service pack that contains this fix.
To resolve this problem immediately, contact Microsoft Product
Support Services to obtain the fix. For a complete list of Microsoft
Product Support Services phone numbers and information about support
costs, please go to the following address on the World Wide Web:
http://support.microsoft.com/directory/overview.asp
NOTE: In special cases, charges that are normally incurred for
support calls may be canceled, if a Microsoft Support Professional
determines that a specific update will resolve your problem. Normal
support costs will apply to additional support questions and issues
that do not qualify for the specific update in question.
The English version of this fix should have the following file
attributes or later:
Date Time Version Size File name
-------------------------------------------------------
08/16/2000 03:03p 5.00.2195.2103 368,976 Mrxsmb.sys
08/16/2000 03:03p 5.00.2195.2103 234,352 Srv.sys
08/16/2000 03:04p 5.00.2195.2103 71,952 Srvsvc.dll
08/16/2000 03:05p 5.00.2195.2103 97,552 Wkssvc.dll
This hotfix raises the upper limit for the MaxCmds parameter to
65,535, and the upper limit for the MaxMpxCt parameter to 64,535. The
hotfix also includes a check to determine if clients are running
Windows 95 or Windows 98. If the Windows 2000-based server detects a
client that is running Windows 95 or Windows 98, it behaves as if the
MaxMpxCt value is no larger than 125. Smaller values are still
honored.
STATUS
Microsoft has confirmed this to be a problem in the Microsoft
products listed at the beginning of this article.
MORE INFORMATION
Although this hotfix increases the upper limit on the number of
concurrent commands that can be outstanding between a client and a
server, take care not to set these values too high. The more
outstanding connections that exist, the more memory resources will be
used by the server. If you set the values too high, the server could
run out of resources such as paged pool memory. This could result in
various kinds of system problems. In particular, you should not
increase the values substantially unless you know that there will be
a limited number of clients connected to the server at any given
time.
Note that you may also need to adjust other server parameters to
maintain optimum performance. For example, you may also need to
increase the MaxWorkItems value. This article does not make specific
recommendations as to which values or settings will be optimal for
your situation because of the number of variables that are involved.
For additional information about how to install Windows 2000 and
Windows 2000 hotfixes at the same time, click the article number
below to view the article in the Microsoft Knowledge Base:
Q249149 Installing Microsoft Windows 2000 and Windows 2000 Hotfixes
Additional query words: NETBIOS
Keywords : kbWin2000PreSP2Fix
Issue type : kbbug
Technology : kbwin2000AdvServ kbwin2000AdvServSearch kbwin2000S
kbwin2000Ssearch kbwin2000Search kbwin2000ProSearch kbwin2000Pro