Computer Browsing Service - anyone want to contribute for a good conversation?

Hi,
I have read many posts on this subject recently. I am in the same dilemma's
as many other people on here and I have read all the recent posts but there
hasn't been a good solution offered.

I can't find a clear answer on this so maybe if everyone sticks to one post
we can all work it out? Basically I have 15 vlan's routed with cisco
equipment and run mostly on hp/cisco switches. This is a 2003 domain with 3
sites and 2 dc's at each location. All dc's are GC's as well. 1 location
is coming down soon so let's just work with 2 sites. We have WINS running
on 2 dc's at one location and then at another location on 2 different
servers, 1 of which is a dc and 1 that is not. I don't replicate WINS to
the other location as it is in another country and we don't see a need to
browse through sites or that it is even needed to replicate, is that wrong?
Therefore let's just work with a single site and that is my trouble. So I
have 2 dc's with all the FSMO roles on one of them. They are both on
different subnets. I have about 140 clients. I am trying to find out how
to control the browsing and how to set the reg key "isdomainmaster" or if I
set that manually at all. I would like to know how most people are handling
this issue where xp clients are just filling up the event logs with errors
about machines promoting themselves. This seems to be quite a common issue
and I haven't read a good response yet on how to really fix this? I know it
is a "chatty" service but there must be a solution. Some of you MVP's
recommend that people shut off the browser service while others are quite
opposed to that.
I have used browstat and browmon but the only thing I see is that multiple
member servers or clients are promoting themselves and I don't know why they
can't reach the DMB anyway. Is it in fact correct that the browser service
will not traverse a router? If that is true then doesn't the information
get replicated to the DMB on one subnet via WINS? My dc/dns/wins server 1
is on a .60 subnet. My dc/dns/wins server 2 is on a .70 subnet. Server 2
should send it's info over to server 1 when wins replicates right? So why
is my network neighborhood not updating? Why are clients promoting
themselves instead of going to the master browser - server 2on the .70
subnet or a backup server? Don't server OS' take precedence for promotion?

Thanks
your friendly neighborhood Goblin.

GreenGoblin wrote:
> Hi,
> I have read many posts on this subject recently. I am in the same
> dilemma's as many other people on here and I have read all the recent
> posts but there hasn't been a good solution offered.
>
> I can't find a clear answer on this so maybe if everyone sticks to
> one post we can all work it out? Basically I have 15 vlan's routed
> with cisco equipment and run mostly on hp/cisco switches. This is a
> 2003 domain with 3 sites and 2 dc's at each location. All dc's are
> GC's as well. 1 location is coming down soon so let's just work with
> 2 sites. We have WINS running on 2 dc's at one location and then at
> another location on 2 different servers, 1 of which is a dc and 1
> that is not. I don't replicate WINS to the other location as it is
> in another country and we don't see a need to browse through sites or
> that it is even needed to replicate, is that wrong? Therefore let's
> just work with a single site and that is my trouble. So I have 2
> dc's with all the FSMO roles on one of them. They are both on
> different subnets. I have about 140 clients. I am trying to find
> out how to control the browsing and how to set the reg key
> "isdomainmaster" or if I set that manually at all. I would like to
> know how most people are handling this issue where xp clients are
> just filling up the event logs with errors about machines promoting
> themselves. This seems to be quite a common issue and I haven't read
> a good response yet on how to really fix this? I know it is a
> "chatty" service but there must be a solution. Some of you MVP's
> recommend that people shut off the browser service while others are
> quite opposed to that. I have used browstat and browmon but the only
> thing I see is that
> multiple member servers or clients are promoting themselves and I
> don't know why they can't reach the DMB anyway. Is it in fact
> correct that the browser service will not traverse a router? If that
> is true then doesn't the information get replicated to the DMB on one
> subnet via WINS? My dc/dns/wins server 1 is on a .60 subnet. My
> dc/dns/wins server 2 is on a .70 subnet. Server 2 should send it's
> info over to server 1 when wins replicates right? So why is my
> network neighborhood not updating? Why are clients promoting
> themselves instead of going to the master browser - server 2on the
> .70 subnet or a backup server? Don't server OS' take precedence for
> promotion?
> Thanks
> your friendly neighborhood Goblin.

First off I will repeat what I said in another post recently. The
entries you see where workstations appear to be promoting themselves is
usally a symptom that the browser service has already failed. They are not
really trying to become master browsers. They send the announcement to
trigger off a browser election because they cannot get a browse list. This
is the standard method for a client to force an election when browsing is
not working.

Building a browse list is done by LAN broadcasts. That is why it doesn't
just work in a routed network. The router blocks the broadcasts, and each
segment builds its own browse list. There are two things necessary for
browsing to work in a routed network.

The first essential is a domain controller. Only a domain controller can
merge browse lists from different segments to build a network-wide list. The
second essential is a method for the Domain Master Browser to find the
Segment Master Browsers in other segments/subnets. That is where WINS comes
in.

WINS does not store or replicate browse lists. The part it plays is
simply to provide a means for the DMB to find the SMBs (and vice versa).
Because they are in different subnets/segments they cannot communicate by
broadcast. They need to be able to go to WINS to resolve names to IP
addresses. They can then communicate directly with machines in other
subnets/segments.

If browstat/browmon isn't giving you the info you need, you will need to
go to a network monitor/sniffer. That is the only way to really see why a
client machine cannot get a browse list. You need to see how it requests a
browse list and why it fails.

The normal process is that the client will query WINS for the special
Netbios name <domainname 1B> (ie the domain master browser) . If WINS has
an entry for this name, it should return the IP address of the DMB. The
client then sends off a request for the browse list.

Common causes of failure are that the client doesn't have the correct
domain name (this is common with remote access clients which are logged in
elsewhere) , or WINS doesn't have an entry for the DMB.

The most common cause of master browser failures is multihomed browse
masters. If a master browser is multihomed (and this includes remote access
servers which have a "internal" interface with its own IP), browsing fails
when the "wrong" IP is used to contact the browse master. Netbios bound to
one interface is not seen if you use the IP address of a different interface
on the machine.

VLANs complicate the situation because each VLAN is a separate broadcast
domain. So each VLAN has its own SMB. In VLANs without servers, the SMB will
be a workstation. Because workstations come and go, the SMB will not be
consistently the same machine. When the current SMB shuts down, you get the
same situation as in a workgroup when the current master browser shuts down.

