If the remote client requires to browse remote network shares or log on to a remote Windows Domain it will fail to do so if left to it's default settings.

The remote client must be configured with either a LMHOSTS file, utilize WINS, or utilize DNS.

Windows 9x/Me/NT clients utilizes NetBios over TCP/IP to communicate to other clients and servers on the network.

When these type of hosts require to find shared resources or even log on to the Domain they use NetBios over TCP/IP to obtain a browse list so they can resolve the NetBios names of the resouce. This is similar to resolving DNS names to IP address.

NetBios over TCP/IP clients operate in different modes:

When using b-node, broadcasts are used for both name registration and name resolution. On a TCP/IP network, if the IP router is not configured to forward the name registration and name query broadcasts, systems on different subnets will not be able to see each other since they will not receive the broadcasts. B-node name resolution is not the best option on larger networks because its reliance on broadcasts can load the network with broadcasts.

When using p-node name resolution, broadcasts are NOT used for name registration or name resolution. Instead, all systems register themselves with a NetBIOS Name Server (NBNS) upon start up. The NBNS is responsible for mapping computer names to IP addresses and making sure that no duplicate names are registered on the network. All systems must know the IP address of the NBNS, which is equivalent to a WINS Server. If the systems are not configured with the correct IP address for the NBNS, p-node name resolution will not work.

The main drawback of p-node name resolution is that if the NBNS cannot be accessed, there will be no way to resolve names and thus no way to access other systems on the network.

M-node uses a combination of b-node and p-node for name resolution. This method first uses b-node and then p-node, which in theory should increase local area network (LAN) performance. M-Node has the advantage over p-node in that if the NBNS is unavailable, systems on the local subnet can still be accessed through b-node resolution.

M-node is typically not the best choice for larger networks because it uses b-node and thus results in broadcasts. However, when you have a large network that consists of smaller subnetworks connected via slow Wide Area Network (WAN) links, M-node is a preferred method since it will reduce the amount of communication across the slow links.

H-node name resolution also uses both b-node and p-node, however it only uses b-node as a last resort. When configured to use h-node, a system will always first try to use p-node and then use b-node ONLY if p-node fails. In addition, a system can be configured to use the LMHOSTS file after p-node fails and before trying b-node.

H-node resolution does not require successful p-node registration for a system to initialize, however the system will use strictly b-node until p-node registration succeeds. If the NBNS is unavailable and the system resorts to using b-node resolution, it will continue to attempt to contact the NBNS so that it can return to using p-node if the NBNS becomes available.

Without WINS, you need special LMHOSTS entries that designate who all the domain controllers are. This is done in the following convention:

199.199.199.1 ComputerName #PRE #DOM:DomainName

When a computer is booted, it reads these entries and store them permanently in the NetBIOS name cache until the computer is powered down. (Because of this, it is best that these entries are last in the LMHOSTS file, for subsequent LMHOSTS parsing efficiency.) All computers in the domain needs one of these entries for each domain controller (in the local domain), as well as one for the PDC. Also note the exact order of #PRE #DOM, and that they are capitalized. The other names are not case sensitive.

The LMHOSTS file should be created in the following directory:
Windows 9x/ME
C:\Windows (the folder where Windows is installed)
Windows NT and Windows 2000
%SystemRoot%\System32\Drivers\Etc

Note that there will be a sample file called "LMHOSTS.sam". If you edit this file you must save it without the file extension.

Having the above entries is sufficient for a Windows NT computer: Upon becoming a Segment Master Browser, a Windows NT computer determines who the PDC is by sending a query (using the NetGetDcName API) to all LMHOSTS entries with the #DOM: designation. Only the PDC responds. The Windows NT computer then contacts the PDC, informs the PDC that it is a master browser, then continues the process of getting the domain browse list. The PDC then contacts the Windows NT computer to get its local segment browse list. This process repeats every 12 to 15 minutes.

These do not perform the NetGetDcName API, so they need entries in the LMHOSTS file that indicate who the PDC is. Assuming the example above is the PDC of the domain, you would have two entries for a Windows 95 or Windows for Workgroups client:

199.199.199.1 controller1 #PRE #DOM:domainname
199.199.199.1 "domainname,,,,,\0x1b" #PRE

