Master browsers maintain lists of computers and the services they offer. In this context, services refers to the types of SMB/CIFS duties they perform, such as file server, NBNS system, and so on. Master browsers don’t maintain lists of the specific shares offered on particular servers; for that detail, clients must contact the servers themselves.

As mentioned earlier, two types of master browsers exist: local master browsers and domain master browsers. Domain master browsers normally also function as local master browsers. Both types deliver basically the same information, but domain master browsers add more methods of operation.

Local master browsers serve just one subnet on a LAN. The computers on a single subnet automatically determine which system is to function as the local master browser via an election , in which each computer broadcasts a set of credentials to the entire subnet, and the system with the best credentials claims victory. Because of this automatic selection system, you can’t simply set a Samba parameter or two and be sure the system will become a local master browser. You can, however, set Samba parameters that will make it more or less likely to win—ideally, so likely to win that it’s all but a sure thing, if that’s what you desire. You can also tell Samba not to participate in elections, if you like. The next section describes configuring a system to win or lose local master browser elections.

Domain master browsers integrate information from local master browsers on multiple subnets, providing a way to enable browsing across subnets. They’re usually part of an NT domain configuration, although you can configure a domain master browser in a workgroup. You must explicitly configure one computer as a domain master browser; they aren’t selected through an election process. The Section 5.3.3 describes how to do this.

No client-side configuration is required to point clients at either type of master browser. Clients should be able to find local master browsers by using broadcasts. Domain master browsers can be found via any NetBIOS name lookup method.

The local master browser election process is designed to give local master browser status to the computer that’s best able to handle this duty. Election criteria include the OS version, whether the computer is functioning as a domain controller, whether the computer is functioning as an NBNS system, and so on. The most important factor is the OS version, so adjusting this detail is a critical step in “rigging” an election that you want a Samba server to win. Several other factors are important as well, though. Overall, you should consider these global parameters:

The os level parameter trumps all the others, aside from local master and browse list. That is, in a contest between computers with os level parameters set to say, 32 and 33, the system with os level = 33 will win every master browser election, even if the other system is configured with domain logons = Yes, wins support = Yes, and preferred master = Yes. Overall, you can be fairly certain that a system will function as a local master browser if you set options like these in the [global] section of smb.conf:

local master = Yes
preferred master = Yes
os level = 64

If your network has some Samba systems with inappropriately high os level parameters, you may need to increase that value. (On the other hand, tracking down the offending systems and fixing their configurations may be a preferable solution.) If the computer also functions as a domain controller or NBNS system, you may need to set appropriate options for those functions, too. These settings shouldn’t be necessary to have the system take on local master browser duties, though.

The domain master browser isn’t elected by all the computers on the network; it’s assigned by a network administrator. For this reason, Samba provides a parameter that tells Samba to take on this duty: domain master. This parameter is a global Boolean, and you should be careful about setting it. Don’t set this parameter to Yes if you’re not certain the system should be functioning as a domain master browser; do set it to Yes if the computer takes on this role.

Normally, the domain controller takes on domain master browser duties. Some workgroup configurations also use domain master browsers, even though they don’t have domain controllers. This configuration can be helpful if your network spans multiple subnets, but you don’t want to use a full domain configuration.

You should be sure to configure a domain master browser to win the local master browser election for its subnet, as described in the previous section. That section describes some options related to domain controller status as factors in browser elections; however, these factors are small ones, and they’re completely irrelevant if two systems’ OS levels don’t match. Thus, you should be sure your domain controller has the highest os level parameter of any computer on the network.