Bill,
that's great information.
So I do have a 1b entry but that is the dc on the .70 subnet. So my
machines are on.60 and .70. So if I am following this then machines on .60
won't get the master browse list from the dc on the .70? So they got to the
SMB which is the DC on the .70. Well, I checked name resolution and all
that is fine. So where can I look next? Does this have to do with clients
netbios over tcp settings?
If the browse list isn't replicated with wins, what method is it that makes
the browsers replicate to eachother?

There are many servers on each subnet so that makes no sense that the
clients are promoting themselves?
"Bill Grant" <not.available@online> wrote in message
news:e4b%(E-Mail Removed)...
> GreenGoblin wrote:
>> Hi,
>> I have read many posts on this subject recently. I am in the same
>> dilemma's as many other people on here and I have read all the recent
>> posts but there hasn't been a good solution offered.
>>
>> I can't find a clear answer on this so maybe if everyone sticks to
>> one post we can all work it out? Basically I have 15 vlan's routed
>> with cisco equipment and run mostly on hp/cisco switches. This is a
>> 2003 domain with 3 sites and 2 dc's at each location. All dc's are
>> GC's as well. 1 location is coming down soon so let's just work with
>> 2 sites. We have WINS running on 2 dc's at one location and then at
>> another location on 2 different servers, 1 of which is a dc and 1
>> that is not. I don't replicate WINS to the other location as it is
>> in another country and we don't see a need to browse through sites or
>> that it is even needed to replicate, is that wrong? Therefore let's
>> just work with a single site and that is my trouble. So I have 2
>> dc's with all the FSMO roles on one of them. They are both on
>> different subnets. I have about 140 clients. I am trying to find
>> out how to control the browsing and how to set the reg key
>> "isdomainmaster" or if I set that manually at all. I would like to
>> know how most people are handling this issue where xp clients are
>> just filling up the event logs with errors about machines promoting
>> themselves. This seems to be quite a common issue and I haven't read
>> a good response yet on how to really fix this? I know it is a
>> "chatty" service but there must be a solution. Some of you MVP's
>> recommend that people shut off the browser service while others are
>> quite opposed to that. I have used browstat and browmon but the only
>> thing I see is that
>> multiple member servers or clients are promoting themselves and I
>> don't know why they can't reach the DMB anyway. Is it in fact
>> correct that the browser service will not traverse a router? If that
>> is true then doesn't the information get replicated to the DMB on one
>> subnet via WINS? My dc/dns/wins server 1 is on a .60 subnet. My
>> dc/dns/wins server 2 is on a .70 subnet. Server 2 should send it's
>> info over to server 1 when wins replicates right? So why is my
>> network neighborhood not updating? Why are clients promoting
>> themselves instead of going to the master browser - server 2on the
>> .70 subnet or a backup server? Don't server OS' take precedence for
>> promotion?
>> Thanks
>> your friendly neighborhood Goblin.
>
> First off I will repeat what I said in another post recently. The
> entries you see where workstations appear to be promoting themselves is
> usally a symptom that the browser service has already failed. They are not
> really trying to become master browsers. They send the announcement to
> trigger off a browser election because they cannot get a browse list. This
> is the standard method for a client to force an election when browsing is
> not working.
>
> Building a browse list is done by LAN broadcasts. That is why it
> doesn't just work in a routed network. The router blocks the broadcasts,
> and each segment builds its own browse list. There are two things
> necessary for browsing to work in a routed network.
>
> The first essential is a domain controller. Only a domain controller
> can merge browse lists from different segments to build a network-wide
> list. The second essential is a method for the Domain Master Browser to
> find the Segment Master Browsers in other segments/subnets. That is where
> WINS comes in.
>
> WINS does not store or replicate browse lists. The part it plays is
> simply to provide a means for the DMB to find the SMBs (and vice versa).
> Because they are in different subnets/segments they cannot communicate by
> broadcast. They need to be able to go to WINS to resolve names to IP
> addresses. They can then communicate directly with machines in other
> subnets/segments.
>
> If browstat/browmon isn't giving you the info you need, you will need
> to go to a network monitor/sniffer. That is the only way to really see why
> a client machine cannot get a browse list. You need to see how it requests
> a browse list and why it fails.
>
> The normal process is that the client will query WINS for the special
> Netbios name <domainname 1B> (ie the domain master browser) . If WINS
> has an entry for this name, it should return the IP address of the DMB.
> The client then sends off a request for the browse list.
>
> Common causes of failure are that the client doesn't have the correct
> domain name (this is common with remote access clients which are logged in
> elsewhere) , or WINS doesn't have an entry for the DMB.
>
> The most common cause of master browser failures is multihomed browse
> masters. If a master browser is multihomed (and this includes remote
> access servers which have a "internal" interface with its own IP),
> browsing fails when the "wrong" IP is used to contact the browse master.
> Netbios bound to one interface is not seen if you use the IP address of a
> different interface on the machine.
>
> VLANs complicate the situation because each VLAN is a separate
> broadcast domain. So each VLAN has its own SMB. In VLANs without servers,
> the SMB will be a workstation. Because workstations come and go, the SMB
> will not be consistently the same machine. When the current SMB shuts
> down, you get the same situation as in a workgroup when the current master
> browser shuts down.
>
>
>

I suggest you read it again. Many of your VLANs will not have a server
in them at all!

