Don't say WINS !!!

[wessss 0]

I recently installed Win 2000 Advanced server to be the domain controller of my network, I got this problem with my Win98 and 95 clients, that when ever a user try to logon to the domain it is a success the first time, after they logoff and try to log on again they all get the message (Invalid password, or logon to your sever has been denied!!) I checked it in MS knowledge base I found out it is a bug in Win95,98,ME ! I worked around this problem by letting PC's log on locally to access the workgroup, but now a new problem occured, opening the network nighbourhood takes FOREVER, and when it opens, pc's can access all the other pc's except the Win2k server! where is the problem?? how can i fix it? I got WINS installed on the server but i don't know if it is configured right.

 

WESSSSSSSSSSS

[clutch 1]

Are all the clients setup to use your WINS server in their respective TCP/IP properties?

[ryoko 0]

Also try this out.

http://www.ntcompatible.com/vb/showthread.php?threadid=17306

 

-Ry

[wessss 0]

Quote:

Are all the clients setup to use your WINS server in their respective TCP/IP properties?

yes, all the clients are configured to use WINS server, is there anyway to make sure that the WINS server is working correctly?? I will try the suggestions on the article that ryoko mentioned and I'll be back

[CyberGenX 0]

Try installing NetBeUI on those machines, it may help.

[clutch 1]

Installing NetBEUI is simply a patch job at best. I would strongly recommend not digging up that old protocol for use in a production (or any other) environment.

 

Now, what was the KB article you found that you used in the first place? I am interested to see what the original fix was that got you into this predicament.

[emagowan 0]

your clients can't access the win2k server because they are logging on locally, and not authenticating on the domain.

[ryoko 0]

You can log on locally if the password and user name on the workstation are the same as on the server. I had to do that at times to work around some software issues. There obviously are some major disadvantages to this method.

 

-Ry

[wessss 0]

The KB article is Q272594 it states that this is a problem in win95,98,ME. all the clients have the same username and password localy as they are for the domain controller. and I already installed netBEUI but nothing changed. By the way the problem is not that only the w2k server takes a long time to browse the network, it is that all the clients take about two minutes to open the network neighbourhood. it is making me nervouuuuuuuuuuuuuus. please help me guys!!

[wessss 0]

guys .. are you still there?

[CyberGenX 0]

hey clutch, i use netbeui in a production environment and it works A LOT faster than TCP/IP does, especially when you have machines that are on different IP ranges, so don't bag on an old protocol that still out performs TCP/IP on smaller LANs (not WANs)

[clutch 1]

Quote:

hey clutch, i use netbeui in a production environment and it works A LOT faster than TCP/IP does, especially when you have machines that are on different IP ranges, so don't bag on an old protocol that still out performs TCP/IP on smaller LANs (not WANs)

NetBEUI used to be the protocol of choice for smaller networks because of its lower overhead and faster throughput. However, have you taken a good look at the collisions on an average network using it? How about the broadcast storms? Also, when comparing the protocols, are you comparing the two on the same OS (such as Win2K) or is this a mixed environment (such as Win95, 98, NT4, 2K)? If you are using older Win9X boxes, then those are the ones that will see the performance benefit (unless the aforementioned issues catch up depending on the network size as NetBEUI does not scale well), but if you are using a modern network that relies on network-installed and client/server applications, then you will not see a performance benefit and in reality be hurting the performance of the network.

@wessss,
Did you try calling MS Support and just getting the proper fix for the clients? They are pretty easy to deal with; all you have to do is tell them the Q number along with what the issues were that brought you to that conclusion, and they will email the fix to you (or a link to get it). You don't have to pay for it either, so it would definately be worth your time to check it out. Point to this article as it is the one that supercedes your earlier Q number.

Also, while your clients may be pointing to your WINS server's IP, are your servers doing the same? They will need to (including the WINS box itself) so the WINS db will properly cache all the IPs and machine roles to each machine name on the network.

Now, if either of those don't work for you and you still have NetBEUI installed, then make sure you have NetBEUI higher up in the binding order than TCP/IP for your NICs. If not, your systems will have to wait for your TCP/IP stack to timeout on its session(s) before moving its way to NetBEUI.

[CyberGenX 0]

I do agree NetBEUI is old and not good for larger networks, but you can avoid the collisions by using a SWITCH. We tested throughput between the 2 protos and NetBEUI was faster.

[clutch 1]

Quote:

I do agree NetBEUI is old and not good for larger networks, but you can avoid the collisions by using a SWITCH. We tested throughput between the 2 protos and NetBEUI was faster.

Well, there are many SWITCHES that aren't OPTIMIZED for use with NetBEUI, especially ones in the price segment that a small office would use (plus many small networks still use HUBS anyway). So, why not stop using the "Band-Aid" of Windows-compatible protocols and just use a current one that all the OSs are supporting? It's bad enough to still be on a network that needs NetBIOS for something, but you can at least let that ride on the back of TCP/IP rather than install ANOTHER protocol that MS wants as dead as everybody else has. They have gone out of their way to make a little bit harder to install on their newest OS, and I would imagine that canning it altogether in their next release is a completely reasonable prediction. At some point, you will HAVE to move forward in protocols since almost nothing supports NetBEUI or IPX/SPX (NWLink) anyway. Print servers, WAPs, managed SWITCHES and HUBS, etc. all have support for TCP/IP, but none come screaming to mind that support NetBEUI. And if you have one of these gizmos (or Heaven forbid you want to get ONLINE to the Internet) you will now have 2 protocols to babysit; NetBEUI and TCP/IP. All-in-all, not such a hot choice.

