The IBM i NetServer Does Not Appear in Microsoft Windows Network Neighborhood

Resolving The Problem

This document is presented 'as-is'. Whether computers (including IBM i NetServer) show up in Windows Network Neighborhood or Network Places, is mostly related to how the Microsoft network is configured. The only thing that can be done from an IBM i perspective, is to make sure that NetServer is set to send browse announcements. Everything else is related to Microsoft Network Configuration.

A common problem is for some or all PCs on a network to not be able to see the IBM i NetServer in Network Neighborhood. These PCs may still be able access NetServer using Search for Computer (or Find Computer) or the Net Use command on the NetServer name or TCP/IP address. Network Neighborhood uses the Microsoft Windows Browser service to locate PCs and servers that are active on the network and display them to users. The IBM i NetServer does not have a role in browsing other than to send a broadcast announcing it is present.

A separate issue is whether the Windows PCs are able to successfully resolve the NetServer name to its TCP/IP address. The NetBIOS name resolution process is relatively complicated and varies depending on the type of Windows operating system, how it is configured, and how the Windows network is configured. NetBIOS name resolution is a function of the Windows network.

If NetServer does not show up in Network Neighborhood, try locating NetServer using Windows Find Computer or Search for Computer on the NetServer name. If NetServer is found by name but does not show up in Network Neighborhood there may be a problem with Windows browsing. See the sections below regarding Browsing. If NetServer is not found by name but is found by TCP/IP address, there may be a problem with the Windows name resolution on the network. See the sections below regarding NetBIOS name resolution.

NetServer Property 'Browse Announcement Interval'

For a PC or server to show up in Network Neighborhood it must broadcast browse announcements out to the Network. By default IBM i NetServer does this. This option is configurable in the System i Navigator NetServer properties by expanding the system name, expanding Network, expanding Servers and double clicking on TCP/IP. When NetServer is shown on the right, highlight it, and right-click. Select the Advanced tab and locate Browse Announcement Interval. This specifies the current browse service announcement interval, in seconds or minutes. A value of zero specifies that no browse service announcements are made. A communications trace will confirm if NetServer is sending out broadcast announcements. Contact your Support representative if there is a question on this.

To resolve issues with NetServer not showing up in Network Neighborhood due to browsing on a Network, an understanding of TCP/IP subnetting and of Microsoft networking functions is needed. This process can be quite complex in networks that span multiple TCP/IP subnets.

Browsing on a Single Subnet

Verify that the PC and NetServer are in the same workgroup (domain name) and the same subnet. This will help NetServer to show up in Network Neighborhood. The NetServer domain name property can be accessed by using Operations Navigator. Expand the tree through Network, Servers, TCP/IP, NetServer and select properties. After verifying the domain name, restart NetServer. It may take 15 minutes or more before the system appears in Network Neighborhood. There can be multiple workgroups in the subnet but there must be at least one PC capable of being a master browser in the same workgroup as the system.

Browsing with WINS Configured

If the NetServer is configured to use WINS, verify that the WINS server TCP/IP addresses are correct. If the NetServer uses a different WINS server than that of the failing PC, verify that replication between the WINS servers is configured and working. For information on how to configure a Microsoft WINS server, please contact Microsoft.

Browsing Across Multiple Subnets

TCP/IP browsing (Network Neighborhood) across multiple subnets without using WINS is a complex process. Whether a PC will be able to locate NetServer on a different subnet is dependent on the Network configuration. The NetServer has no role in browsing other than to send a broadcast announcing it is presence on the network. Because the Computer Browser Service is implemented only on Microsoft products, you will need to consult your Microsoft networking documentation for information on how to configure browsing in a TCP/IP network that uses multiple subnets. Some of the Microsoft resources that may be helpful include:

o	Microsoft NT® Server Resource Kit
o	Microsoft Knowledge Base Article ID: Q102878 - Information on Browser Operation
o	Microsoft Knowledge Base Article ID: Q150800 - Domain Browsing with TCP/IP and LMHOSTS Files

IBM i NetServer NetBIOS Name Resolution

This section describes a quick method using an LMHOSTS file on the PC to verify that the PC is resolving the NetServer's NetBIOS name to the correct TCP/IP address. If Windows Find Computer or Search for Computer is able to locate NetServer using the TCP/IP address but not the NetServer name, there is a NetBIOS name resolution issue.

Note: NetBIOS name resolution uses the LMHOSTS file not the HOSTS file.

