Can Samba scale with NT_Terminal_Server? (was: Samba and WinTS/ WinDD)

[Charles N. Owens]

Thanks, Olaf, for your reply.  I'm giving this registry tweak a try. 
>From my read of the related Knowledge Bank articles, it seems _very_
applicable to our situation with some of the symptoms we've seen.

I've got a suggestion for your lingering temp files problem.  See below.

Thanks,

Charles

Olaf Dreyer wrote:
> 
> Hi,
> 
> On Fri, 17 Sep 1999, Charles N. Owens wrote:
> 
> > I'm wondering if the unique (?) way NT Terminal Server (NT_TS) connects
> > to Samba is a problem.  Samba seems to spawn a separate process per
> > connecting client.  With "normal" single-user stations (Win3.x, Win9x,
> > WinNT), this results in a process per user.  But with NT_TS (and other
> > related Citrix derivatives) we have many users coming from a single
> > client machine, all of which get handled by a _single_ Samba process
> > (one per NT_TS server box).  It is not unreasonable to expect that there
> > may then be 50 to 150 users being handled by a single Samba process
> > (depending on the horsepower of the NT_TS server).
> 
> You can set "nt smb support = no", but this will brake win 98 clients, or
> you can change one entry in WinTS-Registry after installing Service-Pack 4
> for WinTS. This is probably the better way, because Microsoft recommends
> setting this parameter for various problems (look at the knowledge base).
> 
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters\
> MultipleUsersOnConnection=0x000000
> 
> > So... any other NT_TS users doing the Samba thing with better luck than
> > I?
> 
> We have a WinTS/metaframe system running here. We use a Samba 2.0.5a
> Fileserver and a NT PDC.
> We also have a lot of WinCenter Servers using NIS to authenticate their
> users against Linux-Servers running Samba and NIS, we don't have the
> NIS-thing for WinTS/Metaframe :( . But we will use Samba as PDC as soon as
> possible. We have 40 to 60 users and the system is running stable. We had
> a lot of problems with "oplock breaks", but since we reorganized some part
> of the network they are gone.
> 
> > And, of course, I feel duty-bound to point out that were NT_TS and
> > Metaframe correctly, or at least more robustly implemented, they'd be
> > able to with-stand non-ideal behavior from Samba (assuming this is
> > occurring) without going belly-up.  Said another way, it's not Samba's
> > fault that there are some fundamental flaws in NT_TS that cause it to
> > crash when tickled.  Samba is only responsible for the tickling.
> 
> WinCenter ( NT 3.51 ) was more stable. We are missing the NIS-Thing, and
> the NCD Wincenter for WinTS/Metaframe ( its a Citrix product ) is known to
> be buggy. :(
> 
> One Point which always make problems are the clients. On the Metaframe
> Server there will be created a temp-directory for each connection. If this
> connections disconnects abnormal, eg the user get a blue screen on his
> workstation, this directory stays there. It won't be deleted even after a
> reboot of the WinTS. If someone later gets the same connection ID he will
> get this temporary directory assigned, the files probably owned by someone
> else...

We've fought with this.  The obvious solution was to have a script run
at boot time that simply deleted all subdirectories of %TEMP%.  This let
to my horrific discovery that, as far as I can tell, NT (or at least
WinTS) does not execute _any_ startup batch file when booting.  (What
was wrong with AUTOEXEC.BAT?)  Very bizarre.  Anyhow... our solution is
to use the AutoExNT service (from the Resource Kit) to do this.  It runs
at boot time the script %WINDIR%\SYSTEM32\autoexnt.bat .  Our script is
simply:

@echo .  System Startup
@echo .
@echo .  Now removing and recreating \TEMP
rmdir /s /q C:\TEMP
mkdir C:\TEMP

What I haven't yet determined is whether or not connection IDs ever get
reused during a given uptime of a system.  Do you know?  From what we've
seen, they start at zero and then increment until the next reboot....
but there _does_ have to be some roll-over value.  (We've never had
enough stability to have our systems up long enough to see it though.
;-)  If the maximum ID value is high enough, then between periodic
reboots (or crashes) and this startup script we should have the problem
licked.

A more thorough solution would be a regularly run Perl script that
parses the output of "query users" and then removes the any temp
directory that isn't associated with an existing session.  If we lick
our stability problems I'll probably write such a script at some
point...


> 
> Best Regards
> Olaf Dreyer

-- 
-------------------------------------------------------------------------
  Charles N. Owens                               Email: owensc at enc.edu
                                            http://www.enc.edu/~owensc
  Network & Systems Administrator
  Information Technology Services  "Outside of a dog, a book is a man's
  Eastern Nazarene College         best friend.  Inside of a dog it's 
                                   too dark to read." - Groucho Marx
-------------------------------------------------------------------------