The Windows Browser (Building Internet Firewalls, 2nd Edition)

20.4. The Windows Browser

The information that Windows machines display in the Network Neighborhood and in other places where you can pick a computer from a list comes from a server known as the Windows Browser. This is a separate service from name resolution and is not just dependent on name resolution, but also intertwined with it. In particular, machines use special names to locate Browser servers, and those names are sometimes registered and resolved exceptionally. The Browser service is responsible for most of the mysterious broadcast packets to port 138 that you will see on Windows networks, and a significant number of the mysterious headaches suffered by Windows administrators. The headaches are greatly magnified by the fact that very few people understand exactly what Browser service is supposed to do, let alone how it does it.

The Browser service is responsible only for maintaining lists of computers so that human beings can pick them from the list instead of having to be able to type the computer's name. The Browser does not list the resources actually available on the computer; it isn't part of WINS, much less the same thing as WINS; and it isn't involved in any direct interactions between servers and clients. It's not at all unusual for a machine to be visible via the Browser but not actually accessible, and this is not a problem with the Browser. If it is accessible but unintentionally invisible, that's a Browser problem but not a surprise.

Originally, Windows Browser service was entirely broadcast-based. A number of complicated changes have been made to allow it to work across routers, so that in theory if a network stays the same for long enough, and contains enough Windows NT machines, browsing information will stabilize and propagate across the entire network. For a complex network, this process may take a considerable amount of time and in fact will often take longer than the average delay between network changes.

20.4.1. Domains and Workgroups

Every machine on a Windows network must be part of some domain or workgroup. A workgroup is simply a collection of machines that share the same workgroup registration; there are no controls over what machines can be in a workgroup. Being a member of a workgroup is like being a sports fan; if you say you're part of the group, then you are.

A domain is an administrative entity where there is a centralized source of information (a domain controller). Joining a domain is like joining an exclusive club; you have to be admitted by the administration. Unfortunately, it is possible to create a workgroup with the same name as a domain.

The Browser service was created before domains, and as a result, it is not fully aware of the distinction between workgroups and domains. It treats them identically and pretends that they are domains (both by calling them domains and by assuming that every group of workstations that it knows about has a contactable domain controller).

20.4.2. Windows Browser Roles

A Browser server contains information about a single domain, which it gathers by listening to the registrations broadcast by machines at boot time. Since the Browser is primarily broadcast-based, many things about the Browser apply to the set of machines that are reachable by broadcast. For convenience, we'll call this set of machines a subnet, although depending on how you configure your network it may not technically be a subnet.

ost machines that know about Browser service are capable of being Browser servers, and it is perfectly legitimate for multiple machines on the same subnet to be Browser servers for the same domain or workgroup. These machines will use broadcast to elect a master browser. There will always be exactly one master browser per subnet per domain or workgroup. A single subnet may have multiple master browsers for different domains or workgroups, and a single domain or workgroup may have multiple master browsers on different subnets. Figure 20-7 shows a network with multiple subnets and multiple domains and the resulting browser configuration.

Figure 20-7. Master browsers in a network with multiple domains and multiple subnets

In general, users don't care about subnet boundaries; they want to know about all the machines in a domain or workgroup, regardless of what subnet they're on. Since Browser servers collect data via broadcast, it requires some mechanism for master browsers on different networks to synchronize information. In a workgroup configuration, there is simply no way for this to occur. Workgroups have no centralized structure. In a domain configuration, however, there is a central source of information (the domain controller), and the master browsers for a domain will all synchronize to it. The domain controller's centralized Browser server is called a domain master browser.

Browser servers do not initiate transactions to individual hosts by their normal names. Instead, the Browser sends out broadcast packets or unicast packets to special hostnames. The Browser does not need to know how to find other servers; it simply tries to send packets to the name that the server would be using if it existed. If no server is there, name resolution will fail (for unicast packets), or the broadcast will be ignored (for broadcast packets). The Browser simplifies things still further by not even attempting name resolution for most group names and simply sending out broadcasts with a destination NetBIOS name set. Hosts that are not part of the group will ignore the broadcasts.

The following sections describe the browser roles and the names associated with them.

20.4.2.1. Domain master browser

The domain master browser registers a unique name with the name of the domain and the type 1B. It is always the primary domain controller. Because it is a domain controller, it also registers a group name with the name of the domain and the type 1C. Aside from registering the name, the domain master browser takes no special actions. Other master browsers will initiate connections to it for synchronization. (This will be true whether or not there is an actual domain master browser, since the Browser assumes that everything is a domain. If there is no domain master browser, or it is unreachable, the amount of name resolution traffic will be significant as master browsers try to resolve the 1B and 1C names.)

