The NetBIOS API provides support for the naming scheme used by Windows networking: computer names, domains, and workgroups. Windows 2000 includes NetBIOS over TCP/IP (NBT), a service that allows NetBIOS communications and name resolution through TCP/IP.
After the HOSTS file and DNS fail to locate an IP hostname, Windows 2000 clients can use NetBIOS resolution. NetBIOS names have their own rules for domain resolution and their own name server service (WINS).
The steps involved in NetBIOS name resolution depend on the client’s NetBIOS node type or name resolution mode. The following are the five possible node types and their name resolution methods:
- B-node (broadcast)
These nodes send a broadcast (NetBIOS name query) to the entire local subnet when they need to resolve a name. The broadcast is repeated three times, if necessary. Each machine on the subnet compares the NetBIOS name in the broadcast with its own name. If a machine finds a match, it sends a reply (NetBIOS name query response) to the original node, and the NetBIOS session is established.
- Enhanced B-node
This is Microsoft’s nonstandard version of the B-node method and is Windows NT’s default if a WINS server is not used. The broadcasts are sent as in the previous method. If no response is received from any machine on the local subnet, the client searches its local LMHOSTS file (explained later in this section) for an entry corresponding to the name.
- P-node (peer-to-peer)
This type of node sends a NetBIOS name query message directly to a defined WINS server (described later in this section). No further resolution attempts are made.
- M-node (mixed)
These nodes first attempt to use B-node broadcasts. If no response is received, they send a query to a WINS server. Primary and secondary WINS servers are tried, if specified in the client’s configuration.
- H-node (hybrid)
These nodes use the opposite of the M-node method: they first send a query to the defined WINS servers. If there is no response or the response is negative, they resort to B-node broadcasts. This is Windows NT’s default method when a WINS server is available; it minimizes network traffic.
The P-node, M-node, and H-node methods of NetBIOS name resolution can make use of an NBNS (NetBIOS Name Service) server. Microsoft’s implementation of NBNS is called WINS, or Windows Internet Name Service. A properly configured WINS server allows clients to avoid bandwidth-heavy B-node broadcasts.
Several processes, each involving a type of message sent between the client and the server, make up WINS resolution:
When a client initializes, it sends a NAME REGISTRATION REQUEST message to its defined primary WINS server. If it does not receive a response, it sends the same request to its secondary WINS server.
If the server hasn’t already registered the same name to another client, it sends a POSITIVE NAME REGISTRATION RESPONSE message, specifying a TTL (Time-to-Live) indicating how long the name will remain registered. Otherwise, the server sends an END-NODE CHALLENGE message, and the client must challenge the already-registered node.
After 50% of the TTL has expired, the client attempts to renew the registration by sending a NAME REFRESH REQUEST message. If the response is positive, a new TTL is specified.
When the client needs to resolve a NetBIOS name, it sends a NAME QUERY REQUEST message to the server. The server replies with a positive response if the name is registered or with a negative response if the name is not found.
When the client shuts down, it sends a NAME RELEASE REQUEST to the server and receives a NAME RELEASE RESPONSE releasing the name. The client stops using the name, and the server removes it from the WINS database.
Windows 2000 Server includes a WINS server. This can be selected for installation during the Windows 2000 installation, or it can be installed manually. If the WINS server is not already installed, use the following procedure to install it:
Select Add/Remove Programs from the Control Panel.
Click Add/Remove Windows Components to start the Windows Components Wizard.
Highlight the Networking Services entry in the list and select Details.
Check the box next to Windows Internet Name Service (WINS) and click OK.
Click Next to complete the installation. The Windows 2000 Server CD-ROM may be required during the installation process.
After WINS Server is installed, you can manage it from the WINS MMC snap-in. To access this utility, select Programs → Administrative Tools → WINS from the Start menu.
The Active Registrations item under a WINS server displays a list of currently registered names and their corresponding IP addresses. Because WINS configures itself automatically, you do not need to configure this list yourself; however, you can add static mappings for machines that are unable to register themselves in WINS, such as Unix and other non-Windows machines.
To add a static mapping, select New Static Mapping from the Action menu. The New Static Mapping dialog includes the following options:
- Computer name
Specify the NetBIOS name for the computer.
- NetBIOS scope
Specify an optional NetBIOS scope. Only nodes with the same scope can participate in the same network.
- Type
Specify the type of node or nodes: Unique, Group, Domain Name, Internet Group, or Multihomed.
- IP address
Specify the IP address corresponding to the NetBIOS name. For the Domain, Internet Group, and Multihomed mapping types, you can specify multiple IP addresses.
The Windows 2000 WINS server includes support for automatic database replication between servers. The replication scheme uses a system of partners:
- Push partners
Automatically send updates to partner servers whenever changes are made to the WINS database. This provides for the best database synchronization.
- Pull partners
Periodically poll partner servers and receive updates for any changes since the previous polling. This system works best over wide-area links where constant synchronization updates would inflate bandwidth.
To configure WINS replication, highlight the Replication Partners item under the server name in the WINS snap-in. This displays a list of current replication partners, if any.
To add a partner, select New Replication Partner from the Add menu. You are prompted for the IP address of the WINS server to partner with. After the partner is added, right-click its entry and select Properties to access the Partner Properties dialog, shown in Figure 18-5. This dialog includes the following options:
- Replication partner type
Choose the type of partner: Push, Pull, or Push/Pull (allows both types of replication).
- Pull replication
For pull partners, choose whether to use a persistent connection for the replication. You can specify a start time and replication interval for the regular updates.
- Push replication
For push partners, choose whether to use a persistent connection. You can also specify the number of updates to the WINS database that will be allowed before forcing a replication session.
In Enhanced B-node NetBIOS resolution, the LMHOSTS file is checked if a negative response is received from the WINS server. This file is similar to the HOSTS file, but uses IP addresses and NetBIOS names. To enable the LMHOSTS file, select the Enable LMHOSTS Lookup option in the WINS tab of the TCP/IP Properties dialog.
LMHOSTS is a standard ASCII file stored in \systemrootsystem32driversetclmhosts.sam. The following is an example of a simple LMHOSTS file:
168.192.150.1 East1 # this is a comment 168.192.150.2 East2 #PRE # see below 168.192.150.6 North1
Entries in the LMHOSTS file can be suffixed with
#PRE to indicate that
they are to be directly loaded into the local NetBIOS cache for fast
resolution. Entries suffixed
#DOM
are domain entries, which can be used to
support network browsing and domain authentication.
The LMHOSTS file supports a rudimentary form of remote name resolution through the use of block inclusion. Entries from the LMHOSTS file on a remote server can be included using the following syntax:
BEGIN_ALTERNATE #INCLUDE \East1publiclmhosts END_ALTERNATE
The files you include are searched only if no match was found in the local LMHOSTS file. If more than one remote LMHOSTS file is included in this fashion, they are searched in order; if a name is resolved by one file, the remaining files will not be searched.