Re: WINS/nbtstat query

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Steve,

That is great - thanks for the advice. I shall do as you suggest....


Ben.


"Steve Duff [MVP]" <ergodic@xxxxxxxxxxxxxxxxxxx> wrote in message
news:uihp#k8iFHA.2904@xxxxxxxxxxxxxxxxxxxxxxx
> The nbtstat tells us that DNS is resolving fine. And these are h-node
machines. So I do not know where the (presumed) WINS queries
> are originating from. I would probably ignore that for now. I'd be
interested to know if they still happen if no WINS server is
> configured on the client.
>
> By "tear down" I mean reduce your network to a single WINS database, and
then rebuild the links and replication the way you want
> them. You do not have to remove the WINS service from the other servers,
but you do have to take out replication links, client
> references, and the WINS databases before you put them back in. Whether
this is simpler than debugging one at a time depends on the
> size and complexity of your network.
>
> Steve Duff, MCSE, MVP
> Ergodic Systems, Inc.
>
> "Ben" <ben.flynn@xxxxxxxxxxxx> wrote in message
news:42dbe275$0$149$7b0f0fd3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Oh forgot to mention the machines that send the FQDN to wins... when you
do
> > an nslookup on it it resolves it fine via DNS ?!?!
> >
> >
> >
> > "the_player12345" <ben.flynn@xxxxxxxxxxxx> wrote in message
> > news:1121684875.135717.84190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >> Hi,
> >>
> >> Thanks for the response.
> >>
> >> The machines that are affected are h-nodes (0x8)
> >>
> >> The following is the nbtstat -r from one
> >>
> >>
> >> NetBIOS Names Resolution and Registration Statistics
> >> ----------------------------------------------------
> >>
> >> Resolved By Broadcast = 0
> >> Resolved By Name Server = 8
> >>
> >> Registered By Broadcast = 0
> >> Registered By Name Server = 3
> >>
> >>
> >> I agree with what you say about sorting the replication issues first.
> >> I'm going to do as you say - when you say tear down the satellites, do
> >> you mean just drop the replication links and re-establish or completely
> >> uninstall. If the latter should I back the database up before or just
> >> let clients re-register ?
> >>
> >> Thanks for the help
> >>
> >>
> >> Ben
> >>
> >>
> >> Steve Duff [MVP] wrote:
> >> > 1) What does nbtstat -r show on the workstations affected by your
second
> > issue?
> >> > 2) What resolution mechanism are you passing out in DHCP (b-node,
> > h-node, etc.)?
> >> >
> >> > I think if you find and fix your second symptom the first may go away
> > with it.
> >> >
> >> > You need to resolve any WINS config or replication problems before
you
> > try and deal with the finer problems or you can lose your
> >> > mind since the namespace views can be substantially different in
> > different places. Depending on the size of your network it may be
> >> > best to tear down all WINS servers except the hub, point everyone
there,
> > and then rebuild the satellites one at a time.
> >> >
> >> > Steve Duff, MCSE, MVP
> >> > Ergodic Systems, Inc.
> >> >
> >> > "Ben" <ben.flynn@xxxxxxxxxxxx> wrote in message
> > news:42d92074$0$146$7b0f0fd3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >> > > Hi there,
> >> > >
> >> > > I'm currently trying resolve some wins replication problems. I
think
> > I have
> >> > > tracked a lot of it down to the fact that a lot the WINS servers
are
> > not
> >> > > pointing to themselves, there isn't a proper hub/spoke topology
> > amongst
> >> > > other things.
> >> > >
> >> > > However, does anyone know why I may be experiencing either of the
two
> > issues
> >> > > below :
> >> > >
> >> > > - on running an nbtstat -c on the (supposedly) hub server I get a
lot
> > of
> >> > > entires that have an IP address in both the name and address field
> > i.e.
> >> > >
> >> > > Name Type Host Address Life [sec]
> >> > > ---------------------------------------------------------
> >> > > 10.14.101.40 <20> UNIQUE 10.14.101.40 602
> >> > > 10.132.103.93 <20> UNIQUE 10.132.103.93 600
> >> > > 10.10.106.114 <20> UNIQUE 10.10.106.114 600
> >> > >
> >> > > - Also on putting a sniffer on the network I am getting quite a few
> > clients
> >> > > that are send UDP requests on port 137 to the wins serevr for FQDNs
> > (which
> >> > > are then aboviously failing) despite these clients having DNS
servers
> >> > > defined and the appropriate DNS entries being present.
> >> > >
> >> > >
> >> > > Any help much appreciated
> >> > >
> >> > >
> >> > > Ben.
> >> > >
> >> > >
> >> > >
> >> > >
> >>
> >
> >
>
>


.

Relevant Pages

  • Re: Database Issues
    ... When you repromote the dns should come back with the ... Database: d:\new\ntds.dit ... and delete the old log files: ... Event Source: NTDS Replication ...
    (microsoft.public.win2000.active_directory)
  • Re: AD and DNS
    ... is replicated to all DC's along with AD database during AD replication. ... only the DCs which are configured as DNS will act as DNS servers and reply ... and 2.in all client mention the additionl DNS server ip ...
    (microsoft.public.win2000.active_directory)
  • Re: SBS 2003 and Replication Errors with Remote DC
    ... alpha server as soon as you can to get things going. ... A simple DNS replication test is to create a host record in the SBS server ... Domain Controller Diagnosis ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS 2003 and Replication Errors with Remote DC
    ... I did make the changes that you suggested on the DNS of my alpha server and rebooted. ... I did run the simple DNS test that you suggested by adding a host record to my SBS server. ... A simple DNS replication test is to create a host record in the SBS server and wait till it shows up in the remote server. ...
    (microsoft.public.windows.server.sbs)
  • RE: DNS/AD/RPC issues (x posted to .dns)
    ... You are right that an error like this is usually caused by a DNS problem. ... subnet - although replication is not functioning. ... (The DNS server could not bind a Transmission Control ... From DC3SRVR to DC1SRVR ...
    (microsoft.public.windows.server.active_directory)