The first entry allows the PDC to act as a logon domain controller for the client, the second entry allows the client browser service to explicitly find the PDC. Remember you will probably have multiple lines similar to the first line (for multiple domain controllers), but only one line with the \0x1b directive (to designate the PDC). Note that the domain name must be in quotes, and padded with spaces for a total of 15 characters before the \0x1b portion. (The example above shows commas for visual placeholders, however in a real LMHOSTS file these commas would be replaced with spaces). Also be aware that moving the PDC role to another Windows NT Server (via promotion) will cause your \0x1b entry to be invalid. Options to fix this:
Switch IP addresses on the controllers, so effectively the PDC always has the same address. You would not need to change anything in the LMHOSTS file.

Change the \0x1b IP address in all the LMHOSTS files on the clients, or on the centrally distributed LMHOSTS file (if you are implementing that).

Your domain name is "Globe", your PDC NetBIOS name is "Mongo", and you have other various backup domain controllers. Your LMHOSTS file would look like this:

199.199.199.1 "globe \0x1b" #PRE
199.199.199.1 mongo #PRE #DOM:globe

"nbtstat -R" purges and reloads the remote cache name table. To verify that you've entered these correctly, open a command window (DOS prompt) and look at your NetBIOS cache:

c:\> nbtstat -R

Successful purge and preload of the NBT Remote Cache Name Table.
c:\> nbtstat -c

NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]
------------------------------------------------------------
globe <1B> UNIQUE 199.199.199.1 -1
MONGO <03> UNIQUE 199.199.199.1 -1
MONGO <00> UNIQUE 199.199.199.1 -1
MONGO <20> UNIQUE 199.199.199.1 -1

When a WINS server is installed and the WINS clients are configured, WINS name registration will occur automatically. When the WINS clients starts it will automatically send it IP address and NetBios name to the configured WINS server. NetBios name resolutions will be processed by the WINS server.

By default, when a system is configured to use WINS for its name resolution, it adheres to h-node for name registration. For name resolution, it will also adhere to h-node but with a few differences. It will:

• Check to see if it is the local machine name.
• Check its cache of remote names. Any name that is resolved is placed in a cache where it will remain for 10 minutes.
• Try the WINS Server.
• Try broadcasting.
• Check the LMHOSTS file, if the system is configured to use the LMHOSTS file.
• Try the HOSTS file and then a DNS, if so configured.

On a Windows 2000/XP/2003 system you can run TCP/IP without NetBIOS or Windows Internet Names Service (WINS) servers. All name resolution can be done through Domain Name Service (DNS). To use this configuration, your applications should interpret and use DNS names correctly, and use directory services through Active Directory for browsing. Also, API functions that rely on NetBIOS name resolution will no longer work in this environment.

Microsoft Active Directory replaces NetBIOS as the primary name resolution and directory service in Windows 2000. Active Directory uses DNS as the location service for finding computers that share resources throughout a client's distributed environment. To use these integrated services, you should use DNS names when developing distributed applications. The DNS domain name is usually an organization name followed by a period and an extension that indicates the type of organization, such as microsoft.com. The organization name can be any combination of the letters A through Z, the numerals 0 through 9, and the hyphen (-). A fully qualified DNS name consists of its DNS host name followed by a period and the name of the DNS domain to which it is assigned, for example sample.microsoft.com. Like the organization name, the host name can be any combination of the letters A through Z, the numerals 0 through 9, and the hyphen (-). By default, the host name is the computer name, but computer names are limited to 15 characters, whereas DNS allows any name component to be longer than 15 characters. The host name does not have to match the computer name.

NOTE: Functions that relied on NetBIOS names for resolution in previous versions of Windows will not work in an environment that is purely using DNS for name resolution. For example, NetServerEnum is not supported in an environment that does not use NetBIOS.

In addition to using DNS names, you should implement browsing using directory services through Active Directory. Active Directory provides a single set of directory services for managing network resources from a variety of network providers. If you use Active Directory, the browsing functionality in your application will work on a user's computer regardless of the directory service that they have installed.

NOTE: Many existing systems rely on NETBIOS for down-level client support and functionality such as printing and file sharing. NETBIOS should not be turned off until these issues are addressed.