Connecting to Shared Folders
You can share all the folders you want, but if users cannot find them with a minimum of fuss, you might as well be selling whiskey at a Methodist revival meeting.
Windows Server 2003 provides three ways to locate shared file resources: browsing, Active Directory publishing, and the Distributed File System (Dfs). The first two options are covered here. The Distributed File System is covered later in this chapter in section, "Resource Sharing with the Distributed File System."
Browsing has been a feature of Windows networking for many years. It's a clumsy but serviceable way to locate servers and their shared resources.
Every network segment has at least one browser, called the Subnet Master Browser. Servers register their names with the Subnet Master Browser when they come onto the network. The database of server names maintained by the Subnet Master Browser is called a Browse list.
When a user opens My Network Places or views a resource list under Map Network Drive, the network client requests a copy of the Browse list from the Subnet Master Browser. The list of servers in the interface comes from that Browse list.
Any Windows computer with file sharing enabled can be a master browser or a backup browser. This includes Windows for Workgroups, Windows 9x/ME, all versions of NT, Windows 2000, XP, and Windows Server 2003. Master browsers are selected on the basis of a browse election. The results depend on a hierarchy designed to rig the election in favor of servers over desktops and domain controllers over servers and NT-based operating systems over Windows 9x/3.x operating systems.
It's possible that the Subnet Master Browser could get too busy to handle client requests. To get help, it behaves like a Revolutionary-era British merchant captain and presses other servers into action as backup browsers. The master browser replicates the latest Browse list to the backup browsers then refers client requests to them in round-robin fashion for load sharing.
Servers who toss their hat into the ring for the election to master browser are called potential browsers. If a potential browser loses the election, it becomes a candidate to be a backup browser. Each time 32 additional clients come on the wire, the master browser selects another backup browser.
In a routed TCP/IP environment, the Subnet Master Browsers replicate their Browse lists to the primary domain controller (PDC), which also acts as the Domain Master Browser. In an Active Directory domain, the PDC Emulator is the Domain Master Browser. The Domain Master Browser consolidates the Browse lists and redistributes the result to the Subnet Master Browsers, which in turn replicate them to the backup browsers.
Searching Instead of Browsing
In a large enterprise with hundreds or thousands of servers, it can take quite a while to open My Network Places to find a particular computer. It's much faster to use the Search utility from the Start menu. The Search feature searches the browse database, not DNS or Active Directory. Search for a computer as follows:
From the Search window, select the Printers, Computers, or People link in the left side of the window.
Click the Computer on the Network link.
Enter the flat name for the computer.
When and if the computer is found, double-click it to see the shared resources.
Troubleshooting Browsing Problems
Aside from printing and security, browsing is the network function that causes the most grief for system administrators. It's fairly straightforward to troubleshoot browsing failures, but it's important to keep the basic functionality in mind.
This is easy because most of the technology in legacy Windows parallels Dr. Seuss stories. Browsing was designed by someone who was raised on Yertle the Turtle. Remember Yertle's catch phrase? "I'm Yertle the Turtle, oh marvelous me. I am the master of all I can see, and nobody's head can see higher than me."
A Subnet Master Browser can see only the servers on its subnet, so its copy of the browse database only lists those servers. The Domain Master Browser can see all the Subnet Master Browsers, so his database contains all the servers, but only when he has obtained copies of the local browse databases. There is potentially a different master browser for each transport protocol, making it possible to have several Yertles in each local LAN or subnet.
Finally, If you try to put too many subnets into the same browsing database, the whole structure will come tumbling down and the browse master will become the master of mud, because that's all he can see.
Browsing, when it works, gives users a quick and convenient way to find servers and their resources. Browsing is much more complex than it first seems, though, and this complexity makes it somewhat confusing to users. Here is a list of browsing's most glaring deficiencies:
Windows clients query the browse master for the first transport in the binding order. This often results in two machines sitting side by side that display different server lists.
Browser registrations, browse elections, and Browse list queries cause a significant amount of broadcast traffic. Every network client in the subnet must process those broadcasts.
Browse list replication has significant latency. It can take as much as 51 minutes for a downed server to disappear from a Browse list. During this time, the dead server continues to appear in My Network Places.
Browsing in a TCP/IP network depends on Windows Internet Name Service (WINS), which is itself a little creaky at the joints. The Subnet Master Browsers locate the Domain Master Browser by querying WINS for the master browser record. In turn, the PDC locates the Subnet Master Browsers by their entries in WINS. If WINS gets unstable or is unavailable, browsing will soon suffer.
It is theoretically possible to eliminate browsing from your network by providing an alternate way of locating servers and their resources. One way to do this is by publishing the shares in Active Directory. As we'll see, this method leaves a bit to be desired, so a better solution is the Distributed File System.