Windows Forum

Ask something
Discussion Locked

WINS Help.

0 helpful
5 replies

by g-spin

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Alright, I got burned on this so I really need some help here. On my network we have two sites, A and B, with site A being the primary (has most of the NT 4 servers) and B being secondary (has one NT 4 server). They are connected via a routed fibre line. We had WINS set up on Site A only. What would happen is if the WINS went down, we could no longer see site B via Neighbourhood. (We would also lose drive mappings to it) We could still ping and get to them via their IPs however. So I figured the optimal solution would be to set up WINS on site B's server. I set up both machines (on A and B) with a WINS server and set each of them to be a "push" and "pull" partner. I then changed DHCP to reflect the new WINS servers. The next day when the IP's were pulled from DHCP (one on both sites) 3/4 of site B lost all their drive mappings and connectivity to site A and were shut down for half a day before we figured out it was WINS. I configured them back to the original WINS on site A only, and renewed their IPs to finally get them working. When I tried replicating the WINS it looked like it replicated fine. Also site A seemed to work perfectly fine. What went wrong??

BTW, The DHCP scopes, if you need them, are 216.*.*.* for A and 172.*.*.* for B. Same subnet mask, and the gateways are *.*.*.1. Any ideas? Let me know if you need more info.

5 replies

by curlergirl

WINS replication is a tricky thing - and I'm not what I would call an "expert" on this, having had my own problems in the past. However, I think what happened was caused by the fact that you set both of your WINS servers up as both "push" and "pull". You should have set up your old WINS server as both "push" and "pull" and your new WINS server as "pull" only initially. Also, WINS replication takes some time - it's not immediate, esp. with a new WINS server - so that probably contributed to the problems. So, probably the new WINS server at Site B did not have the records it needed to provide name resolution for the Site B workstations as quickly as you expected it to. At this point, for the purposes of network traffic, you might want totry setting your Site B workstations back to using their own WINS server, if you've checked and made sure that the replication is really working OK in both directions. Hope this helps!

by g-spin

Thanks, but unfortunately I wasn't even using the old WINS database because I thought I had pushed it to the new WINS on site A already. The thing is, if I view the databases on the systems the old one had mappings all over, the new WINS onA has all of site A and a little of site B mapped, and site B has ONLY site B mappings. Any ideas about that?

Oh and site A was/is working fine without using the old WINS.

by joseph moore

I agree, WINS can drive you insane!
I know this sounds like doing the same thing twice, but this really works: modify the LMHOSTS file on the SiteB server with the IP address and machine name of the PDC on SiteA.
For example, say the PDC in SiteAis SITEAPDC and has an IP of 10.1.1.1 and your domain is SITEADOMAIN.
You would put the following in the LMHOSTS file on the SiteB machine you are having all of these problems with:

10.1.1.1 SITEAPDC #PRE #DOM:SITEADOMAIN

Do that, then open a Command Prompt on the SiteB machine and type in:

nbtstat -R

That will force the SiteB server to purge its Netbios over TCP/IP name cache and read from the LMHOSTS file.

And that should take care of it. If you want to turn WINS back onSiteB server, you should be able to do so with no problem.

Name resolution over remote connections (expecially across different IP segments) is tough. LMHOSTS are the only reliable way (in my opinion) that work.

Here is a Technet article on the LMHOSTS file and its syntax:
How to Write an LMHOSTS File for Domain Validation and Other Name Resolution Issues (Q180094)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q180094
(please remove any spaces)

good luck

by shanghai sam

THANKS! That looks like it's going to do it. It appears that before I got here, somebody sent an lmhosts file to most of the clients/servers with information that was way out of date. (For instance, the PDC fix you mentioned above was already set to a different PDC that no longer existed.) *Smacks head* Live and learn I guess... I'm not going to jump into quick fixes without fulling testing them next time. Thanks again!

This discussion is closed to new replies.