GreenGoblin wrote:
> Bill,
> that's great information.
> So I do have a 1b entry but that is the dc on the .70 subnet. So my
> machines are on.60 and .70. So if I am following this then machines
> on .60 won't get the master browse list from the dc on the .70? So
> they got to the SMB which is the DC on the .70. Well, I checked name
> resolution and all that is fine. So where can I look next? Does
> this have to do with clients netbios over tcp settings?
> If the browse list isn't replicated with wins, what method is it that
> makes the browsers replicate to eachother?
>
> There are many servers on each subnet so that makes no sense that the
> clients are promoting themselves?
> "Bill Grant" <not.available@online> wrote in message
> news:e4b%(E-Mail Removed)...
>> GreenGoblin wrote:
>>> Hi,
>>> I have read many posts on this subject recently. I am in the same
>>> dilemma's as many other people on here and I have read all the
>>> recent posts but there hasn't been a good solution offered.
>>>
>>> I can't find a clear answer on this so maybe if everyone sticks to
>>> one post we can all work it out? Basically I have 15 vlan's routed
>>> with cisco equipment and run mostly on hp/cisco switches. This is a
>>> 2003 domain with 3 sites and 2 dc's at each location. All dc's are
>>> GC's as well. 1 location is coming down soon so let's just work
>>> with 2 sites. We have WINS running on 2 dc's at one location and
>>> then at another location on 2 different servers, 1 of which is a dc
>>> and 1 that is not. I don't replicate WINS to the other location as
>>> it is in another country and we don't see a need to browse through
>>> sites or that it is even needed to replicate, is that wrong?
>>> Therefore let's just work with a single site and that is my
>>> trouble. So I have 2 dc's with all the FSMO roles on one of them. They
>>> are both on different subnets. I have about 140 clients. I
>>> am trying to find out how to control the browsing and how to set
>>> the reg key "isdomainmaster" or if I set that manually at all. I
>>> would like to know how most people are handling this issue where xp
>>> clients are just filling up the event logs with errors about
>>> machines promoting themselves. This seems to be quite a common
>>> issue and I haven't read a good response yet on how to really fix
>>> this? I know it is a "chatty" service but there must be a
>>> solution. Some of you MVP's recommend that people shut off the
>>> browser service while others are quite opposed to that. I have
>>> used browstat and browmon but the only thing I see is that
>>> multiple member servers or clients are promoting themselves and I
>>> don't know why they can't reach the DMB anyway. Is it in fact
>>> correct that the browser service will not traverse a router? If
>>> that is true then doesn't the information get replicated to the DMB
>>> on one subnet via WINS? My dc/dns/wins server 1 is on a .60
>>> subnet. My dc/dns/wins server 2 is on a .70 subnet. Server 2
>>> should send it's info over to server 1 when wins replicates right? So
>>> why is my network neighborhood not updating? Why are clients
>>> promoting themselves instead of going to the master browser -
>>> server 2on the .70 subnet or a backup server? Don't server OS'
>>> take precedence for promotion?
>>> Thanks
>>> your friendly neighborhood Goblin.
>>
>> First off I will repeat what I said in another post recently. The
>> entries you see where workstations appear to be promoting themselves
>> is usally a symptom that the browser service has already failed.
>> They are not really trying to become master browsers. They send the
>> announcement to trigger off a browser election because they cannot
>> get a browse list. This is the standard method for a client to force
>> an election when browsing is not working.
>>
>> Building a browse list is done by LAN broadcasts. That is why it
>> doesn't just work in a routed network. The router blocks the
>> broadcasts, and each segment builds its own browse list. There are
>> two things necessary for browsing to work in a routed network.
>>
>> The first essential is a domain controller. Only a domain
>> controller can merge browse lists from different segments to build a
>> network-wide list. The second essential is a method for the Domain
>> Master Browser to find the Segment Master Browsers in other
>> segments/subnets. That is where WINS comes in.
>>
>> WINS does not store or replicate browse lists. The part it plays
>> is simply to provide a means for the DMB to find the SMBs (and vice
>> versa). Because they are in different subnets/segments they cannot
>> communicate by broadcast. They need to be able to go to WINS to
>> resolve names to IP addresses. They can then communicate directly
>> with machines in other subnets/segments.
>>
>> If browstat/browmon isn't giving you the info you need, you will
>> need to go to a network monitor/sniffer. That is the only way to
>> really see why a client machine cannot get a browse list. You need
>> to see how it requests a browse list and why it fails.
>>
>> The normal process is that the client will query WINS for the
>> special Netbios name <domainname 1B> (ie the domain master
>> browser) . If WINS has an entry for this name, it should return the
>> IP address of the DMB. The client then sends off a request for the
>> browse list. Common causes of failure are that the client doesn't have
>> the
>> correct domain name (this is common with remote access clients which
>> are logged in elsewhere) , or WINS doesn't have an entry for the
>> DMB. The most common cause of master browser failures is multihomed
>> browse masters. If a master browser is multihomed (and this includes
>> remote access servers which have a "internal" interface with its own
>> IP), browsing fails when the "wrong" IP is used to contact the
>> browse master. Netbios bound to one interface is not seen if you use
>> the IP address of a different interface on the machine.
>>
>> VLANs complicate the situation because each VLAN is a separate
>> broadcast domain. So each VLAN has its own SMB. In VLANs without
>> servers, the SMB will be a workstation. Because workstations come
>> and go, the SMB will not be consistently the same machine. When the
>> current SMB shuts down, you get the same situation as in a workgroup
>> when the current master browser shuts down.

