Windows Terminal server + Client 4.81 (IPX) hangs during login
Philippe Requilé
directory).
Our microsoft network in on TCP/IP. Our Novell 4.11 server talks IPX.
When I install the novell client 4.81 or 4.83 (custom install/IPX only), the
server hangs during login (after the novell login screen).
Even when I login with 'Workstation only', the server hangs during login.
I can login when I disconnect the network cable and choose 'Workstation
only'. Then I can connect the cable and login.
When I uninstall the Novell client, I can login again to our microsoft
network (TCP/IP).
Reinstallation of the novell client isn't a solution.
I made a log during startup: in the logfile ntbtlog.txt, I see 2 drivers are
loaded when the cable is disconnected (when the server doesn't hang), but
those 2 drivers aren't loaded when the login fails and the server hangs. The
2 extra lines are:
Loaded driver \SystemRoot\System32\Drivers\TDTCP.SYS
Loaded driver \SystemRoot\System32\Drivers\RDPWD.SYS
I don't find any similar problem in the newsgroups.
Can someone help me, or do I have to migrate our novell server to Win2000?
Alan Adams
connectivity to the NetWare 4.11 server by installing the Microsoft
Client for NetWare Networks.
If this is the first time IPX has needed to be configured on the
Windows 2000 Server perhaps also assign a legitimate internal IPX
network number (yes, on the Windows 2000 Server's NWLINK properties)
and nail down the frame type to that being used by the 4.11 server for
IPX.
Before re-installing the Novell client, be sure and remove the
Microsoft Client for NetWare Networks. The installation of the Novell
client does attempt to remove it, but it reports being successfully
removed in cases where it has not. To manually removing the Microsoft
Client for NetWare Networks prior to installation is a good idea.
Alan Adams, MCNE
Philippe Requilé
> connectivity to the NetWare 4.11 server by installing the Microsoft
> Client for NetWare Networks.
could log in to novell & microsoft.
> If this is the first time IPX has needed to be configured on the
> Windows 2000 Server perhaps also assign a legitimate internal IPX
> network number and nail down the frame type to that being used by the 4.11
> server for IPX.
I already tried this.
I removed IPX, reinstalled the Novell client 4.80 with IP-only (of course
then I Can't get to novell), but then the server doesn't hang while logging
in.
I removed client 4.80 and reinstalled with IPX+IP. Hangs.
I removed client 4.80 and reinstalled with IPX only. Hangs.
I tried to login without novell login script disabled. Hangs.
When I enter a wrong user name or wrong password, (both for novell and
microsoft: admin / administrator), the logon screen complains the
username/password is wrong. So there is connection with NDS and active
directory.
When I enter the right passwords, the novell login screen disappears and I
can move the mouse cursor, I can use shift lock/numlock, the led on the
harddisk flashes now and then. There is no repsonse on ctrl+alt+del.
I disconnected the network cable, logged in with workstation only,
reconnected the cable, logged out (not restart op server!) and logged in
again. Then I can login to Novell + microsoft.
So the server hangs only when the cable is connected while starting up. When
I can log in once without network connection, then I can log in normally the
next time.
Alan Adams
login, but not the second time I login" issues I've run into before
have traced back to the Workstation Manager component of the Novell
client trying to do it's thing in an environment that wasn't as
expected. (In this case, perhaps something such as being able to walk
to [Root] via IPX.) That could potentially also fit with the
Microsoft Client for NetWare Networks working (since it does not have
such components).
So another question/idea would be to remove the Novell client and then
re-install via "Custom" and don't leave the "Workstation Manager" or
"NAL Service" items selected, at least as a test for whether it
affects the issue.
A more definitive approach could be to get a LAN trace of the network
traffic on and off of this workstation during initial boot-up & login.
I agree that it sounds like you're making your NDS connection over IPX
okay, and then there is something else occurring "post-login" where
the workstation is timing out or hanging indefinitely.
Alan Adams, MCNE
Philippe Requilé
> So another question/idea would be to remove the Novell client and then
> re-install via "Custom" and don't leave the "Workstation Manager" or
> "NAL Service" items selected, at least as a test for whether it
> affects the issue.
I'm afraid I already tried that. I unchecked 'workstation manager', 'Novell
distributed print services', and 'ZENworks application launcher'.
I tried client 4.80 ,4.81 and 4.83.
> A more definitive approach could be to get a LAN trace of the network
> traffic on and off of this workstation during initial boot-up & login.
Never done that before. Where can I find more information on this topic?
Isn't there some other option (enable some logging in the netware client,
...)
And what about the fact that 2 drivers files aren't loaded (log in
ntbtlog.txt)
Loaded driver \SystemRoot\System32\Drivers\TDTCP.SYS
Loaded driver \SystemRoot\System32\Drivers\RDPWD.SYS
Philippe
Alan Adams
> this topic?
Getting the LAN trace itself isn't usually too difficult; having
someone with experience to read it is what saves lives (and $$$) in IS
departments. If you're coming at this cold, it might be best to call
someone like Novell support or a consultant you like and have them
help you take and read the LAN trace.
If you would like to get exposure to the tools, www.ethereal.com has
an open-source packet capture utility that receives a lot of use.
"Sniffer", "NetMon" and "LANalyzer" (ick) are the widely-known
commercial and vendor-specific products. You can feel your way
through actually getting the trace with just the documentation;
interpreting what the trace says is where you have to have done it for
a while to start making good sense of it.
> Isn't there some other option (enable some logging in the
> netware client, ...
If we already knew where the problem was, maybe; but even then you
might have to get some sort of debug component from Novell like you do
with getting logs out of certain parts of Windows.
> And what about the fact that 2 drivers files aren't loaded
> (log in ntbtlog.txt)
>
> Loaded driver \SystemRoot\System32\Drivers\TDTCP.SYS
> Loaded driver \SystemRoot\System32\Drivers\RDPWD.SYS
The latter appears to be the RDP protocol driver (i.e. terminal
services app. protocol), and TDTCP appears to be a driver specific to
using RDP over TCP. Both of which it would seem should still be in
use regardless of what client you have installed, and wouldn't seem
like something to affect login at the console.
You certainly were already on top of anything I considered a likely
suspect; I can offer at this point that I do use the Novell client
(4.81 & 4.83) on 2000 SP2 terminal servers including Active Directory
controllers; all my NetWare connections are over IP though, if the IPX
factor is actually key here.
I still think a LAN trace could help you try and pinpoint whether this
is related to something specific that the Novell client tries to do
that the Microsoft NetWare client does differently or not at all;
that's just me coming from the presumption that this fundamentally
works and is failing just due to some additional non-obvious factor in
this environment. At minimum it should show how far the login process
gets before the hang-up occurs, even if it's not because of something
that was visible out on the wire.
Alan Adams, MCNE
Philippe Requilé
> an open-source packet capture utility that receives a lot of use.
> "Sniffer", "NetMon" and "LANalyzer" (ick) are the widely-known
> commercial and vendor-specific products. You can feel your way
> through actually getting the trace with just the documentation;
> interpreting what the trace says is where you have to have done it for
> a while to start making good sense of it.
> You certainly were already on top of anything I considered a likely
> suspect; I can offer at this point that I do use the Novell client
> (4.81 & 4.83) on 2000 SP2 terminal servers including Active Directory
> controllers; all my NetWare connections are over IP though, if the IPX
> factor is actually key here.
Our Terminal server (win2000) worked about 1 year with novell client 4.80.
At that time out main microsoft server was NT4.
When we migrated to active directory, everything went wrong and we had to
reinstall the Terminal server.
While installing the novell client 4.83, the server crashed. I changed
NWGINA.DLL with MSGINA.DLL, and we could login again.
After a reinstallation of the novell client (4.83), we could login both on
microsoft and novell. So it worked for about a week. But I couldn't log in
to our main novell server, only a second novell server.
Then 1 week later we had to reboot the terminal server and that was the
beginning of the login problem.
Nobody seems to have installed new software on the terminal server during
that week.
Philippe Requilé
> an open-source packet capture utility that receives a lot of use.
> "Sniffer", "NetMon" and "LANalyzer" (ick) are the widely-known
> commercial and vendor-specific products. You can feel your way
> through actually getting the trace with just the documentation;
> interpreting what the trace says is where you have to have done it for
> a while to start making good sense of it.
> You certainly were already on top of anything I considered a likely
> suspect; I can offer at this point that I do use the Novell client
> (4.81 & 4.83) on 2000 SP2 terminal servers including Active Directory
> controllers; all my NetWare connections are over IP though, if the IPX
> factor is actually key here.
Our Terminal server (win2000) worked about 1 year with novell client 4.80.
Alan Adams
> to our main novell server, only a second novell server.
> Then 1 week later we had to reboot the terminal server
> and that was the beginning of the login problem.
That certainly wouldn't rule out that the issue being encountered is
actually external to the 2000 server itself (i.e. is related to the
network itself or based on information that is being read from NDS
that the Microsoft client's doesn't deal with).
Does only the terminal server have this issue? i.e. Do you have other
Windows 2000 Professional SP2 workstations installed with 4.83
IPX-only that can login successfully from the same proximity on the
network? If other computers also have similar issues then perhaps
that would put weight behind the idea that the issue is actually
coming from the network and/or NDS; if the other workstations are fine
then that could point back towards being still something
configuration-specific to the terminal server or fallout still present
from crashing during configuration.
Just for kicks I restored my 2000 SP2 AD controller image on a testbed
machine, added terminal services and installed the 4.83 client
IPX-only (after manually removing the Microsoft Client for NetWare
Networks). Was able to login via IPX to our NetWare 5.1 servers both
from the console and from a terminal session. I just wanted to see
that to be sure there wasn't something fundamental, but given that
even you had seen this work previously before starting to fail I guess
that was kind of already answered.
Alan Adams, MCNE
Philippe Requilé
> Windows 2000 Professional SP2 workstations installed with 4.83
> IPX-only that can login successfully from the same proximity on the
> network?
run client version 4.80 or 4.81.
It could be something terminal server-related of course.
> Just for kicks I restored my 2000 SP2 AD controller image on a testbed
> machine, added terminal services and installed the 4.83 client
> IPX-only (after manually removing the Microsoft Client for NetWare
> Networks). Was able to login via IPX to our NetWare 5.1 servers both
> from the console and from a terminal session. I just wanted to see
> that to be sure there wasn't something fundamental, but given that
> even you had seen this work previously before starting to fail I guess
> that was kind of already answered.
Thanks Alan for trying.
I also tried to plug the server into a switch where another Win2000 machine
(workstation) doesn't have problems.
There should be a conflict with some other installed software.
I asked other people which new software was installed during the last weeks.
Nobody answered yet.
I think I'll try to uninstall the TS-services, and try again. Then reinstall
SP2 (perhaps some software has overwritten newer DLL's).
Alan Adams
disabled) could be related to non-NetWare user or group policy scripts
executing.
Perhaps look at what's running from the local security policy on the
terminal server and/or any effective group policies in AD that might
be having issue when executing on the terminal server with the Novell
client present.
That you can get by it by unplugging the network cable suggests that
you could see something being attempted on the wire in a LAN trace;
even if you _can_ see it, whether it would create obvious suspects or
not would be the next question.
Alan Adams, MCNE
Philippe Requilé
Than I know if there is something wrong with profiles (I had a similar
problem at home: could log on as administrator, not as 'Philippe')
I suppose this isn't the solution because when no IPX is installed, I can
log in (even with novell client installed).
Another question. Novell 4.11 supports TCP/IP. So I tried to install TCP/IP
on the novell server.
I can ping to the server, but the client can't connect to the server with
TCP/IP.
I read somewhere that the server only talks TCP/IP to connect to the
internet, not to the clients.
Can you confirm that a client can't connect with TCP/IP to a Novell 4.11?
Alan Adams
things like GroupWise, NEPS, Unix Print Services for NetWare -- any of
the .NLM-based applications that know how to use IP.
What NetWare 4.11 lacks that NetWare 5.x and later have is NCPIP.NLM.
i.e. A version of the NCP Server engine that knows how to use IP as a
transport protocol. So no, you cannot create an NCP connection to the
NetWare 4.11 server using IP even though you have a working TCPIP.NLM
installation present.
NetWare 4.11 supported "NetWare/IP" and more recently "IPX
Compatibility Mode (CMD)", both of which are next-generation versions
of the old IPTUNNEL.LAN that tunneled whole IPX packets across an
IP-only connection. So technically you could connect to a NetWare
4.11 server "using IP" with those methods, but you haven't eliminated
the use of IPX (there has to be an IPX stack still at both ends for
the tunneled frames to pass between) and you've made your client and
server configuration more complex to boot. Still, folks who need
access to a NetWare 4.x server from across an IP-only WAN employ these
approaches all the time. But it's not the same as logging in to a
NetWare 6.x/5.x server using IP.
Alan Adams, MCNE
Philippe Requilé
I installed the NT-client for Netware on our terminal server.
It isn't a problem to stay in bindery mode for most applications.
And the server runs much faster.
Perhaps within a year or so when we have to reinstall the server, we'll try
again.