Stoping the master browser election
Imran
My problem is that. i have 2 windows 2000 std
domain controllers and 5 windows 2000 prof in one of the
windows 2000 prof and the first windows 2000 DC i see an
event log of master brwoser election. I serached in
Microsoft site it say the SM on the 2000 prof would not be
correct but that not the case. Every time i gives me a msg
unable to promote the prof computer to master brower. I
have installed the service pack on this machine. is there
a way that i can make stop this election process and make
the first DC as the master browser. or any other
suggestions will really be appericiated.
Regards
Imran
Andy Ball
Knowledge Base
Troubleshooting the Microsoft Computer Browser ServicePSS ID Number: Q188305
Article Last Modified on 09-9-2002
----------------------------------------------------------------------------
----
The information in this article applies to:
a.. Microsoft Windows 2000 Advanced Server
b.. Microsoft Windows 2000 Professional
c.. Microsoft Windows 2000 Server
d.. Microsoft Windows NT Server 4.0
e.. Microsoft Windows NT Workstation 4.0
f.. Microsoft Windows NT Server, Enterprise Edition 4.0
----------------------------------------------------------------------------
----
Summary
Although there is no centralized method to determine if the browse list
across a WAN is complete, there are techniques to determine if the servers
on a particular segment are represented in the browse list on a remote
segment. These same techniques can be applied on all segments throughout the
WAN. However, the results of these tests can change if the roles of the
servers change when browser elections occur. Only if all the servers in a
domain throughout the WAN are completely static, and no servers come online
or go offline, will the results of these tests have meaning over time.
The tests that are described below rely on the Browstat.exe utility from the
Microsoft Windows Resource Kit utility. Sample output will be for the TCP/IP
protocol only. Also, as with most network problem diagnosis, to troubleshoot
the browser service, the administrator must have full knowledge of the
network segment boundaries and router configurations on the network. As an
example, assume that a client on a remote segment does not have a server in
its browse list that is located on another segment.
Because of the time sensitivity of the Browser service and its use of
broadcast datagrams, you should not perform these steps until after you wait
for the 48-minute cycle (the full propagation cycle in a multiple-segment
domain environment).
Remember that name resolution among all browsers is critical and that the
first thing to do is to establish a robust name resolution infrastructure
with WINS. A lot of time can be wasted trying to track down browser issues,
which are really caused by name resolution problems.
More Information
1.. Find the master browser on the segment on which the server is located.
Run this command on the segment on which the missing server resides:
browstat status
The response is similar to:
Status for domain DomainName on transport \Device\NetBT_IEEPRO1
Browsing is active on domain.
Master browser name is: MasterBrowser
Master browser is running build 1381
1 backup servers retrieved from master BackupBrowser
\\SmallerServer
There are 100 servers in domain DomainName on transport
\Device\NetBT_IEEPRO1
There are 1500 domains in domain DomainName on transport
\Device\NetBT_IEEPRO1
This information should indicate which server is acting as the master
browser on the segment. However, if the local master browser was slow to
respond, this information may have been received from another master
browser.
The results of this command give you the "\Device\Protocol_NIC" string,
which you can use with other browstat commands.
To find the local master browser on the client's segment, run the
following command:
browstat getmaster \device\netbt_el59x1 domainname
Using the status or getmaster switch sends a DomainName<1d> query and
returns the current master browser for that segment. The Browser service is
not used to find which computer is acting as the master browser. You can
perform this step remotely if the Browser service itself is used to indicate
which computers are acting as the master browser on the segment, but this
requires the administrator to know the names of all the servers on each of
the segments. Also, this is a poor troubleshooting technique because the
Browser service itself is being used to troubleshoot a browser problem. And
even if this piece of the browser does not have a problem, the list that is
returned may be out-of-date by as much as 36 minutes. To remotely determine
the list of master browsers on the domain, run the following command:
browstat view \device\netbt_ieepro1 \\pdcname | findstr /i mbr
Next, the administrator must determine which master browser is on the
segment that contains the missing server's name.
If a master browser cannot be found, you can force an election by stopping
and starting the Browser service on a domain controller that is on the
server's segment. In a few minutes, run this test again. Or, on the console
of a server on the server's segment, you can force an election by running
the following command:
browstat elect \device\netbt_ieepro1 domainname
2.. Determine if the master browser has the server's name in its list. The
master browser is the first server in the chain of communication that must
contain the missing server's name. This test determines if the master
browser has received the server's Host Announcement frame. Note that the
"\device..." string is obtained from the output above. Run the following
command:
browstat view \device\netbt_ieepro1 \\ masterbrowser | findstr /i
missingserver
If the master browser has the server in its list, the command will return
a response that is similar to:
\\ MissingServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
\\ MissingServer
If the local master browser does not have the server's name, you can run
the following command from any computer on the missing server's segment:
browstat forceannounce \device\netbt_el59x1 domainname
Or, you can run the following command from the missing server's console:
browstat announce \device\netbt_el59x1 domainname
It may be useful to verify that the missing server can map a network drive
to the master browser to verify network connectivity.
Also, you can reboot the server to force a Host Announcement frame.
3.. Determine if the PDC has received the server's name from the master
browser. Run the following command:
browstat view \device\netbt_ieepro1 \\ pdc | findstr /i missingserver
The output should be similar to:
\\ MissingServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
\\ MissingServer
If the server's name is missing, it is probably because of name resolution
problems. For the PDC to obtain the list of servers from the master browser,
the server's master browser must be able to resolve the DomainName<1b> name
so that it can send the directed Master Announcement frame by using UDP port
138. For the PDC to respond to this announcement to obtain the server's
name, it must be able to resolve the master browser's computer name. (For
the server's master browser to obtain the domain-wide list from the PDC, it,
too, must be able to resolve the PDC's computer name.)
Name resolution in both directions is critical. To verify that the
server's master browser can resolve the DomainName<1b> entry, run the
following command:
browstat getpdc \device\netbt_el59x1 domainname
To verify that the PDC and the master browser can resolve each other's
computer name, map a network drive from the master browser to the PDC and
from the PDC to the master browser. If any of these steps does not work,
resolve the name resolution problem.
4.. Determine the master browser on the client's segment. Do this by using
the same steps as in step 1, but on the client's segment.
5.. Determine if the master browser has the missing server's name on the
client's segment. Run the following command:
browstat view \device\netbt_ieepro1 \\ mbclientseg | findstr /i
missingserver
If the server has the entry, the output should be similar to:
\\ MissingServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
\\ MissingServer
If the master browser does not have the missing server's name, it is
probably because of a name resolution problem. Verify that the master
browser on the client's segment is able to resolve the DomainName<1b> name
by running the following command:
browstat getpdc \device\netbt_el59x1 domainname
Also, the master browser must be able to resolve the computer name of the
PDC. To verify this, map a network drive to the PDC.
If either of these tests does not work, resolve the name resolution
problems.
6.. Determine the backup browsers on the client's segment. To reduce the
demands on the segment master browser, when a client requests a browse list,
it will choose a backup browser if one is available. Therefore, it is more
likely that all the clients will use backup browsers. There are two ways to
determine the local backup browsers for this segment.
From the master browser's console, run the following command:
browstat locallist \device\netbt_ieepro1 | findstr /i bbr
This will return a list of entries similar to:
\\ BackupBrowser NT 04.00 (W,S,BDC,NT,BBR,DFS) "Description" of server
\\ BackupBrowser
To remote this command to the master browser, run the following command:
browstat view \device\netbt_ieepro1 \\ masterbrowser 0x40000000 |
findstr /i bbr
NOTE: These flags are defined in the following CIFS Browsing Protocol
document:
ftp://ftp.microsoft.com/developr/drg/cifs/cifsbrow.doc
7.. Determine if the backup browsers have the missing server's name. For
all clients on this segment to retrieve a reliable browse list, you must
check every backup browser for the missing server's name. For each backup
browser, run the following command:
browstat view \device\netbt_ieepro1 \\ backupbrowser | findstr /i
missingserver
If a backup browser does not contain the missing server's name, verify
that the backup browser can map a network drive to the master browser. The
backup browser role is the most dynamic browser role. Master browsers
instruct potential browsers to become backup browsers depending on the
browser load. Wait 12 minutes and then repeat steps 6 and 7.
For additional information about how the computer name might not exist in
the browsing list, click the article number below to view the article in the
Microsoft Knowledge Base:
Q231312 Computer Name Missing in the Browsing List
Multihomed Issues
For the PDC to build a single domain-wide list, it cannot be a multi-homed
server. Each master browser on remote segments will establish a connection
to the PDC. Because there is no guarantee that every master browser will
choose the same interface on the PDC, the PDC must be single-homed so that a
single domain-wide list can be built. Also, all master browsers must be
single-homed. Every 12 minutes, the master browser connects to the PDC and
requests the domain-wide list. The master browser then issues a Master
Announcement Browser frame to the PDC telling it to connect to the master
browser and obtain its local lists. However, because the PDC does not
maintain separate IP addresses for each interface on the master browser,
when the PDC connects to the master browser, it only obtains the list of
computers and servers that are collected on that particular interface.
Other Considerations
To avoid experiencing intermittent browser functionality and having to
perform these tests, you may need to dedicate computers on each segment to
maintain a consistent domain-wide list. If servers are frequently shut down
and restarted, consider placing a BDC if the number of segments is not
large, or at minimum a Windows-based member server on each segment with the
IsDomainMaster registry setting set to True. This will give the server an
edge during elections in becoming the master browser for the segment.
If none of the steps above work to allow you to proceed to the next step,
verify that none of the browser servers that you have identified have a
"name in conflict" error. You can check for this by running the following
command:
nbtstat -n
You can use this command remotely by using either the -A or -a switch.
The browser is very sensitive to the configuration of the routers throughout
the WAN. Because the browser roles are determined by broadcast elections,
UDP broadcasts must not be forwarded. Strange behavior can occur if UDP
broadcast traffic is forwarded in one direction but not the other. This may
generate "8003" browser events causing a continuous cycle of elections.
Another step that you can take to try to resolve problems is to capture
network traffic with a protocol analyzer such as the Microsoft Network
Monitor tool. To directly view the browser exchanges, you can stop and then
restart the Browser service. Unfortunately, there is no guarantee that a
browser will assume the same role that it had after you stop and start the
Browser service. However, this method can be especially useful to verify the
communication when the master browser requests the domain-wide list from the
PDC, and immediately following when the PDC requests the local list from the
master browser. After the browser service has started on the master browser,
within one or two minutes the full exchange should take place. Configure the
protocol analyzer's capture buffer and frame size settings to allow for this
quantity of traffic.
The list of servers returned by the browse service prior to Windows NT 4.0
was limited to 64 KB in size. When this size is exceeded, you will see a
truncated alphabetical list of servers. To avoid this behavior, all browsers
must be running Windows NT version 4.0 or later.
References
For more information, refer to the "Microsoft Windows NT Browser" white
paper at the following Microsoft Web site:
http://www.microsoft.com/ntserver/commserv/techdetails/prodarch/ntbrowser.asp
Additional query words: win2000hotnet kbfaqw2knet
Keywords: kbnetwork kbtshoot
Issue Type: kbinfo
Technology: kbWinNTsearch kbWinNTWsearch kbWinNTW400 kbWinNTW400search
kbWinNT400search kbwin2000AdvServ kbwin2000AdvServSearch kbwin2000Serv
kbWinNTSsearch kbWinNTSEntSearch kbWinNTSEnt400 kbWinNTS400search
kbWinNTS400 kbwin2000ServSearch kbwin2000Search kbwin2000ProSearch
kbwin2000Pro kbWinAdvServSearch
----------------------------------------------------------------------------
----
Send feedback to Microsoft
© 2002-2003 Microsoft Corporation. All rights reserved.
--
Andy Ball
Greenfell Computing Ltd
http://www.sharepointcode.com
"Imran" <falco...@hotmail.com> wrote in message
news:00fe01c2cce5$47f74640$89f82ecf@TK2MSFTNGXA01...