• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 300
  • Last Modified:

Losing mappings/printers on Netware env. workstations

I have 3- 4.10 servers (one tree), 1- 3.12 and 1- 3.11 Novell server at one site.  There are about 350 users whose workstations are dropping mapping and capture commands several times throughout the day.  Workstations are either NT 4.0 or Win 3.1 with the latest Intranetware clients installed.  We've checked for viruses  (Mcafee) and only select groups (containers) are losing connectivity.  These users are connecting to the 4.10 servers.  No major changes have been made other than upgrading the virus s/w version and client s/w.  Problems appear to be intermittent between containers and users.  Servers are not maxed out with utilization nor are there are errors with the packets being received.
0
drodey
Asked:
drodey
  • 3
  • 2
1 Solution
 
tbarschCommented:
There is a confirmed bug with Client 2.20.  It seems to drop server connections at will.   I cannot find the TID on Novell's site, but the patch is called 95220I1.exe.  You can find it on support.novell.com (using file finder) or send me an e-mail and I'll send you the file.  The patch is small, only containing 6 files...

tbarsch@xlconnect.com
0
 
drodeyAuthor Commented:
I am unable to find any file on the Novell web site starting with "95" nor could I find the TID stating the bug in the intranetware client.  

In addition, the problem of losing connections also occurs on Dos/Win 3.1 machines which are using VLMs v 1.20.
0
 
paulnicCommented:
What patch level are the 4.10 servers running?

Any possibility of different infrastructure (hubs/switches/routers, etc.) between the clients and the 4.10 servers, possibly with a flakey device?

Have you seen if it happens when a client *doesn't* load the virus checker?

The file tbarsch mentioned is available as 95220i1.exe (that's an "eye" and a "one," and the search is case sensitive).  This patch fixes a bug with Win95, Word 97 and the 2.20 Intranetware client, which combo you may not have.  The TID is #2929518.


0
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
drodeyAuthor Commented:
Patch level is 410PT7 on the 4.10 servers.

I just upgraded the NIC drivers on all 4.10 servers and replaced the patch cords for the servers.

I've tried the workstation test without Mcafee but same results.  

All the users are not on the same hub.  They are scattered across 3 or 4 other hubs, of which other users are connecting without problems.  If anything, it might be the actual ports on the hubs.  BTW, the hubs connecting the network are 3COM (24 port mini-hubs), 3COM Lanplex 2500 and 2 old Cabletron MMAC hubs, all connected via dual FDDI rings.
0
 
paulnicCommented:
Has performance been normal except for the disconnects?  No slowdowns that might suggest heavy packet traffic, no extra-busy activity lights on certain hub ports?

Do any of the hubs have some level of packet and error statistics you can monitor per port?

If it keeps up you may want to set a Lanalyzer or other packet tracer/decoder to watch the IPX conversations when workstations disconnect.  There may even be some freeware utils available if you need a Lanalyzer or Sniffer inexpensively.

This assumes the disconnects recur more or less frequently.  

Depending on how many devices are translating FDDI to Ethernet, you might try temporarily bypassing one at a time.  If you can toss a 10BT NIC into one 4.1 server, and wire it directly to a hubful or two of users, and they stay solidly connected on the new segment, you may be able to suspect the (somewhat complex) FDDI-to-Enet bridging/translation.
0
 
drodeyAuthor Commented:
So far, I've determined that the watchdog packets are not returning to the server from the workstation.  To keep the workstation connections going, I've just increased the watchdog time to about 5 days.  Anybody logged in longer than that needs to reboot anyway.

It does appear that this is a faulty piece of hardware.  It could be one of the hubs or the fddi connection to the hub.  Rather than test each one, I'm going to leave it like this since we're going to redo our LAN in the upcoming months.

Thanks to all who helped!
0

Featured Post

Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now