Bill, one more question. I am looking at my dhcp scope now, do I need to
enable netbios there for all clients, could that be the reason they are not
getting to the SMB or DMB?
I didn't know that setting was important because I thought WINS took care of
this?
So if you provide a WINS server, what does netbios over tcp do? Does that
also make clients use WINS before DNS?
"GreenGoblin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Bill,
> that's great information.
> So I do have a 1b entry but that is the dc on the .70 subnet. So my
> machines are on.60 and .70. So if I am following this then machines on
> .60 won't get the master browse list from the dc on the .70? So they got
> to the SMB which is the DC on the .70. Well, I checked name resolution
> and all that is fine. So where can I look next? Does this have to do
> with clients netbios over tcp settings?
> If the browse list isn't replicated with wins, what method is it that
> makes the browsers replicate to eachother?
>
> There are many servers on each subnet so that makes no sense that the
> clients are promoting themselves?
> "Bill Grant" <not.available@online> wrote in message
> news:e4b%(E-Mail Removed)...
>> GreenGoblin wrote:
>>> Hi,
>>> I have read many posts on this subject recently. I am in the same
>>> dilemma's as many other people on here and I have read all the recent
>>> posts but there hasn't been a good solution offered.
>>>
>>> I can't find a clear answer on this so maybe if everyone sticks to
>>> one post we can all work it out? Basically I have 15 vlan's routed
>>> with cisco equipment and run mostly on hp/cisco switches. This is a
>>> 2003 domain with 3 sites and 2 dc's at each location. All dc's are
>>> GC's as well. 1 location is coming down soon so let's just work with
>>> 2 sites. We have WINS running on 2 dc's at one location and then at
>>> another location on 2 different servers, 1 of which is a dc and 1
>>> that is not. I don't replicate WINS to the other location as it is
>>> in another country and we don't see a need to browse through sites or
>>> that it is even needed to replicate, is that wrong? Therefore let's
>>> just work with a single site and that is my trouble. So I have 2
>>> dc's with all the FSMO roles on one of them. They are both on
>>> different subnets. I have about 140 clients. I am trying to find
>>> out how to control the browsing and how to set the reg key
>>> "isdomainmaster" or if I set that manually at all. I would like to
>>> know how most people are handling this issue where xp clients are
>>> just filling up the event logs with errors about machines promoting
>>> themselves. This seems to be quite a common issue and I haven't read
>>> a good response yet on how to really fix this? I know it is a
>>> "chatty" service but there must be a solution. Some of you MVP's
>>> recommend that people shut off the browser service while others are
>>> quite opposed to that. I have used browstat and browmon but the only
>>> thing I see is that
>>> multiple member servers or clients are promoting themselves and I
>>> don't know why they can't reach the DMB anyway. Is it in fact
>>> correct that the browser service will not traverse a router? If that
>>> is true then doesn't the information get replicated to the DMB on one
>>> subnet via WINS? My dc/dns/wins server 1 is on a .60 subnet. My
>>> dc/dns/wins server 2 is on a .70 subnet. Server 2 should send it's
>>> info over to server 1 when wins replicates right? So why is my
>>> network neighborhood not updating? Why are clients promoting
>>> themselves instead of going to the master browser - server 2on the
>>> .70 subnet or a backup server? Don't server OS' take precedence for
>>> promotion?
>>> Thanks
>>> your friendly neighborhood Goblin.
>>
>> First off I will repeat what I said in another post recently. The
>> entries you see where workstations appear to be promoting themselves is
>> usally a symptom that the browser service has already failed. They are
>> not really trying to become master browsers. They send the announcement
>> to trigger off a browser election because they cannot get a browse list.
>> This is the standard method for a client to force an election when
>> browsing is not working.
>>
>> Building a browse list is done by LAN broadcasts. That is why it
>> doesn't just work in a routed network. The router blocks the broadcasts,
>> and each segment builds its own browse list. There are two things
>> necessary for browsing to work in a routed network.
>>
>> The first essential is a domain controller. Only a domain controller
>> can merge browse lists from different segments to build a network-wide
>> list. The second essential is a method for the Domain Master Browser to
>> find the Segment Master Browsers in other segments/subnets. That is where
>> WINS comes in.
>>
>> WINS does not store or replicate browse lists. The part it plays is
>> simply to provide a means for the DMB to find the SMBs (and vice versa).
>> Because they are in different subnets/segments they cannot communicate by
>> broadcast. They need to be able to go to WINS to resolve names to IP
>> addresses. They can then communicate directly with machines in other
>> subnets/segments.
>>
>> If browstat/browmon isn't giving you the info you need, you will need
>> to go to a network monitor/sniffer. That is the only way to really see
>> why a client machine cannot get a browse list. You need to see how it
>> requests a browse list and why it fails.
>>
>> The normal process is that the client will query WINS for the special
>> Netbios name <domainname 1B> (ie the domain master browser) . If WINS
>> has an entry for this name, it should return the IP address of the DMB.
>> The client then sends off a request for the browse list.
>>
>> Common causes of failure are that the client doesn't have the correct
>> domain name (this is common with remote access clients which are logged
>> in elsewhere) , or WINS doesn't have an entry for the DMB.
>>
>> The most common cause of master browser failures is multihomed browse
>> masters. If a master browser is multihomed (and this includes remote
>> access servers which have a "internal" interface with its own IP),
>> browsing fails when the "wrong" IP is used to contact the browse master.
>> Netbios bound to one interface is not seen if you use the IP address of a
>> different interface on the machine.
>>
>> VLANs complicate the situation because each VLAN is a separate
>> broadcast domain. So each VLAN has its own SMB. In VLANs without servers,
>> the SMB will be a workstation. Because workstations come and go, the SMB
>> will not be consistently the same machine. When the current SMB shuts
>> down, you get the same situation as in a workgroup when the current
>> master browser shuts down.
>>
>>
>>
>
>

Yes, I understand, however I am only concerned with 2 vlans currently and
both have dc's.
One holds all master roles and is a gc, the other is a dc and gc.
The master browser as you know is the 1st dc in subnet 1. The other one is
subnet 2 and that is a dc.
I get clients promoting themselves on both subnets.
I am not sure why.

