Windows Forum

Ask something
Discussion Locked

Problem with NetBIOS Protocol

0 helpful
14 replies

by sgandenberger

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
I have been having a problem with users loosing the connection for their mapped network drives. The drives are mapped by a "NET USE" command run as part of a log in script. They are not dropping from the network because they still can e mail (EXCHANGE via RPC), access the UNIX server via the terminal emulation program using TCP/IP, and they can ping the file server. They just can't access the network drives through Explorer or Network Neighborhood. This evidence makes me believe the problem is in the Net BIOS protocol since what is failing is dependent on Net BIOS Name Resolution. We are not currently running WINS nor are there LMHOSTS files set up on the PDC (NT4.0 SP6) or the BDC (NT4.0 SP6). The problem seems to be isolated to just certain users. Does anyone one have an idea of what the problem might be? If implementing WINS or using LMHOSTS files seem to be the answer, can you recommend a good guide for implementing the solution?

14 replies

by Member 35772270

I had this problem too a while back, even when I used an Lmhosts file on my clients. I later activated a Wins server closer to my clients and havn't had a problem since.

by guy

I think that WINS would solve your problem.
Install on the server, then configure the TCP/IP tab for the WINS server.
Better Still use DHCP and give each client the WINS server automatically add a type 44 and type 46 (0x8).
If you do not like either of these then there is the trusty LMHOSTS files.
I have been wondering how the users log on if there is no NetBIOS to get the Domain controllers names? Perhaps they logon to Novell or Unix or even locally?

by calves

WINS is the easiest solution in the long run. Also, you want to look into possible Browser problems. Look for a Tools called Browstat.exe in your NT Utilities CD.
That will help you indentify who is your Master Browser. From there, you should (using the documentation from Technet, change the registry for NT and change the NIC configuration on 95/98 machines to disable unwanted computers to become master browsers.

That all I have for you!

Good Luck!

by mcessna

Try using an LMHOSTS file pointing to your domain controller. I have had similar problems with win9x clients, especially over a wan link or slow network link (building to building wireless). Here's an example of the lhhosts file
xxx.xxx.xxx.xxx%PDC/BDCservername% #PRE #DOM:%domainname%
Just drop the file into the c:\windows directory on win9x. I haven't had this problem with me NT workstations but if you do drop the lmhosts file into c:\winnt\system32\drivers\etc

Hope this helps.

by msullivan

Most of the previous posts seem to be on track. It sounds like a browse master issue. As the browse master (likely a client) re-boots, computers lose resolution.

You can use any of 3 methods to resolve the problem. WINS, LMHOST, or setting yournetbios node type to 'B'roadcast (if everyone is on the same network).

There are plenty of great articles at msdn.microsoft.com on WINS and LMHOST usage.

Hope this helps
Mike

by morgan_donohue

WINS is definately the best solution to any NetBios Name resolution problems. However whilst this will fix your problem, it does not resolve the possible current situation. As stated by somebody above, the problem most likely has to do with the Browse lists. The most commmon problem with these if running TCP/IP is incorrect subnet masks. A Browse master will be elected for each IP network, that means if you have incorrectly used a B mask on some machines in a C class network there will be multiple browse master elected. This will however produce constant election errors in the event logs.

Something else to consider is that whilst host name and NetBios name resolution are different animals, if your network crosses over a WAN then you should use them in combination to streamline the amount of replication traffic. If you want a copy of a proposal for the implementation that I have done, email me.

Ciao for Now

by morgan_donohue

The recommendation for page files are RAM + 12MB to allow for a dump if a BSD occurs. The only downside to this is the time taken for shutdowns. The reality of the situation is that if you consistantly have BSD's then you can quite easily up the pagefile size to capture the info for a dumpexam run, unless the machine is not bootable. I generally follow the Microsoft recommendation for the pagefile, with the only exception being to set the minimum and maximum settings the same to avoid fragmentation of the page file. You should also run performance monitor on the system as suggested above to check for memory leaks and maximum utilisation.

This discussion is closed to new replies.