Samba Part 7
The underlying system that makes this presentation possible is called the "Browser Service." This service collects and maintains the "Browse List," and viewing the Browse List (e.g., via the Network Neighborhood) is called "Browsing." It should be noted that Microsoft came up with these names before the invention of the Web Browser, so they cannot be blamed for any ensuing confusion.
Browsing is organized in terms of IP subnets and Workgroups. A "Workgroup" is a set of NBT nodes on an IP subnet that shares the same Workgroup name. In our examples, all of the nodes are members of the UBIQX workgroup.
On each subnet, the Workgroup members hold an "election," which involves sending group datagrams via the NBT Datagram Service. The election mechanism makes Florida recounts look easy, so we will save the description for another day. Eventually, a winner is declared and designated as the local "Master Browser" (LMB) for the Workgroup. If there are a lot of nodes in the Workgroup, additional local Browsers may be elected to serve as "Backup Browsers."
When a client wishes to see the Browse List, it asks one of the Browsers on the local LAN for a copy; this is what is displayed when you double-click Network Neighborhood.
As described earlier, the lack of a working NBDD in Microsoft's implementation of NBT limited browsing to IP subnets. Microsoft recognized the need to circulate Browse Lists outside of IP subnets, so they created yet another new server called the "Domain Master Browser" (DMB). The DMB registers its name with the WINS server. All of the local Master Browsers look for this name and will send updates to the DMB, which then combines the lists and hands them back. The DMB is a work-around for the missing NBDD, essentially allowing browsing to cross subnet boundaries.
NBT can be a pain in the neck, and old mistakes still haunt modern implementations. What is a multi-billion dollar corporation to do?
As mentioned earlier, Microsoft introduced SMB without NBT in Windows 2000 and calls it CIFS. In CIFS, the SMB packets run native over TCP without the need for NetBIOS framing. Not only has NetBIOS been removed, but all of the supporting systems (like name resolution, browsing, and even authentication) have been replaced with standards-based services. WINS, for example, has been replaced by Dynamic DNS, and Kerberos is now used for authentication. At the core of all this is the Active Directory, which (like Novell's NDS) is based on X.500. Unfortunately, Microsoft seems to have added their own spin to these services, and several sources are complaining about incompatibilities.
SAMBA can work with Windows 2000 systems, as long as the latter are running in NBT-compatibility mode. Even so, a number of problems have been reported and, hopefully, accommodated. SAMBA lives by adjusting itself to the quirks of each new Microsoft OS.
The Linux community has only begun to dig into Windows 2000. It is an enormous animal that will take some time to dissect. Meanwhile, Microsoft is already working on their next big products. We can only wait to see what changes will come with those.