"Bill Grant" <not.available@online> wrote in message
news:%(E-Mail Removed)...
> I suggest you read it again. Many of your VLANs will not have a server
> in them at all!
>
> GreenGoblin wrote:
>> Bill,
>> that's great information.
>> So I do have a 1b entry but that is the dc on the .70 subnet. So my
>> machines are on.60 and .70. So if I am following this then machines
>> on .60 won't get the master browse list from the dc on the .70? So
>> they got to the SMB which is the DC on the .70. Well, I checked name
>> resolution and all that is fine. So where can I look next? Does
>> this have to do with clients netbios over tcp settings?
>> If the browse list isn't replicated with wins, what method is it that
>> makes the browsers replicate to eachother?
>>
>> There are many servers on each subnet so that makes no sense that the
>> clients are promoting themselves?
>> "Bill Grant" <not.available@online> wrote in message
>> news:e4b%(E-Mail Removed)...
>>> GreenGoblin wrote:
>>>> Hi,
>>>> I have read many posts on this subject recently. I am in the same
>>>> dilemma's as many other people on here and I have read all the
>>>> recent posts but there hasn't been a good solution offered.
>>>>
>>>> I can't find a clear answer on this so maybe if everyone sticks to
>>>> one post we can all work it out? Basically I have 15 vlan's routed
>>>> with cisco equipment and run mostly on hp/cisco switches. This is a
>>>> 2003 domain with 3 sites and 2 dc's at each location. All dc's are
>>>> GC's as well. 1 location is coming down soon so let's just work
>>>> with 2 sites. We have WINS running on 2 dc's at one location and
>>>> then at another location on 2 different servers, 1 of which is a dc
>>>> and 1 that is not. I don't replicate WINS to the other location as
>>>> it is in another country and we don't see a need to browse through
>>>> sites or that it is even needed to replicate, is that wrong?
>>>> Therefore let's just work with a single site and that is my
>>>> trouble. So I have 2 dc's with all the FSMO roles on one of them. They
>>>> are both on different subnets. I have about 140 clients. I
>>>> am trying to find out how to control the browsing and how to set
>>>> the reg key "isdomainmaster" or if I set that manually at all. I
>>>> would like to know how most people are handling this issue where xp
>>>> clients are just filling up the event logs with errors about
>>>> machines promoting themselves. This seems to be quite a common
>>>> issue and I haven't read a good response yet on how to really fix
>>>> this? I know it is a "chatty" service but there must be a
>>>> solution. Some of you MVP's recommend that people shut off the
>>>> browser service while others are quite opposed to that. I have
>>>> used browstat and browmon but the only thing I see is that
>>>> multiple member servers or clients are promoting themselves and I
>>>> don't know why they can't reach the DMB anyway. Is it in fact
>>>> correct that the browser service will not traverse a router? If
>>>> that is true then doesn't the information get replicated to the DMB
>>>> on one subnet via WINS? My dc/dns/wins server 1 is on a .60
>>>> subnet. My dc/dns/wins server 2 is on a .70 subnet. Server 2
>>>> should send it's info over to server 1 when wins replicates right? So
>>>> why is my network neighborhood not updating? Why are clients
>>>> promoting themselves instead of going to the master browser -
>>>> server 2on the .70 subnet or a backup server? Don't server OS'
>>>> take precedence for promotion?
>>>> Thanks
>>>> your friendly neighborhood Goblin.
>>>
>>> First off I will repeat what I said in another post recently. The
>>> entries you see where workstations appear to be promoting themselves
>>> is usally a symptom that the browser service has already failed.
>>> They are not really trying to become master browsers. They send the
>>> announcement to trigger off a browser election because they cannot
>>> get a browse list. This is the standard method for a client to force
>>> an election when browsing is not working.
>>>
>>> Building a browse list is done by LAN broadcasts. That is why it
>>> doesn't just work in a routed network. The router blocks the
>>> broadcasts, and each segment builds its own browse list. There are
>>> two things necessary for browsing to work in a routed network.
>>>
>>> The first essential is a domain controller. Only a domain
>>> controller can merge browse lists from different segments to build a
>>> network-wide list. The second essential is a method for the Domain
>>> Master Browser to find the Segment Master Browsers in other
>>> segments/subnets. That is where WINS comes in.
>>>
>>> WINS does not store or replicate browse lists. The part it plays
>>> is simply to provide a means for the DMB to find the SMBs (and vice
>>> versa). Because they are in different subnets/segments they cannot
>>> communicate by broadcast. They need to be able to go to WINS to
>>> resolve names to IP addresses. They can then communicate directly
>>> with machines in other subnets/segments.
>>>
>>> If browstat/browmon isn't giving you the info you need, you will
>>> need to go to a network monitor/sniffer. That is the only way to
>>> really see why a client machine cannot get a browse list. You need
>>> to see how it requests a browse list and why it fails.
>>>
>>> The normal process is that the client will query WINS for the
>>> special Netbios name <domainname 1B> (ie the domain master
>>> browser) . If WINS has an entry for this name, it should return the
>>> IP address of the DMB. The client then sends off a request for the
>>> browse list. Common causes of failure are that the client doesn't have
>>> the
>>> correct domain name (this is common with remote access clients which
>>> are logged in elsewhere) , or WINS doesn't have an entry for the
>>> DMB. The most common cause of master browser failures is multihomed
>>> browse masters. If a master browser is multihomed (and this includes
>>> remote access servers which have a "internal" interface with its own
>>> IP), browsing fails when the "wrong" IP is used to contact the
>>> browse master. Netbios bound to one interface is not seen if you use
>>> the IP address of a different interface on the machine.
>>>
>>> VLANs complicate the situation because each VLAN is a separate
>>> broadcast domain. So each VLAN has its own SMB. In VLANs without
>>> servers, the SMB will be a workstation. Because workstations come
>>> and go, the SMB will not be consistently the same machine. When the
>>> current SMB shuts down, you get the same situation as in a workgroup
>>> when the current master browser shuts down.
>
>

