This page is provided by the NETS to assist those who may be experiencing problems with Microsoft (MS) Windows networking. We outline how MS Windows networking normally functions and give some troubleshooting techniques to try for those times when it does not.
This NETS troubleshooting guide is for those situations where users using MS Windows clients complain of not being able to see various MS Windows network resources (e.g., server shares and printers). A common call made to the local system administrator might sound like this -- "I can't browse the Network Neighborhood--is the network down?" The answer, of course, is that the "network" is NOT down, but the MS process called "browsing" has probably had some component of it go wrong, so MS Windows network resources do not display in browse lists in Explorer or Network Neighborhood applications.
One of the best summaries available for this issue comes from Cisco's Windows Networking Design Implementation Guide. A lot of that material will be summarized here (along with other materials taken from some of the resources given in the "for more information" section at the bottom of this page).
What Is Windows Networking?
"Windows Networking" refers to the networking system shared by all the Microsoft operating systems (MS LAN Manager through Windows 2000 (W2K)). Windows Networking has three concepts of a group of related computers: workgroups, domains and a domain hierarchy. Workgroups can be any logical collection of computers; any computer on the network can join an existing workgroup or create a new one. More formal entities, domains are created and managed by a primary domain controller (PDC) process that runs on a Windows NT or Windows 2000 server. A domain has security and administrative properties that a workgroup does not. Each domain must have at least one NT or 2000 server, which is responsible for the PDC process, user account information in the domain, and security within the domain. Windows Networking domains are not the same as Internet domain names as used by the Domain Name System (DNS). A domain hierarchy or Active Directory Hierarchy is a collection of domains organized into parent-child relationships. This convention, introduced with W2K, enables easier searching through multiple domains in a single query (among other things). This hierarchy maps closely to a DNS namespace.
Prior to W2K, Windows Networking used the NetBIOS protocol for file sharing, printer sharing, messaging, authentication, and name resolution. A pure Windows 2000 installation would require NetBIOS only for interoperability with earlier versions of Windows Networking using the flat NetBIOS namespace. NetBIOS is a session-layer protocol that can run on any of the following transport protocols:
- NetBEUI (NetBIOS over LLC2)
- NWLink (NetBIOS over Internetwork Packet Exchange [IPX])
- NetBIOS over TCP (NBT)
It is recommended that NetBIOS over TCP (NBT) be used for most networks. Since NBT uses TCP/IP, each computer must be configured to use a static IP address, or to fetch an IP address dynamically with the Dynamic Host Configuration Protocol (DHCP). For ease of network administration, it is highly recommended to use DHCP; for optimum network performance, it is highly recommended to use a (Windows Internet Name Service) WINS server as well. A WINS server allows clients to get browsing information without having to broadcast requests every time.
In TCP/IP-based networks involving routers and multiple segments like we have here at UCAR, it is generally recommended that you implement WINS for name resolution and browsing support. It is important to note that a client only participates in domain browsing when the client is using a workgroup name that is equivalent to the domain name. Windows NT computers can also "join" the domain to gain this functionality, instead of being in a workgroup. A WINS environment acts as a central resource for information about various domains and resources. There is one more benefit in having WINS to assist browsing: multi-domain browsing. A PDC that is set up to query WINS periodically requests the list of all domains that are registered in the database. The PDC combines this with its own domain browse list, and thus has a complete list of computers in its domain, as well as a list of other domains. You see the effect of this when you browse the network using File Manager or Network Neighborhood. This is the extent of WINS involvement with browsing. It is not involved in the browser election process, nor with helping a client determine who its local segment master browser is, nor with helping the domain master browser determine who the segment master browsers are. Every NetBIOS name is a full 16 characters in length; the first 15 are user definable (or padded with spaces), and the 16th character is reserved to identify the network service that registered the name. The most familiar example of a NetBIOS name is the ComputerName on any Microsoft networking client. When the client is booted, various client network services will register the ComputerName along with their unique extension, such as ComputerName<00> (workstation service), and ComputerName<20> (server service). In this case, the only difference between these two names is the 16th character - and that does make them individually identifiable. A client can register all of its names by broadcast, and by direct datagram to WINS, depending on the client node type.
What is "browsing"?
"Browsing" in a Microsoft network should be considered a distributed service provided by one or more computers. Each computer can fall into several browser roles. For example, a "Segment master browser" (SegMB) could be any Windows NT Server, Workstation, or domain controller. It can also be a Windows 95 or Windows for Workgroups 3.11 computer. It is responsible for maintaining a browse list of the computers on its local segment, forwarding that list to the domain master browser, and requesting the domain browse list from the domain master browser. The SegMB merges the domain list with its local list, and makes that list available to any local client that requests it. A "Domain master browser" (DomMB) is a Windows NT or Windows 2000 (W2K) primary domain controller (PDC). It distributes and synchronizes the master browse list for master browsers on other subnets that have computers belonging to the same domain. Thus it is the central hub for maintaining the domain-wide browse list.
A network (or subnet or VLAN in our case) can contain the following types of "browsers":
- Non-Browsers - Do not maintain browse lists, but announce themselves periodically to the Master Browser. Can operate as a browse client, requesting browse lists from other computers operating as browsers on the same subnet. Configured so it cannot become a browser.
- Potential Browser - Can become a backup browser if instructed by the master browser for the subnet.
- Backup Browser - Receives a copy of the browse list from the master browser for its subnet. Distributes the browse list to other computers upon request.
- Master Browser - Collects and maintains the list of available network servers in its subnet. Fully replicates its listed information with the domain master browser to obtain a complete browse list for the network. Sends browse lists to Backup Browsers, responds to clients requesting browse server lists, and promotes Potential Browsers to Backup when needed.
- Preferred Master Browser - Same as Backup Browser except that it is biased in browser elections through setting the "IsDomainMasterBrowser" to TRUE in the registry's browser parameters.
- Domain Master Browser - Used only in Domain environments. By default the Primary Domain Controller (PDC) for a domain operates in this role. The PDC of a domain is given a special bias in browser elections so that it will become the Domain Master Browser. This allows browsing to be effective when a domain spans multiple subnets. Collects and maintains the master browse list of available servers for its domain, as well as any names for other domains and workgroups used in the network. Distributes and synchronizes the master browse list for master browsers on other subnets that have computers belonging to the same domain.
There will be at least one Master Browser on a workgroup/domain and one Backup Browser for every 32 systems in that workgroup/domain. This means that in a domain/workgroup with fewer than 32 systems, there will be one Master and one Backup Browser. One more Backup Browser will be added for every 32 systems. This is accomplished by the Master Browser telling a Potential Browser to become a Backup Browser.
The browse service maintains an up-to-date list of domains, workgroups, and computers and provides this list to applications when requested. For example, a W2K user might see this list when they select a workgroup to which the user's computer does not belong from within the "My Network Places" application. "Browse lists" can also be displayed by using the "net view" command. The list can contain the names of domains, workgroups, and computers that run file and printer sharing services. These computers can be Windows for Workgroups (WFW) through W2K machines, including both workstations and server, or any Samba shares that are in that subnet as well. Both domain and workgroup (if present) resources will be shown in these browse lists.
How the "normal" process starts:
When a Windows computer is started on the network, it announces itself to the master browse server for its workgroup and the master browse server adds that computer to the list of available computers in the workgroup The master browse server then notifies backup browse servers that a change to the browse list is available. The backup browsers then request the new information to update their local browse lists. It might take as long as 15 minutes before a backup browser receives an updated browse list, and new computers on the network do not show up in a user's request for a browse list until after this time.
How the "normal" process stops:
When a user shuts down a computer properly, the operating system informs the master browse server that it is shutting down. The master browser server then notifies backup browse servers that a change to the browse list is available. The backup browse servers then request the changes to the browse list. If a user turns off the computer without shutting down, the computer does not get a chance to send the message to the master browse server. In such cases, the computer name continues to appear in the browse list until the name entry times out, which can take up to an hour.
What can go wrong:
The biggest challenge is avoiding rogue browse masters, which cause havoc on a subnet because they disrupt the browsing process. The WINS resolution process is working properly when all clients register with and query the WINS server directly. This process is broken when a "rogue browse master" has no information about the Windows network resources, and consequently none of the clients on a domain can see any MS Windows network resources.
Windows 3.1 and Windows 95/98 workstations cannot function as browse masters in a Windows NT network because they do not handle NT server and domain information. Unfortunately, by default, Windows 95/98 attempts to become a browse master. A single workstation incorrectly claiming to be the browse master hinders browsing for every computer on that entire subnet. The priority for becoming a browse master is PDC, BDC, NT Server, NT Workstation, then Windows 95/98, which should prevent this from occurring. As outlined in the troubleshooting steps below, the easiest way to find a rogue broadcaster on a subnet is to run the "browstat" Resource Kit (RK) utility on a Windows NT computer on the affected subnet.
Most networks today have several subnets. Domains often span subnets and subnets sometimes contain systems in more than one domain. The browser software on some systems can communicate with a domain master browser (usually the PDC) to exchange browse lists from many subnets, but it needs to know the unicast address of the domain master browser. A subnet master browser can get the unicast address of the PDC from an LMHOSTS file or from WINS.
When a user opens the network neighborhood to request a list of domains, the system will attempt to get a list of backup browsers, either through broadcasting to the master browser name, or directly connecting to the domain master browser (or both). Once a list of backup browsers is retrieved, the system will choose a backup browser, connect to that system and retrieve the list of domains. Subsequent requests for servers within a domain are forwarded to the same backup browser.
The normal "browser process" described above can get "broken" for any number of reasons including:
- The router between VLAN connections is temporarily unavailable for some reason (e.g., due to an upgrade, maintenance work, or any reboot). This action would cause several "local master browser elections" to occur on the newly isolated switch segments. If a PDC or BDC for a given domain is suddenly not present in the new broadcast domain, machines that do not have current information about MS Windows networking resources could be elected as "master browsers".
- A misconfigured MS Windows 95 computer could have recently joined the subnet. The Windows 95 browser service has the capability to act as a subnet master browser for a domain in a routed TCP/IP network. This effectively means that a Windows 95 computer can behave like a Windows NT computer in that it will share the local subnet browse list with the Windows NT Domain Master Browser (DMB). When a Windows 95 computer is elected to become master browser on the network segment, it will contact the Domain Master Browser every 12 to 15 minutes to share browse lists. During this transaction, Windows 95 will request the domain browse list from the DMB, which includes the list of computers in the local domain as well as the list of other domains. Obviously, if the W95 box is misconfigured, and passes this information along to the DMB as authentic, the entire network will be basing its browsing decisions on bad information (possibly with no network resource shares advertised at all).
Without going into too many of the details behind these recommendations, here's a list of things to try if it appears that "Network Neighborhood" browsing is broken on your Windows network. These items focus on the NBT transport, not the other two mentioned above. Please refer to the links below if you want the details behind some of these recommendations (or if you are having trouble sleeping :->).
___Always start with the Physical Layer at the client PC--is the cable connection between the network interface card (NIC) and the port it is connected to secure? Many "big problems" are solved with this simple check.
___Is name resolution working on the local client PC? Try to ping a device by name (e.g., ping niwot.scd.ucar.edu). If that doesn't work, can you ping by IP address (e.g., ping 128.117.8.223)? If you can ping by name and you get a successful reply, it indicates that name resolution is working, and that basic TCP/IP connectivity exists. To verify that both the PDC and the master browser can resolve each other's computer names, map a network drive from the master browser to the PDC and from the PDC to the master browser. If any of these steps fail, resolve the name resolution problem.
___Is the PC client getting their network settings from DHCP? If so, is the DHCP server giving out correct information (i.e., IP address, subnet mask, DNS servers, WINS servers)? Verify this by running the "winipcfg" utility in W95/98 or typing "ipconfig /all | more" at a command prompt in WNT or W2K.
___Does the PC client have one or more network settings "hard-coded?" For example, has someone manually entered an incorrect WINS server? Is WINS enabled for the Windows client manually? Are the WINS server addresses that might have been manually entered correct for the domain the user is trying to browse?
___Are you trying to reach a Samba share via Windows Network Neighborhood? We have found at least one case that indicates that access to Samba shares may require the addition of DNS search suffixes. For example, reaching a Samba share on cyclone.scd.ucar.edu may require that you enter "scd.ucar.edu" as a DNS suffix that will automatically be added when you try to reach shares on this host. We believe this is because, for at least some versions of Samba, when it registers with the WINS server, it only registers what "hostname(1)" returns, whereas Windows hosts register their fully qualified domain names. Thus, when you click on a Windows host in the browse list, implicitly a connection to the fully qualified name is done, but for the Samba host in question, it just tries to connect to the host name (e.g., just "cyclone" and not "cyclone.scd.ucar.edu"). If your DNS is not set up to tack on "scd.ucar.edu", the lookup fails and you can't connect. An alternative to changing your DNS settings is to just map to a share directly using the fully-qualified name explicitly, such as "\\cyclone.scd.ucar.edu\share".
___Can you "find" the computer you are trying use a resource on via the "find computer" options? Can you map a drive to the master browser? This will verify network connectivity.(e.g., by mapping a network drive directly to the resource; either by right-clicking on the "network neighborhood icon" using "net use \\servername\sharename" or "Tools > Map Network Drive" within Windows Explorer)? If you can, then you know your network connectivity is OK and the resource is available, it's just that you're likely experiencing a browsing problem if you can't see a network resource.
___If you don't have the MS Resource Kit utilities available to you, what can you verify by using the "nbtstat" commands at a command prompt? Do you see any obviously incorrect information displayed when you type "nbtstat -c"? Can you correlate the "List of Names Registered with WINS Service" with the output you get from the command "nbtstat -a <yourpdc>"? In the SCD Domain, output from this command might look something like this:
C:\>nbtstat -a grand-nt
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
GRAND-NT <00> UNIQUE Registered
GRAND-NT <20> UNIQUE Registered
SCD <00> GROUP Registered
SCD <1C> GROUP Registered
SCD <1B> UNIQUE Registered
GRAND-NT <03> UNIQUE Registered
INet~Services <1C> GROUP Registered
IS~GRAND-NT....<00> UNIQUE Registered
GRAND-NT <6A> UNIQUE Registered
GRAND-NT <87> UNIQUE Registered
GRAND-NT <6B> UNIQUE Registered
GRAND-NT <01> UNIQUE Registered
SCD <1E> GROUP Registered
SCD <1D> UNIQUE Registered
..__MSBROWSE__.<01> GROUP RegisteredNotice how the line "..__MSBROWSE__.<01> GROUP Registered" indicates "This name is registered by the Master Browser and is used to broadcast and receive domain announcements on the local subnet." Unfortunately, "nbtstat" does not provide a direct way to determine what the "master browser" is for your domain. However, if you run the command indicated above on your PDC (which in most cases should be the "master browser"), and you do NOT see the "__MSBROWSE__<01>" line, that probably indicates another machine is the "master browser" and potentially is the source of your problems.
___If you don't see what you think is a complete "Network Neighborhood" view--what DOES appear there? Is it only your machine (i.e., the one you are currently logged in to)? Is that machine configured with a unique local workgroup name only? Or is it configured to be part of a Windows domain? Usually if you only see the machine you're using, you're either getting the current "browse list" for your local domain (and you're the only one currently in it) or you're not getting a current browse list for the domain you think you've joined. You should verify your local settings are correct and then follow some of the other troubleshooting items listed on this page. Note that you must have the "File and printer sharing for Microsoft Networks" service installed to browse Windows 95 and Windows 98 "peer networks." If a Microsoft Windows NT server is installed on your LAN, it should automatically become the browse master for your network.
___If you are a Windows system administrator, you should have a MS Windows Resource Kit (RK). What do the RK browsing utilities tell you ( e.g., "browstat.exe" or the "browser monitor" from the W2K RK). Here's some steps Microsoft recommends when using the "browstat.exe" RK utility:
- Find the master browser. Using the NT4 RK utility and typing "browstat status" will give you this information. Alternatively, you can use the W2K RK "browser monitor" utility. The "browstat.exe" utility will also allow you to use a variety of other commands--issue "browstat /?" to get a list of them. You'll need to note the "transport" (i.e., the "\Device\Protocol_NIC" string) the utility is using (e.g., "\Device\NetBT_El59x1") so you can use that for the other command options of this utility. The "browstat view" command is particularly useful in listing all the machines in the domain along with their capabilities. This could also be a useful tool in determining which computers might potentially be causing problems (now or in the future).
- Check for the expected master browser on the client's segment (same as for step 1).
- To avoid experiencing intermittent browser functioning and having to perform these tests, you may need to dedicate computers on each segment to maintain a consistent domain-wide list. If servers are frequently shut down and restarted, consider placing a BDC if the number of segments is not large, or at minimum a Windows NT Member Server on each segment with the IsDomainMaster registry setting set to true. This gives the server an edge during elections in becoming the master browser for the segment.
- For all the previous steps, if none of the suggestions allow you to proceed to the next troubleshooting step, verify that none of the browser servers that you have identified have a "name in conflict" error. This can be seen by executing the following: "nbtstat -n" (you can use this command remotely by using either the -A or the -a switch).
___Do you want to verify a browsing-related setting for a Windows operating system? Here's some guidelines:
Windows for Workgroups 3.11 (WFW3.11)
When using WFW3.11, a new browser file, VREDIR.386, which is included with Windows NT 3.5, must be used to allow browsing to work correctly. Windows 95/98 already includes this modified browser. The VREDIR.386 file is typically located in the C:\WINDOWS\SYSTEM directory.
Windows for Workgroups clients should make the following change to the SYSTEM.INI file:
; SYSTEM.INI
;
[Network]
MaintainServerList=No
Windows 95 or 98
For Windows 95/98, turn off the "browse master" setting via "Start > Settings > Control Panel > Network > File and Printer sharing for Microsoft Networks > Advanced > Property > Browse Master > Value=Disabled"
Windows NT 3.51
Windows NT 3.51 workstations and servers that are configured for WINS name resolution do not send broadcasts unless other computers on the network request a browser election. No action is required.
Windows NT4 Workstation and Windows 2000 Professional
For WNT4 Workstation and W2K Professional computers, you can change a registry entry to ensure that machine cannot become a browser. This is done by setting "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters\MaintainServerList" to "No."
___Are there any Windows for Workgroups (WFW) 3.11 or older Windows 95 machines on the subnet? Because of a bug in some versions of WFW 3.11 and W95, these systems cannot function as a subnet master browser or backup browser. The bug prevents the subnet browser from contacting the domain master browser. As a result, browsing on the subnet could fail if there are WFW3.11 or W95 master or backup browsers on the subnet. This bug has been fixed in Windows 95 OSR (OEM Service Release) 2.
___Is there a machine on the subnet (yours?) using an LMHOSTS file? LMHOSTS is a text file that the browser software can read to find the unicast address of a PDC. A sample follows. First is the unicast IP address of the PDC, next the NetBIOS name of the PDC (ENG_PDC), a tag which stores this line in the NetBIOS name cache, (#PRE) and finally, a tag that marks this system as a domain controller for the ENG domain (#DOM).
10.1.3.4 ENG_PDC #PRE #DOM:eng
When a subnet master browser knows the unicast address of the domain master browser, the browsers exchange browse lists every 15 minutes (using IP unicast packets). Because a master browser is consulted, clients can browse only domains that have a system on the local subnet (a subnet master browser). In practice, this scenario works well enough to find a login server at startup, but does not allow users to browse using the network neighborhood.
___Is the WINS server itself configured correctly? This is an item you would probably leave for troubleshooting last, but it might be worth checking if the problems are persistent. Is the WINS server using an LMHOSTS file? If so, is the information contained in that file correct? Is it formatted correctly? Does the WINS server have current and correct DNS server addresses?
A collection of useful URLs relating to Microsoft browsing via Network Neighborhood:
Windows Networking Design Implementation Guide (by Cisco)
Troubleshooting Browsing with Client for Microsoft Networks
8003 Browsing Errors with UDP Forwarding
UDP Broadcast Forwarding by Cisco's IP Helper
Windows 95 Can Share the Windows NT Domain Browse List
Domain Browsing with TCP/IP and LMHOSTS Files
Information on Browser Operation
List of Names Registered with WINS Service
NetBIOS over TCP/IP Name Resolution and WINS
Default Node Type for Microsoft Clients
"Microsoft Windows NT Browser," a White Paper by R. Dan Thompson IV and Randy McLaughlin (in MS Word format)
Microsoft Windows 2000 Professional Resource Kit
Troubleshooting Microsoft Network Neighborhood After Establishing a VPN Tunnel With the Cisco VPN Client (a Cisco document)