Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- From: "GreenGoblin" <none@xxxxxxxx>
- Date: Mon, 21 Nov 2005 22:26:32 -0500
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:%23SjVVNx7FHA.740@xxxxxxxxxxxxxxxxxxxxxxx
> 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.
>
>
.
- References:
- Computer Browsing Service - anyone want to contribute for a good conversation?
- From: GreenGoblin
- Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- From: Bill Grant
- Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- From: GreenGoblin
- Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- From: Bill Grant
- Computer Browsing Service - anyone want to contribute for a good conversation?
- Prev by Date: Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- Next by Date: Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- Previous by thread: Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- Next by thread: Re: Computer Browsing Service - anyone want to contribute for a good conversation?
- Index(es):
Relevant Pages
|