Bill, also just so you know I am reading this carefully.
I do have multiple vlans but 2 are the ones clients are on, the rest are
firewalled off and I am not concerned with them as they aren't on the
domain.
The 2 subnets I am worried about I have sent you the info on. There are
servers and WINS has the dmb record in it properly.
How do I check for an smb record and is there one?
I don't know if you mean the browser service has actually failed or you mean
the process failed? I tested from at least 10 clients that promoted
themselves and they can all resolve the name of the dmb and the server that
should be the smb.
So I can get a packet sniffer but what do I get and how do I test it to
generate the browser request? So if WINS doesn't replicate the browse list
between smb and dmb, how/what doest this?
"Bill Grant" <not.available@online> wrote in message
news:%(E-Mail Removed)...
> I suggest you read it again. Many of your VLANs will not have a server
> in them at all!
>
> GreenGoblin wrote:
>> Bill,
>> that's great information.
>> So I do have a 1b entry but that is the dc on the .70 subnet. So my
>> machines are on.60 and .70. So if I am following this then machines
>> on .60 won't get the master browse list from the dc on the .70? So
>> they got to the SMB which is the DC on the .70. Well, I checked name
>> resolution and all that is fine. So where can I look next? Does
>> this have to do with clients netbios over tcp settings?
>> If the browse list isn't replicated with wins, what method is it that
>> makes the browsers replicate to eachother?
>>
>> There are many servers on each subnet so that makes no sense that the
>> clients are promoting themselves?
>> "Bill Grant" <not.available@online> wrote in message
>> news:e4b%(E-Mail Removed)...
>>> GreenGoblin wrote:
>>>> Hi,
>>>> I have read many posts on this subject recently. I am in the same
>>>> dilemma's as many other people on here and I have read all the
>>>> recent posts but there hasn't been a good solution offered.
>>>>
>>>> I can't find a clear answer on this so maybe if everyone sticks to
>>>> one post we can all work it out? Basically I have 15 vlan's routed
>>>> with cisco equipment and run mostly on hp/cisco switches. This is a
>>>> 2003 domain with 3 sites and 2 dc's at each location. All dc's are
>>>> GC's as well. 1 location is coming down soon so let's just work
>>>> with 2 sites. We have WINS running on 2 dc's at one location and
>>>> then at another location on 2 different servers, 1 of which is a dc
>>>> and 1 that is not. I don't replicate WINS to the other location as
>>>> it is in another country and we don't see a need to browse through
>>>> sites or that it is even needed to replicate, is that wrong?
>>>> Therefore let's just work with a single site and that is my
>>>> trouble. So I have 2 dc's with all the FSMO roles on one of them. They
>>>> are both on different subnets. I have about 140 clients. I
>>>> am trying to find out how to control the browsing and how to set
>>>> the reg key "isdomainmaster" or if I set that manually at all. I
>>>> would like to know how most people are handling this issue where xp
>>>> clients are just filling up the event logs with errors about
>>>> machines promoting themselves. This seems to be quite a common
>>>> issue and I haven't read a good response yet on how to really fix
>>>> this? I know it is a "chatty" service but there must be a
>>>> solution. Some of you MVP's recommend that people shut off the
>>>> browser service while others are quite opposed to that. I have
>>>> used browstat and browmon but the only thing I see is that
>>>> multiple member servers or clients are promoting themselves and I
>>>> don't know why they can't reach the DMB anyway. Is it in fact
>>>> correct that the browser service will not traverse a router? If
>>>> that is true then doesn't the information get replicated to the DMB
>>>> on one subnet via WINS? My dc/dns/wins server 1 is on a .60
>>>> subnet. My dc/dns/wins server 2 is on a .70 subnet. Server 2
>>>> should send it's info over to server 1 when wins replicates right? So
>>>> why is my network neighborhood not updating? Why are clients
>>>> promoting themselves instead of going to the master browser -
>>>> server 2on the .70 subnet or a backup server? Don't server OS'
>>>> take precedence for promotion?
>>>> Thanks
>>>> your friendly neighborhood Goblin.
>>>
>>> First off I will repeat what I said in another post recently. The
>>> entries you see where workstations appear to be promoting themselves
>>> is usally a symptom that the browser service has already failed.
>>> They are not really trying to become master browsers. They send the
>>> announcement to trigger off a browser election because they cannot
>>> get a browse list. This is the standard method for a client to force
>>> an election when browsing is not working.
>>>
>>> Building a browse list is done by LAN broadcasts. That is why it
>>> doesn't just work in a routed network. The router blocks the
>>> broadcasts, and each segment builds its own browse list. There are
>>> two things necessary for browsing to work in a routed network.
>>>
>>> The first essential is a domain controller. Only a domain
>>> controller can merge browse lists from different segments to build a
>>> network-wide list. The second essential is a method for the Domain
>>> Master Browser to find the Segment Master Browsers in other
>>> segments/subnets. That is where WINS comes in.
>>>
>>> WINS does not store or replicate browse lists. The part it plays
>>> is simply to provide a means for the DMB to find the SMBs (and vice
>>> versa). Because they are in different subnets/segments they cannot
>>> communicate by broadcast. They need to be able to go to WINS to
>>> resolve names to IP addresses. They can then communicate directly
>>> with machines in other subnets/segments.
>>>
>>> If browstat/browmon isn't giving you the info you need, you will
>>> need to go to a network monitor/sniffer. That is the only way to
>>> really see why a client machine cannot get a browse list. You need
>>> to see how it requests a browse list and why it fails.
>>>
>>> The normal process is that the client will query WINS for the
>>> special Netbios name <domainname 1B> (ie the domain master
>>> browser) . If WINS has an entry for this name, it should return the
>>> IP address of the DMB. The client then sends off a request for the
>>> browse list. Common causes of failure are that the client doesn't have
>>> the
>>> correct domain name (this is common with remote access clients which
>>> are logged in elsewhere) , or WINS doesn't have an entry for the
>>> DMB. The most common cause of master browser failures is multihomed
>>> browse masters. If a master browser is multihomed (and this includes
>>> remote access servers which have a "internal" interface with its own
>>> IP), browsing fails when the "wrong" IP is used to contact the
>>> browse master. Netbios bound to one interface is not seen if you use
>>> the IP address of a different interface on the machine.
>>>
>>> VLANs complicate the situation because each VLAN is a separate
>>> broadcast domain. So each VLAN has its own SMB. In VLANs without
>>> servers, the SMB will be a workstation. Because workstations come
>>> and go, the SMB will not be consistently the same machine. When the
>>> current SMB shuts down, you get the same situation as in a workgroup
>>> when the current master browser shuts down.
>
>

WINS uses Netbios over TCP/IP. WINS is just a name server like DNS. The
difference is that it uses Netbios names, not heirarchical names like DNS
uses.If the clients didn't have Netbt enabled, they would never appear in
WINS in the first place. Do you have all client machines and servers
configured with a WINS address (either static or from DHCP)? All machines
should register with WINS.

Browse lists are built and exchanged by the computer browser service. If
you really want to know how it works, start with KB188001 . The KB has links
to further documents .

Start by looking hard at WINS. Make sure all WINS servers have an entry
for <domainname 1b> . Make sure all backup browsers are registered in WINS.
It doesn't matter which subnet your clients are in. They can reach the DMB
as long as the WINS server they use has the <domainname 1B> entry.

