Browsing WANs using WINS

WINS acts as a directory service for NetBIOS names and IP addresses. The use of WINS can improve browsing for wide area networks through the following enhancements:

• WINS-enabled clients can directly query their configured WINS server for NetBIOS names used to implement browsing and domain services.
• If a domain master browser is a WINS-enabled client, it queries WINS periodically (every 12-15 minutes) to obtain a list of all domains stored in the WINS database.

These enhancements make it possible for WINS to assist in fully browsing the entire network and resources shared in remote domains. The process of implementing this enhanced browsing involves the use of WINS in two ways:

• Names for remote domains are registered in WINS and replicated to all WINS servers used in the network.
• WINS-enabled clients use a modified process of WINS query and directed communication with computers in the remote domain to obtain browse list information about servers and shared resources in these remote domains.

How remote domains register in WINS

For example, as shown in the following graphic, three PDCs for three separated domains (ADMIN, FINANCE, MIS) are operating as domain master browsers for their respective domains. All of these computers are WINS-aware computers running as WINS clients.

When each of the PDC computers starts for its domain, it registers the [1b] name for the domain with its preferred WINS server. For example, in the ADMIN domain, the computer PDC-ADMIN registers its IP address (192.168.1.2) as the domain master browser. These [1b] names then appear at other WINS servers as WINS database replication occurs in the routed network.

Because each of the four PDC computers operating as the domain master browser for their respective domains are configured to use WINS, they query WINS every 15 minutes to update their respective browse lists to include all other domains used in the network. Once all domains are registered in WINS, domain master browsers operating locally for each domain can use a two-part process to query the WINS server and discover remote domains:

1. The local domain master browser does a wild card query of WINS for domain names ending with a name suffix of [1b].

   Note that the result of this query--a list of domain names--only contains the names and a single IP address corresponding to the domain master browser (or PDC computer) for the domain. It does not contain all of the names of master browsers for each domain, as would normally be obtained if the remote domains had member computers located on the same subnet. For domains active on the local subnet, this information is normally obtained through master browser announcements that are broadcast to the local subnet.

2. To obtain a master browser for one of the remote domains, the local domain master browser does a reverse query based on the IP address returned for each remote domain [1b] name collected in step 1.

   The reverse query is used to learn the name of the computer that registered the remote domain name. In this way, the local domain master browser completes its list of remote domain names and their corresponding domain master browsers.

 Note

• Only WINS-aware domain master browsers (those in Windows NT Server 3.5 or later) register their domain [1B] names with the WINS server and perform enhanced WINS queries for learning about remote domains. Domain master browsers running Windows NT Server 3.1 do not use WINS.
• This information describes browsing enhancements for server and client computers that are WINS-aware. For more information about specific differences in browsing service for different versions of Windows operating systems, see Microsoft Support Online.

Browsing remote domains with WINS clients

In wide area networks, the use of a replicated WINS database that contains reference information about each of the domains can assist WINS-enabled clients in browsing remote domains.

As described earlier, NetBT clients can use broadcasts to their local subnets for <domain> [1D] names. When this happens and the domain is located at a remote subnet or site, the query fails. Under these circumstances, browsing is not possible unless special configurations are made and maintained. Without WINS, each domain master browser would need static information entered in an Lmhosts file to further process a client request. This requires careful administration to maintain and update static Lmhosts files at each domain master browser in the enterprise.

With WINS, clients can leverage the replicated names database more effectively and administrators can eliminate reliance on Lmhosts management. The process used by WINS clients to resolve a browser request for a remote domain name is different from the process used by non-WINS (NetBIOS broadcast-only) computers or to obtain information about local domains that are present on the same subnet.

Example: How WINS clients obtain remote domain browse lists

The following graphic shows how a WINS client located in Sydney, SYD-PC-2, is able to obtain browse list information about the remote SEA domain located in Seattle:

1. After the WINS client (SYD-PC-2) fails to locate a master browser for SEA domain using a broadcast for the [1D] name, it queries its configured WINS server (SYD-WINS1) for the <SEA> [1b] name.

   The [1B] query is used to learn the IP address of the domain master browser (the PDC) for the remote domain. If all PDCs are configured to use WINS as described earlier in How remote domains register in WINS, the queried names should be present in the replicated WINS database.

2. The WINS server resolves the request for "SEA [1B]" and returns the answer to the client.

   The WINS response includes the IP address of SEA-PDC, the domain master browser for the remote SEA domain to the client.

3. The client then uses the IP address to send a direct request to SEA-PDC to obtain a list of backup browsers for the requested domain.
4. The remote domain master browser (SEA-PDC) responds with a list of up to three backup browsers for the requested SEA domain to the client.

   For this example, the list of backup browsers returned by SEA-PDC includes the computer names of SEA-BB1, SEA-BB2 and SEA-BB3.

5. The WINS client then randomly selects one of the backup browsers from the list and queries WINS again.

   For instance, if the client randomly selects SEA-BB3, it then attempts to have WINS resolve the name "<SEA-BB3> [20]" to get the IP address of this computer.

6. The WINS server resolves the request for "SEA-BB3 [20]" and returns the answer to the client.

   The WINS response includes the IP address of SEA-BB3, the selected backup browser for the remote SEA domain to the client.

7. The client then sends a request directly to the backup browser, SEA-BB3, located within the remote domain in Seattle, requesting a copy of the browse list for the SEA domain.
8. The remote backup browser then returns the browse list for the remote domain to the client.

If WINS query for the remote domain fails

In some instances, the WINS client can receive a negative name response from the WINS server during step 2 of the previous process, changing how the client attempts to request and obtain browse list information for the remote domain.

Some reasons for a negative response from a WINS server include:

• The remote [1b] name queried was found to be for a workgroup, not a domain.
• The PDC for the remote domain is not a WINS client.
• The PDC for the remote domain is a WINS client, but the PDC and the browsing client are not sharing a common WINS database (replication is not occurring).

In this case, the WINS client does the following:

1. It makes a connection with its local master browser (on the same subnet as the client) and requests the name of the master browser of the desired domain or workgroup.
2. The local master browser returns the name of the master browser that advertised the domain or workgroup.
3. The client resolves the unique name of the <master_browser> [20] that advertised the domain or workgroup.
4. The client then makes a connection with that master browser to request a list of servers in the domain or workgroup.
5. The list of servers in the domain or workgroup is returned to the client.