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

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%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