GreenGoblin wrote:
> Bill, one more question. I am looking at my dhcp scope now, do I need
> to enable netbios there for all clients, could that be the reason
> they are not getting to the SMB or DMB?
> I didn't know that setting was important because I thought WINS took
> care of this?
> So if you provide a WINS server, what does netbios over tcp do? Does
> that also make clients use WINS before DNS?
> "GreenGoblin" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Bill,
>> that's great information.
>> So I do have a 1b entry but that is the dc on the .70 subnet. So my
>> machines are on.60 and .70. So if I am following this then machines
>> on .60 won't get the master browse list from the dc on the .70? So
>> they got to the SMB which is the DC on the .70. Well, I checked
>> name resolution and all that is fine. So where can I look next? Does
>> this have to do with clients netbios over tcp settings?
>> If the browse list isn't replicated with wins, what method is it that
>> makes the browsers replicate to eachother?
>>
>> There are many servers on each subnet so that makes no sense that the
>> clients are promoting themselves?
>> "Bill Grant" <not.available@online> wrote in message
>> news:e4b%(E-Mail Removed)...
>>> GreenGoblin wrote:
>>>> Hi,
>>>> I have read many posts on this subject recently. I am in the same
>>>> dilemma's as many other people on here and I have read all the
>>>> recent posts but there hasn't been a good solution offered.
>>>>
>>>> I can't find a clear answer on this so maybe if everyone sticks to
>>>> one post we can all work it out? Basically I have 15 vlan's routed
>>>> with cisco equipment and run mostly on hp/cisco switches. This is
>>>> a 2003 domain with 3 sites and 2 dc's at each location. All dc's
>>>> are GC's as well. 1 location is coming down soon so let's just
>>>> work with 2 sites. We have WINS running on 2 dc's at one location
>>>> and then at another location on 2 different servers, 1 of which is
>>>> a dc and 1 that is not. I don't replicate WINS to the other
>>>> location as it is in another country and we don't see a need to
>>>> browse through sites or that it is even needed to replicate, is
>>>> that wrong? Therefore let's just work with a single site and that
>>>> is my trouble. So I have 2 dc's with all the FSMO roles on one of
>>>> them. They are both on different subnets. I have about 140
>>>> clients. I am trying to find out how to control the browsing and
>>>> how to set the reg key "isdomainmaster" or if I set that manually
>>>> at all. I would like to know how most people are handling this
>>>> issue where xp clients are just filling up the event logs with
>>>> errors about machines promoting themselves. This seems to be
>>>> quite a common issue and I haven't read a good response yet on how
>>>> to really fix this? I know it is a "chatty" service but there
>>>> must be a solution. Some of you MVP's recommend that people shut
>>>> off the browser service while others are quite opposed to that. I
>>>> have used browstat and browmon but the only thing I see is that
>>>> multiple member servers or clients are promoting themselves and I
>>>> don't know why they can't reach the DMB anyway. Is it in fact
>>>> correct that the browser service will not traverse a router? If
>>>> that is true then doesn't the information get replicated to the
>>>> DMB on one subnet via WINS? My dc/dns/wins server 1 is on a .60
>>>> subnet. My dc/dns/wins server 2 is on a .70 subnet. Server 2
>>>> should send it's info over to server 1 when wins replicates right?
>>>> So why is my network neighborhood not updating? Why are clients
>>>> promoting themselves instead of going to the master browser -
>>>> server 2on the .70 subnet or a backup server? Don't server OS'
>>>> take precedence for promotion?
>>>> Thanks
>>>> your friendly neighborhood Goblin.
>>>
>>> First off I will repeat what I said in another post recently. The
>>> entries you see where workstations appear to be promoting
>>> themselves is usally a symptom that the browser service has already
>>> failed. They are not really trying to become master browsers. They
>>> send the announcement to trigger off a browser election because
>>> they cannot get a browse list. This is the standard method for a
>>> client to force an election when browsing is not working.
>>>
>>> Building a browse list is done by LAN broadcasts. That is why it
>>> doesn't just work in a routed network. The router blocks the
>>> broadcasts, and each segment builds its own browse list. There are
>>> two things necessary for browsing to work in a routed network.
>>>
>>> The first essential is a domain controller. Only a domain
>>> controller can merge browse lists from different segments to build
>>> a network-wide list. The second essential is a method for the
>>> Domain Master Browser to find the Segment Master Browsers in other
>>> segments/subnets. That is where WINS comes in.
>>>
>>> WINS does not store or replicate browse lists. The part it plays
>>> is simply to provide a means for the DMB to find the SMBs (and vice
>>> versa). Because they are in different subnets/segments they cannot
>>> communicate by broadcast. They need to be able to go to WINS to
>>> resolve names to IP addresses. They can then communicate directly
>>> with machines in other subnets/segments.
>>>
>>> If browstat/browmon isn't giving you the info you need, you will
>>> need to go to a network monitor/sniffer. That is the only way to
>>> really see why a client machine cannot get a browse list. You need
>>> to see how it requests a browse list and why it fails.
>>>
>>> The normal process is that the client will query WINS for the
>>> special Netbios name <domainname 1B> (ie the domain master
>>> browser) . If WINS has an entry for this name, it should return the
>>> IP address of the DMB. The client then sends off a request for the
>>> browse list. Common causes of failure are that the client doesn't have
>>> the
>>> correct domain name (this is common with remote access clients
>>> which are logged in elsewhere) , or WINS doesn't have an entry for
>>> the DMB. The most common cause of master browser failures is multihomed
>>> browse masters. If a master browser is multihomed (and this
>>> includes remote access servers which have a "internal" interface
>>> with its own IP), browsing fails when the "wrong" IP is used to
>>> contact the browse master. Netbios bound to one interface is not
>>> seen if you use the IP address of a different interface on the
>>> machine. VLANs complicate the situation because each VLAN is a separate
>>> broadcast domain. So each VLAN has its own SMB. In VLANs without
>>> servers, the SMB will be a workstation. Because workstations come
>>> and go, the SMB will not be consistently the same machine. When the
>>> current SMB shuts down, you get the same situation as in a
>>> workgroup when the current master browser shuts down.

OK, I will do that, so the 1B record must be the same on all wins servers.
How do I know what the SMB's should be? I know on say subnet .60 that my
other dc should be the smb, but what record would be in wins? Just a
standard record?
In DHCP all clients get 2 WINS Server addresses, should they get both or
just 1?
How do I enable Netbios over tcp for wins, is that the record with the
details 0x8 or something similar?

