Microsoft Corporation
July 1996
All computers are on the same wire in the LAN environment, so a user can browse all workgroups and domains because the network client can communicate directly with all master browsers. Multiple workgroups and domains can coexist on a LAN without incident, because both the unique and group NetBIOS names depend on the name of the workgroup or domain.
Name resolution becomes more complex in the WAN IP environment, however, because the broadcasts and messages used for name resolution are not automatically forwarded across routers on TCP/IP networks.
Tip for browsing on IP networks The single most important key to successful browsing using Microsoft networking, whether or not the network includes WINS, is to segment the network so that all clients and servers involved in browsing are members of domains.
This section summarizes name resolution issues related to WAN browsing, depending on whether Microsoft® Windows NT® WINS servers are available in the enterprise.
Microsoft TCP/IP uses NetBIOS over TCP/IP as specified in RFC 1001/1002, which defines a software interface that supports name resolution for NetBIOS client and server programs in the WAN environment. All Microsoft networking products use NetBIOS over TCP/IP for registering and locating NetBIOS resources on IP networks. The various methods used for name resolution include the following:
The order of methods used for NetBIOS name resolution depends on the node type (as defined in RFC 1001/1002) and the particular computer configuration for TCP/IP. These are the node types:
If WINS is enabled on a computer running Microsoft Windows® 95, the system uses h-node by default. Without WINS, the system uses b-node by default. To see which node type is configured on a computer running Windows 95, check the value for NodeType in the following Registry key:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
Figures 1 and 2 summarize the methods for attempting name resolution with Microsoft TCP/IP.
Figure 1. Method for attempting name resolution
Figure 2. Resolving computer name and host name with NetBIOS over TCP/IP
Some TCP/IP utilities, such as ping, can use host names instead of IP addresses by using the Windows Sockets GetHostByName() application programming interface (API) function. The following is the sequence used for name resolution in such cases:
If this method is used, the host name is converted to a NetBIOS name by padding the name with spaces up to 16 bytes and making the sixteenth byte a zero to refer to the other computer's redirector.
If the computer is configured to use WINS, a second DNS search occurs if WINS fails, because the application accesses WINS by way of NetBIOS over TCP/IP, which automatically uses DNS if WINS fails.
In a WAN environment that requires TCP/IP name resolution, Microsoft networking relies on NetBIOS over TCP/IP (RFC 1001/1002) packets. Although some environments forward these broadcasts across routers, most do not. As a result, WAN browsing over TCP/IP is different from LAN browsing.
Tip for browsing without WINS After ensuring that all computers are members of a domain, the single most important key to successful browsing without WINS is to ensure that each subnet has a master browser or primary domain controller (PDC) present. This is because only the local master browser on each subnet receives local subnet membership announcements. The local browse master can be a computer running Windows 95 on any subnet that does not include the domain's PDC.
In a domain, the election of a master browser happens on each subnet, following the same basic election scheme as in the LAN environment, and the PDC always acts as the domain master browser. For TCP/IP WAN browsing to occur, the local master browser must be made aware of the membership list for the entire domain, and this WAN-wide membership list needs to be consolidated into each local master browser's membership list. The domain master browser is responsible for the consolidation and replication of the WAN-wide membership list to each master browser. Periodically, all of the locally elected browsers contact the domain master browser to replicate their membership lists. The domain master browser merges these lists with the "master" list for the entire domain and replicates the master membership list back down to the local master browsers.
The replication algorithm replicates to the master browsers only those members that the master browser did not learn about locally. This allows members in a domain to span subnets and allows all clients to receive complete membership lists.
Because IP subnetworks are not bridged automatically, all browser elections and announcements happen as described earlier for LAN environments. The following summarizes the limitations for name resolution in the WAN environment without WINS:
However, it is possible to connect to a resource you cannot browse (for example, connecting to a share name that ends with the $ character) and to browse a resource you cannot connect to (for example, enumerating a share for which you do not have proper access rights).
To guarantee that the master browser for each subnet can access the PDC for the domain, the domain's PDC must be listed in each browser's LMHOSTS file. To guarantee that the PDC can request the local subnet's list from the master browser on that subnet, the client addresses must be cached for some period of time. However, computers will not appear in the browse list if they are members of the domain but are on a subnet that does not have a master browser and does not include the domain's PDC.
The following defines the conditions necessary for ensuring that browsing works in WAN environments that do not include WINS.
If each subnet in the domain includes a Windows NT Server computer. No specific configuration steps need to be taken within a domain, because the domain master browser and backup browsers automatically maintain the domain browse lists. The browsers' LMHOSTS files need to include address mappings for PDCs in other domains.
If some subnets in the domain do not include a Windows NT Server computer. For each subnet that does not include a Windows NT Server computer, the following must be true:
If a subnet includes only Windows 95 but no members of domains that span subnets. Users in such an isolated subnet cannot browse computers in a workgroup or domain on any other subnet, and users on other subnets cannot browse the computers on the isolated subnet. For users on these subnets to browse each other's computers, one computer on the isolated subnet must be a member of a domain on the other subnet and also must be configured as a master browser with appropriate LMHOSTS entries as described in the previous case.
To understand what the user sees when browsing subnets without WINS available, consider this example where all members of workgroup A are located on subnet 1 and all members of workgroup B are located on subnet 2. The subnets are connected using a router. Master browsers are elected for each subnet, but workgroup announcements to the special name of \0x01\0x02_MSBROWSE_\0x02\0x01 do not pass across the router. Therefore, clients on subnet 1 see only workgroup A in their browse list and cannot see workgroup B and its membership list.
Figure 3. Workgroups on different IP subnets without WINS or domains
In the UNIX environment, the HOSTS file ensures access to other hosts across routers. In LAN Manager 2.1, Microsoft adopted a similar convention with the LMHOSTS file, which maps computer names to IP addresses. However, merely adding an entry for a server to the LMHOSTS file does not ensure that a server appears in the membership list, because connecting to a network resource does not require knowledge of the workgroup or domain, but it is required for the compilation of a membership list. So, domain or workgroup browsing and name resolution are unrelated activities in this scheme.
Using LMHOSTS in the previous example, workgroups A and B cannot see each other, but a domain that spans both subnets can see both workgroups from either subnet, because domains can span routers in a WAN environment.
In the previous example with workgroup A and workgroup B on separate subnets, notice that when you introduce a domain named Domain_C on both subnets, a master browser is elected locally on both subnets for Domain_C. The PDC (named PDC_domC in the following illustration) included on one subnet is the domain master browser, which is also a master browser; the other subnet will have a master browser for Domain_C. These two local browsers learn about workgroups A and B through local broadcasts and about exchange lists using the domain master browser. Therefore, any client of Domain_C will see all servers on subnet 1/workgroup A and subnet 2/workgroup B. As long as both the client and server computer names can be resolved using local broadcasts or LMHOSTS, the clients can connect to the listed servers.
Figure 4. Browsing without WINS using domains
In the configuration in Figure 4, the browse master on subnet 1 can be a computer running Windows 95 if no computers running Windows NT are present. In this example, in subnet 1, the browser master's LMHOSTS file must contain an entry similar to the following, specifying the IP address of the PDC:
102.54.94.97 PDC_domc #PRE #DOM:Domain_C
The special flag #PRE ensures that this mapping is loaded in the computer's name cache whenever the system is started. The #DOM flag specifies a domain controller.
Master browsers must be domain controllers for TCP/IP WAN-wide domain browsing, because for replication of the membership list to occur, the master browsers must be able to find and connect to the domain master browser (which is the PDC). To do this, several things must happen. First, the local master browsers need to learn the name of the PDC using the GetDCName() API function, which relies on the LMHOSTS file to distribute datagrams to all domain controllers in the domain. One of the domain controllers makes the call, and the name of the PDC is learned.
After the local master browser has the name of the PDC, the LMHOSTS file is used to resolve the name of the PDC into an address so that a connection can be made. The computer name-to-IP address mapping for the PDC must also be located in the LMHOSTS files on all local master browsers and potential master browsers. With this done, all clients of the domain on all subnets can connect to the local master browser (or backup browser) and receive a list of all of the members of the domain, regardless of location on the WAN.
When more domains and workgroups are added to the WAN environment, local master browsers learn of them as domains and workgroups announce themselves by using the name \0x01\0x02_MSBROWSE_\0x02\0x01 broadcast only to the local subnet. Each master browser builds a table of domains and workgroups with a membership list for each and then replicates the same table up to the domain master browser.
Therefore, WAN browsing for each client in the original domain is possible if these additional workgroups and domains are not isolated on a subnet. The original domain's membership list includes the domain and workgroup name and the master browser name, so the clients of this domain can expand any of the visible domains or workgroups into a membership list if the master browser for the particular domain or workgroup is defined in the LMHOSTS file.
In the final example for a non-WINS environment, Domain_C spans 3 subnets, and the PDC for Domain_C is on subnet 1. Subnet 2 includes a backup domain controller for Domain_C, and subnet 3 includes a Computer running Windows 95 that is a member of Domain_C and is configured to be a browse master. Subnet 3 also includes computers that belong to a domain named Domain_D, and the PDC for that domain is on yet another subnet.
When the browse master for subnet 3 (a computer running Windows 95) sends the list of servers on its local subnet to the PDC for Domain_C, it also sends a list of domains in its subnet, including Domain_D. So the PDC for Domain_C has a list of domains that includes Domain_D. When the browse master for subnet 2 gets the browse list from the PDC, it includes Domain_D on the list of known domains. When a client on subnet 2 requests the list of servers in Domain_D, it sends the request to the subnet 2 browse master, which in turn can contact the browse master for Domain_D on subnet 3 — but only if the IP address for the browse master on subnet 3 is stored in the LMHOSTS file on the browse master for subnet 2.
Figure 5. Relating subnets and domains
In this example, the following LMHOSTS entries will ensure that computers in each subnet and domain can see each other:
102.54.94.98 pdc_domC #PRE #DOM:Domain_C #preload PDC for Domain_C
102.54.86.24 pdc_domD #PRE #DOM:Domain_D #preload PDC for Domain_D
102.54.94.96 bm_s2domC #PRE #subnet 2 browse master
102.54.94.94 bm_s3domC #PRE #subnet 3 browse master, Domain_C
102.54.94.90 bm_s3domD #PRE #subnet 3 browse master, Domain_D
| For more information about | See |
| LMHOSTS syntax and special keywords for specifying domains, including other LMHOSTS entries | Appendix G, "HOSTS and LMHOSTS Files for Windows 95," in the Microsoft Windows 95 Resource Kit (Microsoft Press, 1995), p. 1227, U.S. ed. |
WINS solves two problems concerning browsing in the WAN: the building of a comprehensive domain list and name resolution for members within a domain or workgroup. The following summarizes issues for browsing in a WAN environment with WINS:
Tip for browsing with WINS: Because of the way PDCs register with WINS, the key to successful browsing is to ensure that all clients and servers are members of a domain. In addition, a few computers running Windows 95 or other networking computers running Windows can be configured as WINS proxies to assist name resolution for non-WINS computers on the network.
The unique NetBIOS name of domain\0x1b that PDCs register is treated specially by WINS and is used to build a table of all domains on a WAN network. The browser on the client periodically connects to WINS and learns of all the systems that registered the domain\0x1b name. The browser then uses a GetDCName() call on each of the domain\0x1b names, followed by an attempt on the domain\0x1c names. The browser then adds the domain master browser's name to its domain and workgroup list. This eliminates the need to strategically place workgroup or domain members on subnets to ensure that comprehensive domain and workgroup lists are built.
With WINS, the domain\0x1e name registration is ignored and basically treated as a normal group name. This forces browser elections to remain on subnetworks rather than extending elections to the WAN. This increases fault tolerance and reduces periodic network-wide traffic. The same is true for the domain\0x1d and \0x01\0x02_MSBROWSE_\0x02\0x01 group names. This also reduces the scope of the announcement broadcasts on the subnetwork. The unique domain\0x1b name and the internet group domain\0x1c name are maintained by WINS and are used during logon and for GetDCName() calls.
Figure 6. Internetwork with WINS servers and WINS proxies
Notice that for networks that use WINS, a computer running Windows 95 plus Microsoft TCP/IP can be configured to act as a WINS proxy by specifying EnableProxy=1 in the following Registry key:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
A WINS proxy is a WINS-enabled computer that passes name query packets from non-WINS computers and verifies that name registrations do not duplicate existing entries in the WINS database. Proxies do not actually register b-node systems in the WINS database. It is recommended that only two computers be configured as WINS proxies in each subnet to help ensure that non-WINS computers can resolve names by using broadcasts.