19.3 Politics

On the local level, the Windows Browse Service is a volunteer organization. Nodes that are willing and able to donate some memory and CPU cycles make themselves available to the community by registering a special NetBIOS group name with a suffix byte value of 0x1E , as shown in the table above. That name is then used to hold an election and choose a workgroup leader. ^[2] The election winner is given the title of "Master Browser," and it registers a unique NetBIOS name with a suffix byte value of 0x1D . It also registers the strangely-formatted group name " \x01\x02__MSBROWSE__\x02\x01 " (that last ' \x01 ' is actually the suffix byte).

^[2] Mnemonic: 0x1Election .

As you may recall from the rant in Chapter 7 on page 141, Microsoft's WINS server provides special handling for unique names with the 0x1D suffix. Though the Master Browser may register this name with the WINS server, WINS will deny knowledge of the name when queried. WINS also returns 255.255.255.255 in response to name queries for group names. Most third-party NBNS implementations behave the same way in order to be WINS-compatible.

Two key things happen as a result:

• The NBNS provides no useful information when queried for either the workgroup <1D> name or the MSBROWSE<01> ^[3] name, so Master Browsers can only be found using NBT Broadcast Name Queries.

  ^[3] From here on out, we use " MSBROWSE<01> " as a shorthand for " \x01\x02__MSBROWSE__\x02\x01 " because it's really annoying to have to type all of those hex escapes and underscores every time.

• Each separate IP subnet may have a Master Browser with the same unique 0x1D name. Even if there is an NBNS, there will be no name conflict.T

This is highly unusual behavior for NetBIOS names but, on the plus side, each subnet in the Network Neighborhood gets to have its own elected leader. On the minus side, the Master Browsers cannot exchange information because they cannot talk to one another.

Figure 19.2 shows three separate workgroups, all with the same base name: " WORKGROUP ". They are distinct because they cannot exchange and combine Browse Lists. In order to bring these three together, we need yet another special node: the "Domain Master Browser."

Figure 19.2. Isolated Master Browsers

Because they cannot "see" one another, Master Browsers on separate IP subnets register the same unique NBT name without conflict.

Pedantic Phrasing Alert

Just to make it absolutely clear that the elected Master Browser is LAN-locked, and to distinguish it from the Domain Master Browser, from this point forward we will use the term L ocal M aster B rowser (LMB).

The D omain M aster B rowser (DMB) is the workgroup president. Unlike the democratically elected LMB, the DMB is appointed. The Network Manager (that's a human being) must select and configure a node to serve as DMB. The DMB will register the unique NetBIOS name workgroup <1B> to identify itself. Since the goal here is to bring together Browse Lists from separate subnets, there must also be an NBNS available so that all of the LMBs on all of the subnets can find the DMB.

Figure 19.3 (which is, admittedly, a bit complex) shows a single, unified workgroup. Node AMOS has been designated to act as the NBNS, and node DENNY has been given the job of Domain Master Browser. Nodes TZUKE and MCSHEE are Local Master Browsers for their own subnets. They will query the NBNS for the name WORKGROUP<1B> , and then contact the DMB in order to exchange Browse Lists. Note that the DMB takes on the role of LMB on its own subnet.

Figure 19.3. A unified workgroup

The existence of a Domain Master Browser and an NBNS allows the Local Master Browsers on each subnet to exchange Browse Lists.

19.3.1 When Is a Workgroup not a Workgroup?

A workgroup is not a workgroup when it is an NT Domain.

The difference between a workgroup and an NT Domain is that the latter has a Domain Controller, which is an authentication server. The Domain Controller keeps track of usernames and passwords, and all of the SMB file servers within the NT Domain are expected to consult with the Domain Controller whenever a client sends a SESSION SETUP REQUEST SMB.

In the Windows world, the DMB service is always offered by a P rimary D omain C ontroller (PDC). The two are considered inseparable, so if you are using Windows, you must set up a PDC in order to offer DMB services, and vice versa. This is probably why the DMB is called a Domain Master Browser.

Samba, on the other hand, lets you set up a DMB without the requirement that you also set up a PDC. Since DMB services do not, in fact, rely upon any NT Domain functionality, the DMB can operate independently. On the other hand, if you do wish to set up a PDC, then the PDC node must also be the DMB even with Samba. This latter restriction is a bit goofy. The reason for the requirement is that Microsoft's WINS (and, therefore, any WINS-compatible NBNS) provides special handling for a group name registered by the Domain Controllers. Consider the following table:

Name & Suffix	Group/Unique	Service/Description
nt_domain <1B>	unique	This name is registered by the Domain Master Browser. It must be registered with the NBNS in order to be of any real use.
nt_domain <1C>	Internet group	Registered by all Domain Controllers in the given NT Domain.

The goofy bit, which has been described elsewhere in this book, is that the WINS server keeps track of up to 25 IPs for the <1C> group name. WINS also ensures that the IP address of the node registering the <1B> name is always the first in the <1C> name's IP list. That last quirk is the only real linkage between the DMB and PDC names:

Within the NBT namespace, the Primary Domain Controller is distinguished from the Backup Domain Controllers by the fact that it also runs the DMB service and, therefore, registers the <1B> name.

This all brings up a small nomenclature problem: If there is a DMB running without a PDC (as Samba allows), is the result a workgroup or a domain? That situation was not anticipated by Microsoft, so the terminology doesn't quite work. (Can you call it a Domain Master Browser if there's no NT Domain?)

Careful Clarification Alert

For our purposes, we will use the term workgroup to specify the scope of the browsing environment even if the workgroup is also an NT Domain. We will use the term NT Domain when discussing an authentication domain.

19.3.2 Delegating Responsibility

So far, we have described Local Master Browsers and Domain Master Browsers. There are two additional types of browsers to consider.

Potential Browsers

These are nodes which are willing and able to provide browse services. They have the workgroup <1E> name registered and they participate as candidates in browser elections .

Backup Browsers

These are nodes that are selected by the Local Master Browser to assist in handing out the Browse List. Following the election, if there are other Potential Browsers available, the LMB may choose one or more of them to be Backup Browsers.

Now we can explain that a "Browser" is any node that participates in the creation and maintenance of the Browse Service. As we have shown, browsers are categorized as Potential , Backup , Local Master , or Domain Master . Browser roles are cumulative, and the Domain Master is at the top of the heap.

If the socio-political system seems overly complex, keep in mind that:

• The Windows Browse Service was developed in the days when 386- and 486-class processors were the top of the line.

• The Browse Service is run behind-the-scenes by systems that volunteer CPU time and a bit of memory.

• The more nodes there are on the subnet, the more work that must be done by the Local Master Browser.

• There may be several nodes on the network that are capable of acting as a Browser.

• If the nodes are unstable (frequently rebooted, shut down at the end of the day, etc.) a single copy of the Browse List may be lost.

All of this plays into the design of the Windows Browse Service.

The key thing to remember is that the Local Master Browser (unless it is also the DMB) is a volunteer, and being a Browser is not its primary function. The LMB node is, most likely, running as an SMB server or desktop system, or doing some other work. Allowing the Browse Service to interfere with someone's word processing or spreadsheet recalculations would be a bad thing.

So, on subnets with a lot of nodes, the LMB may select some of the Potential Browsers to act as Backup Browsers. When a client wants a copy of the Browse List, the LMB may direct the client to one or more Backup Browsers instead. The client will cache the IP addresses of the Backup Browsers, and from that point forward send all Browse List queries to one of those nodes. The Backup Browsers are also the most likely nodes to replace the current LMB if it goes down, and the backup copies of the Browse List that they maintain will ensure stability in the Network Neighborhood.