"Bill Grant" <not.available@online> wrote in message
news:%(E-Mail Removed)...
> WINS uses Netbios over TCP/IP. WINS is just a name server like DNS. The
> difference is that it uses Netbios names, not heirarchical names like DNS
> uses.If the clients didn't have Netbt enabled, they would never appear in
> WINS in the first place. Do you have all client machines and servers
> configured with a WINS address (either static or from DHCP)? All machines
> should register with WINS.
>
> Browse lists are built and exchanged by the computer browser service.
> If you really want to know how it works, start with KB188001 . The KB has
> links to further documents .
>
> Start by looking hard at WINS. Make sure all WINS servers have an entry
> for <domainname 1b> . Make sure all backup browsers are registered in
> WINS. It doesn't matter which subnet your clients are in. They can reach
> the DMB as long as the WINS server they use has the <domainname 1B>
> entry.
>
> GreenGoblin wrote:
>> Bill, one more question. I am looking at my dhcp scope now, do I need
>> to enable netbios there for all clients, could that be the reason
>> they are not getting to the SMB or DMB?
>> I didn't know that setting was important because I thought WINS took
>> care of this?
>> So if you provide a WINS server, what does netbios over tcp do? Does
>> that also make clients use WINS before DNS?
>> "GreenGoblin" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Bill,
>>> that's great information.
>>> So I do have a 1b entry but that is the dc on the .70 subnet. So my
>>> machines are on.60 and .70. So if I am following this then machines
>>> on .60 won't get the master browse list from the dc on the .70? So
>>> they got to the SMB which is the DC on the .70. Well, I checked
>>> name resolution and all that is fine. So where can I look next? Does
>>> this have to do with clients netbios over tcp settings?
>>> If the browse list isn't replicated with wins, what method is it that
>>> makes the browsers replicate to eachother?
>>>
>>> There are many servers on each subnet so that makes no sense that the
>>> clients are promoting themselves?
>>> "Bill Grant" <not.available@online> wrote in message
>>> news:e4b%(E-Mail Removed)...
>>>> GreenGoblin wrote:
>>>>> Hi,
>>>>> I have read many posts on this subject recently. I am in the same
>>>>> dilemma's as many other people on here and I have read all the
>>>>> recent posts but there hasn't been a good solution offered.
>>>>>
>>>>> I can't find a clear answer on this so maybe if everyone sticks to
>>>>> one post we can all work it out? Basically I have 15 vlan's routed
>>>>> with cisco equipment and run mostly on hp/cisco switches. This is
>>>>> a 2003 domain with 3 sites and 2 dc's at each location. All dc's
>>>>> are GC's as well. 1 location is coming down soon so let's just
>>>>> work with 2 sites. We have WINS running on 2 dc's at one location
>>>>> and then at another location on 2 different servers, 1 of which is
>>>>> a dc and 1 that is not. I don't replicate WINS to the other
>>>>> location as it is in another country and we don't see a need to
>>>>> browse through sites or that it is even needed to replicate, is
>>>>> that wrong? Therefore let's just work with a single site and that
>>>>> is my trouble. So I have 2 dc's with all the FSMO roles on one of
>>>>> them. They are both on different subnets. I have about 140
>>>>> clients. I am trying to find out how to control the browsing and
>>>>> how to set the reg key "isdomainmaster" or if I set that manually
>>>>> at all. I would like to know how most people are handling this
>>>>> issue where xp clients are just filling up the event logs with
>>>>> errors about machines promoting themselves. This seems to be
>>>>> quite a common issue and I haven't read a good response yet on how
>>>>> to really fix this? I know it is a "chatty" service but there
>>>>> must be a solution. Some of you MVP's recommend that people shut
>>>>> off the browser service while others are quite opposed to that. I
>>>>> have used browstat and browmon but the only thing I see is that
>>>>> multiple member servers or clients are promoting themselves and I
>>>>> don't know why they can't reach the DMB anyway. Is it in fact
>>>>> correct that the browser service will not traverse a router? If
>>>>> that is true then doesn't the information get replicated to the
>>>>> DMB on one subnet via WINS? My dc/dns/wins server 1 is on a .60
>>>>> subnet. My dc/dns/wins server 2 is on a .70 subnet. Server 2
>>>>> should send it's info over to server 1 when wins replicates right?
>>>>> So why is my network neighborhood not updating? Why are clients
>>>>> promoting themselves instead of going to the master browser -
>>>>> server 2on the .70 subnet or a backup server? Don't server OS'
>>>>> take precedence for promotion?
>>>>> Thanks
>>>>> your friendly neighborhood Goblin.
>>>>
>>>> First off I will repeat what I said in another post recently. The
>>>> entries you see where workstations appear to be promoting
>>>> themselves is usally a symptom that the browser service has already
>>>> failed. They are not really trying to become master browsers. They
>>>> send the announcement to trigger off a browser election because
>>>> they cannot get a browse list. This is the standard method for a
>>>> client to force an election when browsing is not working.
>>>>
>>>> Building a browse list is done by LAN broadcasts. That is why it
>>>> doesn't just work in a routed network. The router blocks the
>>>> broadcasts, and each segment builds its own browse list. There are
>>>> two things necessary for browsing to work in a routed network.
>>>>
>>>> The first essential is a domain controller. Only a domain
>>>> controller can merge browse lists from different segments to build
>>>> a network-wide list. The second essential is a method for the
>>>> Domain Master Browser to find the Segment Master Browsers in other
>>>> segments/subnets. That is where WINS comes in.
>>>>
>>>> WINS does not store or replicate browse lists. The part it plays
>>>> is simply to provide a means for the DMB to find the SMBs (and vice
>>>> versa). Because they are in different subnets/segments they cannot
>>>> communicate by broadcast. They need to be able to go to WINS to
>>>> resolve names to IP addresses. They can then communicate directly
>>>> with machines in other subnets/segments.
>>>>
>>>> If browstat/browmon isn't giving you the info you need, you will
>>>> need to go to a network monitor/sniffer. That is the only way to
>>>> really see why a client machine cannot get a browse list. You need
>>>> to see how it requests a browse list and why it fails.
>>>>
>>>> The normal process is that the client will query WINS for the
>>>> special Netbios name <domainname 1B> (ie the domain master
>>>> browser) . If WINS has an entry for this name, it should return the
>>>> IP address of the DMB. The client then sends off a request for the
>>>> browse list. Common causes of failure are that the client doesn't have
>>>> the
>>>> correct domain name (this is common with remote access clients
>>>> which are logged in elsewhere) , or WINS doesn't have an entry for
>>>> the DMB. The most common cause of master browser failures is multihomed
>>>> browse masters. If a master browser is multihomed (and this
>>>> includes remote access servers which have a "internal" interface
>>>> with its own IP), browsing fails when the "wrong" IP is used to
>>>> contact the browse master. Netbios bound to one interface is not
>>>> seen if you use the IP address of a different interface on the
>>>> machine. VLANs complicate the situation because each VLAN is a separate
>>>> broadcast domain. So each VLAN has its own SMB. In VLANs without
>>>> servers, the SMB will be a workstation. Because workstations come
>>>> and go, the SMB will not be consistently the same machine. When the
>>>> current SMB shuts down, you get the same situation as in a
>>>> workgroup when the current master browser shuts down.
>
>

"GreenGoblin" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>how do I enable Netbios over tcp for wins, is that the record with the
>details 0x8 or something similar?

When you pre-define the node type option in DHCP that automatically enable
NetBIOS over TCP/IP.

--
Todd J Heron, MCSE
Windows Server 2003/2000/NT; CCA
----------------------------------------------------------------------------
This posting is provided "as is" with no warranties and confers no rights