We discussed the various browser roles earlier. Let’s examine the election mechanism used for selecting browser roles for different types of computers.
A computer initiates an election as a result of any one of the following situations.
A client computer can’t locate a master browser or backup browser after three consecutive requests or when a domain controller is turned on. The client might be unable to find a master or backup browser for any one of a number of reasons, including network problems, hardware failures, or simply because the computer is booting up.
A backup browser attempts to update its network resource list and can’t locate the master browser. An NT Server that was acting as master browser may have been powered down with no other servers available to take on the role of master browser.
A computer that has been designated a preferred master browser comes on line.
You can also force elections with tools such as BROWSTAT.
Any computer can initiate an election by broadcasting a special packet called an election packet or election datagram. This election packet contains the requesting computer’s election criteria value. All browsers receive the election packet.
The election packet contains the sending browser’s election version and election criterion. The election version is a constant value that identifies the version of the browser election protocol. The election criterion is a 4-byte hexadecimal value.
Table 5.4 shows the election criteria in order as well as their associated hexadecimal values.
The election summary from a computer with the NetBIOS name Web is shown in Figure 5.11. This computer is a member of a workgroup called Projects.
When a browser receives an election packet, it examines the packet and first compares the election version with its own. If the receiving browser has a higher election version than any other browser, it wins the election regardless of the election criteria. If the election versions are identical for both computers, then the election criteria values are compared to break the tie.
If the browser has a higher election criteria value than the issuer of the election packet, the browser issues its own election packet and enters the “election in progress” state.
In the example in Figure 5.12, an NT Server with the NetBIOS name SERVER3 responds to an election packet. Note the election criteria value (536940430), third line under Browser, as well as the Election Desire Summary value (142). In the next-to-last line, you can also see the up time for this server.
If the receiving browser doesn’t have a higher election criteria value than the issuer of the election packet, the receiving browser attempts to determine which system is the new master browser using the following mechanism:
If two browsers are still tied based on the election version and the election criteria, the browser that has been running longest is the winner.
If both machines have been running for the same time, the browser that has a lexically lower name is the winner. For example, a server with a name of A becomes master browser instead of a server with a name of B.
The final step in the mechanism to elect a master browser is called a delay. When a browser receives an election packet indicating that it wins the election, the browser enters the running election state. In this state, the browser sends an election request after a delay based on the browser’s current browser role. Election delays are shown in Table 5.5.
The browser broadcasts up to four election packets. If, after four election packets, no other browser has responded with an election criterion value that would win the election, the browser becomes the master browser. The local master browser announcement is shown in Figure 5.13.
If a browser receives an election packet indicating that another system would win the election, the browser demotes itself to a backup browser. To avoid unnecessary network traffic, a browser that has lost an election doesn’t broadcast any unsent election packets.
OPTIMIZING BROWSER TRAFFIC
The election description in the previous section assumed that the network has just one protocol. Browser behavior varies with the type of protocol being used, the number of computers on the network, and the number of protocols in use on the network.
The master browser must keep track of one backup browser for every 32 computers in a NetBEUI network or in a TCP/IP subnetwork. Reducing the number of computers in a given TCP/IP subnetwork or NetBEUI network of course minimizes the number of backup browsers and the related traffic. So, the first rule for minimizing browser traffic is to reduce the number of computers.
The second rule for minimizing browser traffic is to reduce the number of protocols that you’re running on a given network. The IPX/SPX protocol behaves slightly differently than TCP/IP and NetBEUI. Even though IPX/SPX can be used for WANs, from a browser’s perspective the IPX/SPX network is one large logical network. As a result, the master browser keeps track of one backup browser for every 32 computers in the IPX/SPX network. When backup browsers are located across the WAN, browse lists must traverse the WAN and clients may have to go across the WAN to access information about local resources.
In typical IPX/SPX networks, resources are usually accessed from the local network, and therefore you may not need to access IPX/SPX resources across the WAN. If that is the case, you can filter IPX Type 20 WAN broadcasts at the router; filtering lets local servers, most probably BDCs, become master browsers and minimize browser traffic across the WAN.
The third rule for minimizing browser traffic is usually a variation of something that says rules 1 and 2 can’t be followed! As a result, your network has multiple protocols, which ultimately results in further troubleshooting of problems related to multiple protocols and multiple computers. You can use products such as Network Associates’ Sniffer to capture browser-related packets and analyze them. In our experience, both the Network Monitor that comes with NT Server and the Network Monitor that is part of Microsoft’s System Management Server (SMS) have provided more helpful troubleshooting information than third-party products.
Tip: To reduce browser traffic:
Minimize the number of computers in a TCP/IP subnetwork or a LAN running the NetBEUI or IPX/SPX protocols.
Standardize on one protocol, preferably TCP/IP. Remove all other protocols.
If you don’t need to access IPX/SPX resources across a WAN, filter out IPX Type 20 WAN broadcasts at your router to prevent broadcast storms across your backbone network.
Browser-Related Problems
Networks with a large number of domain controllers may experience some browser-related problems. The following description is based on problems at one of our client sites.
The site has a network across four countries, linked through frame relay and TI lines. They were in the habit of installing every NT Server as a backup domain controller. As a result, they had close to 120 BDCs for about 6,000 users. The protocol mix on this network was different from location to location but all computers in each location were members of the same domain. Some BDCs had IPX/SPX and TCP/IP, others had TCP/IP and NetBEUI, and still others had IPX/SPX, TCP/IP, NetBEUI, and DLC. The PDC was running only TCP/IP. The corporation had a single master domain with six resource domains.
One of the problems was inconsistent browse lists. Constantly, one server or other would disappear from the browse list even though it was available on the network. Because the administrators assumed that the problem could be caused by NetBIOS broadcasts being invisible across their routed network, they turned NetBIOS on. Still the problem persisted.
A quick examination of the network using BROWSTAT, BROWMON, and the Network Monitor revealed the following facts:
The role of master browser was constantly passing from one BDC to another.
Logon servers for each client were changing constantly.
Browser elections were constantly being forced across the network and, as a result, logon servers were constantly building new browse lists.
Because browse lists were being built from scratch, the network had a large number of announcement requests.
Reducing the number of BDCs resolved all these problems for the following reasons:
A smaller number of BDCs meant that the PDC had to do less work satisfying requests from BDCs to synchronize security databases. Fewer requests in turn led to better handling of domain master browse lists. The PDC was no longer too busy to handle browse list requests from individual master browsers in each subnetwork.
Because the PDC could provide the domain browse list adequately to all master browsers, the browse lists were more consistent.
With fewer BDCs, fewer election packets were generated, which meant that the role of master browser for IPX/SPX and NetBEUI protocols stayed with specific BDCs for longer periods of time.
Another problem we noticed in this particular case was that the WINS servers were also affecting the browsing problem. The client had many users with Domain Administrator privileges and a large number of WINS servers. (Essentially, each domain administrator thought that his/her computer should be a WINS server!) The high number of domain administrators was necessary because installing server computers as BDCs resulted in the lack of a local security database on the server; all services were based on the domain’s security database. This situation led to more Domain Administrator accounts. Again, reducing the number of BDCs across the network improved control over the network. Once the rogue WINS servers were taken out, browsing improved as well.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