Now, as I asked earlier, what OSs were you testing in throughput? Was it Win2K/XP or 9X-based OSs? The more modern ones have vastly improved performance in TCP/IP, and I am not inclined to believe that NetBEUI is that much faster (if at all) than these newer implementations. What did your test entail? Was it simply copying files over, or were there many networked applications running in the background while you were checking network/CPU utilization? Was it a single large file and/or many small files? What were the results?

[CyberGenX 0]

why did i even post anything in this board, YOU WIN, fine what ever you say. My statement is this; NetBEUI works great on my networks, especially the ones that have static IPs in completly dif ranges as well as dif netmasks. TCP/IP is far better, yes, but in some cases, like mine, NetBEUI is fine for file transfers and tcp can handle the rest. Yes i agree it should only be tcp/ip until you can solve my problem, it's both protos

[clutch 1]

Quote:

Yes i agree it should only be tcp/ip until you can solve my problem, it's both protos

What problem is that?

[Hornet303 0]

Im not sure I understand why you need to use WINS. Do Win 95/98 clients not support DNS? Its been a while since Ive used one, but Im pretty sure they do. Anyway, try a few different tests such as trying to map a network share via dos prompt. try pinging the server with its nebios name, as well as its dns name. It sounds like its taking a while for the authentication to initiate when you log in via the network neighborhood. Sometimes its hard to force it. Also, when you have local users on the WIN 95/98 machine, as well as on the DOMAIN, authentication becomes tricky. If you are using the same usernames, the passwords MUST match. This is what happens.

 

user a logs into a local computer. using a USERNAME and a PASSWORD

now, when that user goes to brows the domain, the domain asks who is wanting access. So, the 95/98 client uses the USERNAME and PASSWORD the user typed in to log into the local computer, and it goes to match it against the domain list. Unless those accounts match exactly, you'll be forced to authenticate to the domain. It becomes tricky and does take a long time to initiate. Once the users log in to a share or whatever, does it work fast afterwords?

 

Anyway, Im suprised that you cant log into the domain more than once using a 9x client. that seems rediculous, and should be fixed by now Id imagine. Anyway, I try to not use WINS, use DNS instead. Unless you guys have reasons why youd want to use WINS, Id like to hear.. as Im not very fond of WINS.

 

jeff

[clutch 1]

When logging onto a domain/workgroup resource, you will be using NetBIOS traffic in most cases (unless using AD with DDNS and DS clients). WINS handles this far more efficiently than simply broadcasting using NetBIOS over TCP/IP, and trying to get reliable information from the local browse master can be problematic on even the smallest of networks, especially when mixing 9x with NT systems. WINS allows for the clients to register their respective names, IPs, and resource status along with other information and provides a central source for name and resource resolution in return (what printers are available? who is the PDC?). DNS does not provide for any of this, (DDNS does, but that's a function of AD which isn't the issue here) as it is static environment and the names have to be mapped manually, and you can't map the resource status of the unit (PDC? Printer?) in that database either. As a matter of fact, one of the most stable NT-based name resolution systems is a combination of both DNS (NT4) and WINS, where DNS can perform reverse lookups on names that it can't find in its own DB. In that case, any clients using DHCP can be found using a FQDN on the LAN. This was the first form of DDNS, if you will.

[wessss 0]

here is another thing i discovered, when the w2k server is disconnected from the network, the clients browse the network so fast as if there has never been a problem!!! is it a master browser problem or authintication problem I am facing here????

[clutch 1]

Do the logs have anything to say about this? Have you tried not having the clients use WINS at all to see if that would speed up your browsing? You could have a corrupt WINS database if browsing is faster when the WINS-hosting server is offline.

[Intlharvester 0]

A classic problem with Windows networking is that the incorrect machine becomes the Browse Master due to whatever (mostly bugs in Win 9x).

 

This is due to the fact that Name Resolution uses a different mechanism (WINS/DNS) than does the Network Neighborhood (Master Browser elections). In theory the correct machine - usually the WINS or DC box - should win all of the elections. In practice it doesn't always happen.

 

The resource kit has a tool called browmon.exe which will tell you who thinks they are the master browser on a network. My guess is that there's some sort of conflict going on between the DC and various Win9x boxes on your net leading to a "election storm".

 

If it looks to be the case, the solution to use policy files to disable the 9x boxes ability to participate in browser elections.

 

As for the name resolution issues - could you have 2 WINS servers on the same network perhaps? Other than that I'm stumped.

 

The longterm solution might be to go to active directory and leave all of WINS/Browse stuff behind.

[clutch 1]

Unfortunately, you can still get odd browse master elections forced even in AD. Locking the clients down to keep them from taking part in elections is a good idea.

[ryoko 0]

Unless I'm mistaken, only win95 had the browse master problem. I believe it was fixed in 98. You could try only disabling it on the 95 machines first to save time.

 

-RY

[clutch 1]

It wasn't, as I have seen Win98/SE clients do it, and even some Win2K/XP clients as well if they are confused enough.

[wessss 0]

the WINS server is working perfectly, I checked the data base one by one and all the entries there are correct. I disconnected the W95 clients but nothing changed! what bothers me that the clients eventually see the network but after 1 - 2 minutes of searching! any new ideas ????????