20.4.2.2. Master browser

A master browser registers a unique name with the name of the domain and the type 1D. This represents a problem for WINS because WINS spans multiple subnets. It's legal for more than one master browser to exist, as long as they're on different subnets, but if they're all talking to the same WINS server, they shouldn't be able to register the name as a unique name. This is dealt with by having WINS treat the type 1D as special. WINS servers will return success for any attempt to register a unique name with type 1D, and failure for any attempt to resolve such a name. This allows the broadcast-based NetBT name service to handle uniqueness and resolution for master browsers.

A master browser also registers the group name _MSBROWSE_, which is used to distribute information among master browsers so that each one has the full list of available domains and workgroups.

aster browsers collect information from broadcasts to build up a list of all hosts in the domain or workgroup that they are responsible for, and to build up a list of other domains and workgroups and their master browsers.

aster browsers initiate four types of communication:

They broadcast their lists of hosts and domains to the backup browsers (using the group with the name of the domain and the type 1E).
They broadcast their domain and name to the other master browsers (using the group _MSBROWSE_).
They synchronize their lists of hosts and domains with their domain master browser (using the unique name with the name of the domain and the type 1B or, if that fails, the group name with the name of the domain and the type 1C).
They tell machines that are potential browsers to become backup browsers (using a packet that is an IP unicast but has a NetBT destination of the group name with the name of the domain and the type 1E).

In addition, master browsers get requests from clients and return lists of backup browsers.

Sends a GetBackupListRequest via a NetBT message at UDP port 138 to the special unique name "netherworld<1d>" (this is sent as an IP broadcast and is processed only by the local master browser).
Sends a GetBackupListRequest to the unique name "netherworld<1b>" (this is sent as an IP unicast because it's a unique name, and it goes to the domain master browser, which is also the primary domain controller).
Gets back two lists of servers, which contain computer names.
Selects three of the servers listed in the browser lists provided to it and saves them for future browsing.
Asks one of those three servers for a list of domains and workgroups; this comes back with the names of the domains or workgroups and the computer name of the local master browser for each one. This is a NetBT session conversation at TCP port 139.
Sends a name resolution query for the name "limbo<1d>" via broadcast to UDP port 137 (NetBT name service). This is a special query that is done over broadcast even on a machine that would otherwise try WINS before broadcast.
If step 6 succeeded, sends a request for a list of members to the machine "limbo<1d>". This is once again a NetBT session conversation at TCP port 139.
If there was no response to the previous request, resolves the computer name listed as the master browser for domain "limbo" by the machine's standard name resolution procedure and connects to it over NetBT session for a list of members.

If the client wanted a member list for its own domain, it would send that request at step 5. If there is no response to the initial GetBackupList requests, both requests are retried up to three times, and if there is still no response, the client starts an election. The client starts an election only if both GetBackupList requests fail.

20.4.3. Browser Elections

Elections are one of the best-documented parts of the Browser protocol; for the details on how they work, consult almost any book on Microsoft networking (for instance, Microsoft's Windows NT Server Networking Guide, mentioned earlier). In outline, the procedure is that a machine that wants an election to occur sends a packet to the IP broadcast address with the NetBT destination of the group with the name of the domain and the type 1E. This packet includes several parameters that indicate the machine's qualifications to be master browser. Each browser that gets the packet compares those qualifications to its own and sends another election packet if it is more qualified. A machine that sends out an election packet without getting a response from a more qualified machine will send out three more; once a machine has sent out four election packets without seeing a response from a more qualified machine, it will consider itself elected and send out a master browser announcement.

Because master browsers are important for the speed with which browsing works, elections are designed to prefer more stable machines. Election qualifications include a parameter that depends on the machine's operating system version (Windows NT Server is better than Windows NT Workstation is better than Windows 95), plus a parameter specific to the browser, which you can think of as an indication of how much the machine wants to win, and a parameter that depends on the machine's uptime (longer uptime wins). Master browser announcements include information about some of these parameters (in particular, the operating system type and part of the browser-specific information).

There are two situations in which machines will decide to call elections:

A client will call an election if it tries to find a master browser and cannot. In this case, it will send out an election packet that is guaranteed to lose (all the parameters are set to zero). This is called an election force. If the client is also a potential browser server, it will not send out its real election packet unless it gets one from a less-qualified candidate, or it gets no response to repeated election force attempts.