For informational purposes only, this section also lists the entire name resolution process used by Microsoft Windows NT. Adding the NetServer name to a DNS server and/or a WINS server on the network will help resolve the NetServer name on the Network and using an LMHOSTS file may not be necessary. See the section below on Microsoft's methods of resolving NetBIOS names.

This process creates the correct NetServer entry in the PC's NetBIOS name cache. Since this is the first method used by the PC to resolve a NetBIOS name (with all node types), it will prevent any other PC configuration error from interfering.

1.	Create a LMHOSTS file entry with the #PRE keyword. First locate or create the LMHOSTS file. In Windows NT, this file must be placed in the path: \<systemroot>\SYSTEM32\ETC. In Windows 9x, it is in the \<windows> directory. If the file does not exist, then copy the LMHOSTS.SAM file to LMHOSTS. Note: There must be no extension on the LMHOSTS file. Make an entry as follows: 1.1.1.1 QAS400B #PRE where 1.1.1.1 is the system's TCP/IP address, QAS400B is the NetServer Name, and #PRE indicates the entry should be preloaded.
2.	NBTSTAT -R At a command line, type NBTSTAT -R. This flushes the LMHOSTS cache and reloads it with the new information from the LMHOSTS file. You can use the NBTSTAT -c command to view the cache and verify that the NetServer name appears in the cache and has the correct TCP/IP address.
3.	NET VIEW \\QAS400B The NET VIEW command run against the NetServer name can be used to verify that the connection can be made to the system. The Find Computer or Search for Computer command may also be used to the connection. If the connection still fails, then: From a command line on the PC, type NBTSTAT -c to verify that the NetServer name and TCP/IP address are correctly entered into the cache. PING the TCP/IP address to verify that you entered the correct TCP/IP address. Use Navigator to verify that the NetServer is configured and running.

Microsoft Methods of Resolving NetBIOS Names

Windows NT can be configured to use the following methods to attempt to resolve a NetBIOS name to an TCP/IP address. In addition to the configuration options mentioned in this chart, the Windows NT node type also can affect the search order. Node types are configured either through DHCP or by editing the registry. Node information is included at the bottom.

1.	NetBIOS Name Cache Use the NBTSTAT -c command to view the cache. The cache contains previously resolved names and preloaded names (LMHOSTS entries with the #PRE keyword).
2.	NetBIOS Name Server (WINS) If a WINS server is configured for the PC, then three attempts are made to contact the WINS server.
3.	Broadcasts If the name has still not been resolved, the client attempts three broadcasts (which are usually confined by the router to the subnet).
4.	LMHOSTS File The LMHOSTS file is parsed (top to bottom in case of duplicates). It must be in the proper directory: winnt\system32\etc for NT or windows for Windows 9x. This step can be disabled. See node type below.
5.	HOSTS File Windows NT: If the Enable DNS for Windows Resolution check box is enabled in the WINS Address property page, the PC will attempt to resolve the name using host name resolution. The HOSTS file is the first step in that process. Windows 9x: You can check if this is enabled by using the WINIPCFG.EXE program. To be determined as to where it is configured.
6.	DNS Server Windows NT: If the Enable DNS for Windows Resolution check box is enabled in the WINS Address property page, the PC will attempt to resolve the name using host name resolution. DNS is the next step in that process. Windows 9x: You can check if this is enabled by using the WINIPCFG.EXE program. To be determined as to where it is configured.

Controlling the Resolution Order
The order of resolution is controlled by the node type. There are five different nodes but only two are typically used. (See RFC 1001/1002 for details.)

To view the node type:

Windows NT/2000: Use the IPCONFIG /ALL command.
Windows 9x: Use the WINIPCFG.EXE program.

To set the node type:

Default: By default, if a WINS server is configured, the client uses H-node. If no WINS server is configured, the client uses Microsoft enhanced B-node (not in RFC).

Registry: Use the registry entry (NT) HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters. The values are: x1 B-Node; x2 P-Node; x4 M-Node; x8 H-Node.

DHCP: DHCP can assign a specific node type to the client.

Node Definition

H-node (Hybrid): The default node type if WINS is enabled. The client attempts to use WINS first then broadcasts (the process is shown above).

Microsoft enhanced B-node: The default if WINS is not configured. The process shown above except that WINS (step 2) is not used.

B-node: This is not normally used with a Microsoft client; however, should someone force this setting (via DHCP or regedit), then the WINS server and the LMHOSTS file are not used. Only the NetBIOS cache, broadcasts and DNS (if configured) will be used to resolve NetBIOS names.