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

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