WINS/nbtstat query

[Ben]

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.

 

[Steve Duff [MVP]]

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.

 

[the_player12345]

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

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.

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.

 

[Ben]

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 ?!?!

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

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.

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.

 

[Steve Duff [MVP]]

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.

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 ?!?!

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

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.

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.

 

[Ben]

Steve,

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


Ben.

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.

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 ?!?!

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.

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.