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



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