WINS solves two problems for browsing in the WAN: the building of a comprehensive domain list and name resolution for members within a domain or workgroup. The following list summarizes issues for browsing in a WAN environment with WINS:
Workgroups still cannot span subnetworks because they have no equivalent to the domain master browser.
The process of building domain lists uses the WINS database and domain\0x1b names to locate the domain master browser. Workgroup lists are still based on members’ announcing their presence periodically. For example, an isolated workgroup on an island subnet with no domain members is invisible to the WAN until a domain member is added that shares the presence of the subnet.
The ability to expand a workgroup or domain depends on the ability to resolve the master browser’s computer name. If WINS-enabled computers are running in workgroups and domains, this is adequate.
The ability to connect to a resource in a workgroup depends on the ability to resolve the resource’s name. Again, WINS-enabled computers support this adequately. It is possible to connect to a resource that you cannot browse and to browse a resource that you cannot connect to.
Tip for browsing with WINS Because of how PDCs register the domain\0x1b entry with WINS, ensure that all clients and servers are members of a domain.
The unique NetBIOS name of domain\0x1b that the 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 NetGetDCName 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 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 <01><02>MSBROWSE<02><01> 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 NetGetAnyDCName calls.
Troubleshooting Browsing
While there is no centralized method to determine if the browse lists across the WAN are complete, there are techniques to determine if the servers on a particular segment are represented in the browse list on a remote segment. These techniques can be applied on all segments throughout the WAN, but the results of these tests can vary due to the roles of the servers changing when browser elections occur. Only if all the servers in a domain throughout the WAN are completely static and no servers come on or off-line, do the results of these tests have meaning over time. The tests described in this section rely on the Windows NT Resource Kit utility Browstat.exe. Example output is for the TCP/IP protocol only. Also, as with most network problem diagnosis, to troubleshoot the browser service the administrator must have full knowledge of the network segment boundaries, switches, and router configurations on the network. For example, if a client on a remote segment does not have a server in its browse list that is located on another segment, it is not advisable start troubleshooting until after the 48-minute cycle described above has passed. Remember that name resolution between all browsers is critical, and it is most important to establish a robust name resolution infrastructure with WINS. For browsing to work, name resolution must be functional.
The following are the steps to take in troubleshooting on the network.
1) Find the master browser on the segment where the server resides.
The following command must be executed on the segment where the missing server resides:
BROWSTAT STATUS
Status for domain on transport \Device\NetBT_IEEPRO1
Browsing is active on domain.
Master browser name is:
Master browser is running build 1381
1 backup servers retrieved from master
\\SmallerServer
There are 100 servers in domain DomainName on transport \Device\NetBT_IEEPRO1
There are 1500 domains in domain DomainName on transport \Device\NetBT_IEEPRO1
This should tell you which server is acting as the master browser on the segment. If the local master browser is slow to respond, you may have received this information from another master browser.
The results of this command gives you the “\Device\Protocol_NIC” string and can be used with other Browstat commands.
To find the local master browser on the client’s segment, execute the following:
BROWSTAT GETMASTER \Device\NetBT_El59x1
Using the Status or Getmaster switch issues a DomainName<1d> query and returns the current master browser for that segment.
Now you must determine which master browser is on the segment that contains the missing server’s name. If a master browser cannot be found, you can force an election by stopping and starting the browser service on a domain controller that is on the server’s segment. In a few minutes, re-run this test. Alternatively, on the console of a server on the server’s segment you can force an election by executing the following command:
BROWSTAT ELECT \Device\NetBT_IEEPRO1 .
2) Does the master browser have the server’s name in its list?
The master browser is the first server in the chain of communication that must contain the missing server’s name. This test determines if the master browser has received the server’s Host Announcement frame. Note that the “\device…” string is obtained from the output above. Execute the following:
BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\> | FINDSTR /i
If the master browser has the server in its list, the command returns something similar to the following:
\\ NT 04.00 (W,S,NT,PBR,DFS)
If the local master browser does not have the server’s name, the following can be executed from any computer on the missing server’s segment:
BROWSTAT FORCEANNOUNCE \Device\NetBT_El59x1
Or the following can be executed from the missing server’s console:
BROWSTAT ANNOUNCE \Device\NetBT_El59x1
It may be useful to verify that the missing server can map a network drive to the master browser to verify network connectivity. Also, the server can be rebooted to force a Host Announcement frame.
3) Does the PDC receive the server’s name from the master browser?
Execute the following:
BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\
> | FINDSTR /i
The output should be similar to the following:
\\ NT 04.00 (W,S,NT,PBR,DFS)
If the server’s name is missing, this is probably due to name resolution problems. For the PDC to obtain the list of servers from the master browser, the server’s master browser must be able to resolve the DomainName<1b> name so that it can send the directed Master Announcement frame, using UDP port 138. For the PDC to respond to this announcement to obtain the server’s name, it must be able to resolve the master browser’s computer name. (For the server’s master browser to obtain the domain-wide list from the PDC, it too must be able to resolve the PDC’s computer name.) Name resolution in both directions is critical. To verify that the server’s master browser can resolve the DomainName<1b> entry, execute the following:
BROWSTAT GETPDC \Device\NetBT_El59x1
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.
4) Which is the master browser on the client’s segment?
This is done using the same steps as in number 1 above, but is executed on the client’s segment.
5) Does the master browser have the missing server’s name?
Execute the following:
BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\> | FINDSTR /i
If the server has the entry, the output should be similar to the following:
\\ NT 04.00 (W,S,NT,PBR,DFS)
If the master browser does not have the missing server’s name, it is probably due to a name resolution problem. Verify that the master browser on the client’s segment is able to resolve the DomainName<1b> name by executing the following:
BROWSTAT GETPDC \Device\NetBT_El59x1
The master browser must be able to resolve the computer name of the PDC. To verify this, map a network drive to the PDC. If either of these tests fail, resolve the name resolution problem.
6) Which are the backup browsers on the client’s segment?
To reduce demands on the segment master browser, when a client requests a browse list, it chooses a backup browser, if one is available. Therefore, it is more likely that all clients will use backup browsers. There are two ways to determine the local backup browsers for this segment. From the master browser’s console, execute the following:
BROWSTAT LOCALLIST \Device\NetBT_IEEPRO1 | FINDSTR /i BBR
This returns a list of entries similar to the following:
\\ NT 04.00 (W,S,BDC,NT,BBR,DFS)
To have the master browser perform this command remotely, execute the following:
BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\ 0X40000000 | FINDSTR /I BBR
Note: These flags are defined in Appendix H.
7) Do the backup browsers have the missing server’s name?
For all clients on this segment to retrieve a reliable browse list, every backup browser must be checked for the missing server’s name. For each backup browser, execute the following:
BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\ | FINDSTR /i
If a backup browser does not contain the missing server’s name, verify that the backup browser can map a network drive to the master browser. The backup browser role is the most dynamic browser role. Master browsers instruct potential browsers to become backup browsers, depending on the browser load.
8) Other considerations:
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 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
This command can be performed remotely by using either the –A or –a switch.
The browser is very sensitive to the configuration of the routers throughout the WAN. Since the browser roles are determined by broadcast elections, UDP broadcasts must not be forwarded. Unpredictable behavior can occur if UDP broadcast traffic is forwarded in one direction but not the other. This may generate 8003 Browser events, causing a continuous cycle of elections.
Additionally you can resolve problems with a protocol analyzer such as the Microsoft Network Monitor. To view the browser exchanges directly, the browser service can be stopped, and then restarted. Unfortunately, there is no guarantee that a browser will assume the same role that it had before stopping and starting the browser service. However, this method can be especially useful to verify the communication when the master browser requests the domain-wide list from the PDC, and immediately following when the PDC requests the local list from the master browser. After the browser service has started on the master browser, the full exchange should take place within one or two minutes. Configure the protocol analyzer’s capture buffer and frame size settings to allow for this quantity of traffic. The list of servers returned by the browse service prior to Windows NT 4.0 was limited to 64 KB in size. When this size is exceeded, the user sees a truncated alphabetical list of servers. To avoid this behavior, all browsers must be running Windows NT version 4.0 or later.
For More Information
For the latest information on Windows NT Server, visit our World Wide Web site at http://www.microsoft.com/ntserver and the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).
|
