Network Basic Input/Output System (NetBIOS) defines a software interface and a naming convention, not a protocol. The NetBEUI protocol, introduced by IBM in 1985, provided a protocol for programs designed around the NetBIOS interface. However, NetBEUI is a small protocol with no networking layer and because of this, it is not a routable protocol suitable for medium-to-large intranets.
NetBIOS over TCP/IP (NetBT) provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client/server programs to the WAN and providing interoperability with various other operating systems. NetBT and NetBIOS are illustrated in the following figure.
Figure 6.4 NetBIOS over TCP/IP (NetBT) Component
The Windows NT Workstation service, Server service, Browser, Messenger, and Netlogon services are all direct NetBT clients that use the TDI to communicate with NetBT. Windows NT also includes a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS programs and translates them to equivalent TDI primitives.
The NetBIOS namespace is flat, meaning that all names within a network must be unique. NetBIOS names are 16 characters in length. Resources are identified by NetBIOS names that are registered dynamically when computers start, services start, or users log on. Names can be registered as unique (one owner) or as group (multiple owner) names. A NetBIOS Name Query is used to locate a resource by resolving the name to an IP address.
Microsoft networking components, such as Windows NT Workstation and Windows NT Server services, allow the first 15 characters of a NetBIOS name to be specified by the user or administrator, but reserve the 16th character of the NetBIOS name to indicate a resource type (00-FF hex). See Appendix G, "NetBIOS Names."
To identify the names registered on your local computer
1. Click Start, and then click Run.
2. In Open, type nbtstat -n.
NetBIOS Scope, also known as TCP/IP Scope, provides a method for adding a second element to the single-element NetBIOS computer name. The scope ID is a character string value that is appended to the NetBIOS name and is used for all NetBT communications from that computer. The character string can be multi-part¾for example, "mydomain.mycompany.com".
Note
Use of NetBIOS Scope is strongly discouraged if you are not already using it, or if you use Domain Name System (DNS) on your network.
By installation default, the NetBIOS Scope value is NULL. You can change the default value by entering a character string in the Scope ID on the WINS Address tab on the Microsoft TCP/IP Properties page. Note that the maximum length of the combined NetBIOS name and NetBIOS Scope ID is limited to 256 characters.
Note
NetBIOS Scope should not be confused with DHCP Scope, which defines the group of IP addresses that the DHCP server can lease to client computers.
The effect of using a NetBIOS Scope ID, other than the default NULL value, is to isolate a group of computers on the network that can communicate only with other computers that are configured with the identical NetBIOS Scope ID. Use NetBIOS Scope only when it is necessary to isolate a group of computers that cannot communicate with other computers on the intranet.
Once configured on the local computer, NetBIOS Scope is automatically attached to all NetBIOS commands on that local computer. In other words, NetBIOS programs started on a computer using NetBIOS Scope ID cannot "see" (receive or send messages) NetBIOS programs started by a process on a computer configured with a different NetBIOS Scope ID.
Several Windows NT-based programs, such as net logon and domain controller pass-through authentication, use NetBIOS names. Therefore, consider the effect of NetBIOS Scope ID if you decide to change the default NetBIOS Scope ID. Use the following guidelines:
1. All Windows NT Workstation, Windows NT Server, and Windows 95 computers in the same Windows NT domain that are using the same NetBIOS Scope ID can communicate and connect with each other.
2. However, no pass-through authentication can occur between domains that are configured with different NetBIOS Scope IDs. In other words, using NetBIOS Scope ID can break the trust between domains.
3. Users cannot log on to their assigned domain from Windows 95 and Windows NT Workstation computers if the scope on the computer is different from the NetBIOS Scope configured on the domain controller in the user's assigned domain.
4. Users cannot log on to any computer on which the configured NetBIOS scope is not the same as the NetBIOS Scope ID configured on the domain controller for the selected domain.
5. Users cannot connect, either by the command window or by using a program that issues a net use command, to a server whose NetBIOS Scope is different from the scope assigned to the domain controllers in the domain the user is logged on to, or the domain specified in the Connect dialog box.
Windows NT versions 4.0 and 3.5x computers use several methods for locating NetBIOS resources:
Earlier implementations used only cache, broadcasts, and LMHOSTS files; however, in Windows NT versions 4.0 and 3.5x, a NetBIOS name server¾the WINS server¾was implemented, and modifications were made to allow NetBIOS programs to query the DNS namespace by appending configurable domain suffixes to a NetBIOS name.
NetBIOS name resolution order depends on the node type and computer configuration. The following node types are supported:
The many configurable options sometimes make it difficult to determine what name resolution methods to choose, and what name resolution order each configuration will use. The following flowcharts illustrate name resolution for the various node types and the relationships between the different Windows NT name resolution services.
Figure 6.5 NetBIOS Name Resolution Flowchart (part 1 of 3)
Figure 6.6 NetBIOS Name Resolution Flowchart (part 2 of 3)
Figure 6.7 NetBIOS Name Resolution Flowchart (part 3 of 3)
The NetBIOS name server provided with Windows NT Server is the Windows Internet Name Service (WINS) server. Most WINS clients are set up as h-nodes; in other words, they first attempt to register and resolve names by a using WINS server, and if that fails they try local subnet broadcasts. Using a name server to locate resources is generally preferable to broadcasting, for two reasons:
It has always been possible to connect from one Windows NT computer to another using NetBT over the Internet and other TCP/IP networks. To do so, some means of name resolution (associating a name with the appropriate IP address) is used because an IP address is required to establish a connection.
NetBT is the name resolution service for Windows-based networking in TCP/IP. DNS is the traditional and widely used name resolution service for the Internet and other TCP/IP networks. Windows NT Server version 4.0 has expanded support for DNS by implementing a DNS server.
A DNS name is similar to a NetBIOS name in that it is a "friendly" name for a computer or other network device. However, the DNS name is based on a hierarchical naming structure (also known as the name space) that is more flexible than the flat structure of NetBIOS names. DNS computer names consist of two parts: a host name and a domain name, which when combined, form the fully qualified domain name (FQDN).
NetBIOS computer names are analogous to DNS host names, however a DNS name can be as long as 255 characters while the NetBIOS name is limited to 15 user-definable characters.
Note
Under Windows NT, the DNS host name defaults to the NetBIOS computer name. Windows NT combines the NetBIOS computer name with the DNS domain name to form a FQDN by removing the 16th character in the NetBIOS name and appending a dot and the DNS domain name. If you want to change the default host name from the NetBIOS computer name, reconfigure TCP/IP by selecting the DNS page on the Microsoft TCP/IP Properties dialog box and changing the host name displayed on the DNS page.
It is now possible, in Windows NT 4.0, to connect to a NetBT resource by using an IP address, FQDN, or NetBIOS computer name. For example, if using the Event Viewer, when prompted to "select computer," you now can choose to enter an FQDN or IP address or NetBIOS computer name.
As mentioned earlier, NetBT only binds to one IP address per physical network interface. From the NetBT viewpoint, then, a computer is multihomed only when it has more than one NIC installed. When a name registration packet is sent from a multihomed computer, it is flagged as a "multihomed name registration" so that it will not conflict with the same name being registered by another interface in the same computer.
When a broadcast name query is received by a multihomed computer, all NetBT interface bindings receiving the query will respond with their address and, by default, the client will choose the first response and connect to the address supplied by it. This behavior can be controlled by the RandomAdapter registry parameter described in online Registry Help.
When a directed name query is sent to a WINS server, the WINS server will respond with a list of all IP addresses that were registered with WINS by a multihomed computer.
Choosing the "best" IP address to connect to on a multihomed computer is a client function. Currently, the following algorithm is employed, in the order listed:
1. If one of the IP addresses in the name query response list is on the same logical subnet as the calling binding of NetBT on the local computer, then that address is selected. If more than one of the addresses meet this criteria, one is picked at random from those that match.
2. If one of the IP addresses in the list is on the same logical subnet as any binding of NetBT on the local computer, then that address is selected. If more than one of the addresses meet this criteria, one is picked at random from those that match.
3. If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, then an address is selected at random from the list.
This algorithm provides a reasonably good way of balancing connections to a server across multiple NICs, while still favoring direct connections when they are available.
Note
The current implementation of NetBT does not attempt to "walk the list" of returned addresses if a connection attempt to the first choice fails. This enhancement has been requested and is under review.
NetBIOS sessions are established between two names. For example, when a Windows NT Workstation makes a file sharing connection to a server, the following sequence of events takes place:
1. The NetBIOS name for the server is resolved to an IP address.
2. A TCP connection is established from the workstation to the server, using port 139.
3. The workstation sends a NetBIOS session request to the server name over the TCP connection. Assuming the server is listening on that name, it will respond affirmatively and a session is established.
Once the NetBIOS session has been established, the workstation and server negotiate a higher level protocol to use over it. Microsoft networking uses only one NetBIOS session between two names at any point in time. Any additional file or print sharing connections made after the first one are multiplexed over that same NetBIOS session.
NetBIOS keepalives are used on each connection to verify that the server and workstation are both still up and able to maintain their session. This way, if a workstation is shut down ungracefully, the server will eventually clean up the connection and associated resources, and vice versa. NetBIOS keepalives are controlled by the SessionKeepAlive registry parameter and default to once per hour.
If LMHOSTS files are used and an entry is misspelled, it is possible to attempt to connect to a server using the correct IP address but an incorrect name. In this case, a TCP connection will still be established to the server. However, the NetBIOS session request (using the wrong name) will be rejected by the server, because there is no listen posted on that name. Error 51, "remote computer not listening," will be returned.
Datagrams are sent from one NetBIOS name to another over UDP port 138. The datagram service provides the ability to send a message to a unique name or to a group name. Group names may resolve to a list of IP addresses or to a broadcast. For example, the command net send /d:mydomain test would send a datagram containing the text "test" to the group name <mydomain>[03]. The <mydomain>[03] name would resolve to an IP subnet broadcast, and so the datagram would be sent with the following characteristics:
All hosts on the subnet would pick up the datagram and process it at least to the UDP protocol. On hosts running a NetBIOS datagram service, UDP would hand the datagram to NetBT on port 138. NetBT would check the destination name to see if any program had posted a datagram receive on it, and if so would pass the datagram up. If no receive is posted, the datagram is discarded.