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

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" <none@xxxxxxxx> wrote in message
> news:exDQXFx7FHA.3876@xxxxxxxxxxxxxxxxxxxxxxx
>> 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%23Y9w7FHA.476@xxxxxxxxxxxxxxxxxxxxxxx
>>> 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.


.

Relevant Pages