NetBIOS


The NetBIOS and NetBEUI protocols are described in "NetBIOS and NetBEUI," which is on the upgradingandrepairingpcs.com Web site. Although the original specifications were sufficient for use on only very small LANs (fewer than 200 nodes), NetBIOS has been a mainstay in most Microsoft network products. Until Windows 2000, NetBIOS names were integral to the Windows operating systems' management functions. For example, domain names and host names are made up of NetBIOS names. The Server Message Block (SMB) protocol that's used for resource access and administrative duties in LAN Manager and the Windows operating systems' networking software modules are based on NetBIOS names.

Note

The Server Message Block protocol is now called the Common Internet File System (CIFS), which is discussed later in this chapter. To provide for interoperability with Windows networks, many vendors created SMB/CIFS products. The Unix and Linux communities have ventured into this territory with Samba. Samba is an SMB/CIFS client/server system that you can install on Unix and Linux clients or servers and use to access typical Windows NetBIOS-based resources. You can read up on the latest version of Samba or download the software using the URL http://www.samba.org.


The LMHOSTS File

In the %systemroot%\SYSTEM32\DRIVERS\ETC directory on Windows NT 4.0, Windows 2000, XP, and Windows Server 2003 computers is a file named LMHOSTS.SAM. For Windows 95 and Windows 98 clients, this file is found in the \WINDOWS directory. It's used to map NetBIOS names to IP addresses. The .SAM filename extension indicates that this is a sample file. If you're going to use the file, you have to copy it or rename it LMHOSTS with no file extension. Because it's always a good idea to keep the original copy in case things become confused along the line, making a copy is a good choice.

To rename the file from the command line, set your working directory to the directory in which the file resides and enter

ren lmhosts.sam lmhosts 


To copy the file (and preserve the original sample file), enter

copy lmhosts.sam lmhosts 


The Windows files are basically the same for all versions of Windows, except for a few of the comment lines. The following is the version you'll find in Windows Server 2003:

# Copyright (c) 1993-1999 Microsoft Corp. # # This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to computernames # (NetBIOS) names. Each entry should be kept on an individual line. # The IP address should be placed in the first column followed by the # corresponding computername. The address and the computername # should be separated by at least one space or tab. The "#" character # is generally used to denote the start of a comment (see the exceptions # below). # # This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts # files and offers the following extensions: # #      #PRE #      #DOM:<domain> #      #INCLUDE <filename> #      #BEGIN_ALTERNATE #      #END_ALTERNATE #      \0xnn (non-printing character support) # # Following any entry in the file with the characters "#PRE" will cause # the entry to be preloaded into the name cache. By default, entries are # not preloaded, but are parsed only after dynamic name resolution fails. # # Following an entry with the "#DOM:<domain>" tag will associate the # entry with the domain specified by <domain>. This affects how the # browser and logon services behave in TCP/IP environments. To preload # the host name associated with #DOM entry, it is necessary to also add a # #PRE to the line. The <domain> is always preloaded although it will not # be shown when the name cache is viewed. # # Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT) # software to seek the specified <filename> and parse it as if it were # local. <filename> is generally a UNC-based name, allowing a # centralized lmhosts file to be maintained on a server. # It is ALWAYS necessary to provide a mapping for the IP address of the # server prior to the #INCLUDE. This mapping must use the #PRE directive. # In addition the share "public" in the example below must be in the # LanManServer list of "NullSessionShares" in order for client machines to # be able to read the lmhosts file successfully. This key is under # \machine\system\currentcontrolset\services\lanmanserver\parameters\nullsessionshares # in the registry. Simply add "public" to the list found there. # # The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE # statements to be grouped together. Any single successful include # will cause the group to succeed. # # Finally, non-printing characters can be embedded in mappings by # first surrounding the NetBIOS name in quotations, then using the # \0xnn notation to specify a hex value for a non-printing character. # # The following example illustrates all of these extensions: # # 102.54.94.97    rhino        #PRE #DOM:networking  #net group's DC # 102.54.94.102   "appname \0x14"                    #special app server # 102.54.94.123   popular           #PRE             #source server # 102.54.94.117   localsrv          #PRE             #needed for the include # # #BEGIN_ALTERNATE # #INCLUDE \\localsrv\public\lmhosts # #INCLUDE \\rhino\public\lmhosts # #END_ALTERNATE # # In the above example, the "appname" server contains a special # character in its name, the "popular" and "localsrv" server names are # preloaded, and the "rhino" server name is specified so it can be used # to later #INCLUDE a centrally maintained lmhosts file if the "localsrv" # system is unavailable. # # Note that the whole file is parsed including comments on each lookup, # so keeping the number of comments to a minimum will improve performance. # Therefore it is not advisable to simply add lmhosts file entries onto the # end of this file. 


As you can see from the sample file, you can place comments anywhere on a line by using the # character. Using comments aids in managing the file when there are multiple administrators. However, as the last bit of text explains, the entire file is parsed (read) each time it's consulted for a name lookup. For this reason, when you copy the file to create your LMHOSTS file, you should delete all the default introductory comments, populating the file with only hostnames and comments applicable to your needs. If the number of entries in this file becomes quite large and full of both name translations and comments, it has probably outgrown its usefulness and you need to look to another means of name resolution, such as WINS or DNS.

Note

WINS can perform name translation for NetBIOS names to IP addresses. The LMHOSTS file is considered to be a legacy holdover from earlier Microsoft LANsfor example, those using Windows 95/98 or Windows NT 4.0. The LMHOSTS file can be used to override entries stored on a WINS server, or can be used in a very small network that doesn't use a WINS server. This chapter describes this file for historical purposes, as well as to point out that if you're still using it, it's time to upgrade. The exception to this advice is a network based on those older operating systems where the software application still works and there is no upgrade path.


In addition to serving as the comment character, the # character can be used to specify several keywords that have specific functions when used in this file. The keywords are

  • #PRE Load this entry into the NetBIOS name cache.

  • #DOM This entry is a domain controller.

  • #INCLUDE Use the filename following this keyword to get name-to-address mappings.

  • #BEGIN_ALTERNATE and #END_ALTERNATE The #INCLUDE commands within this block are to be processed in order until one of them succeeds in performing the name translation.

For small networks that have several subnets separated by a router, using the #DOM keyword for an entry can enable a client to locate a domain controller on another subnet. Although it's preferable to have a backup domain controller on each subnet (for Windows NT 4.0 and earlier versions of Microsoft's operating systems), this workaround can be helpful for special conditions.

In Figure 29.1, you can see the logical steps that a b-node goes through when trying to resolve a name to an IP address. The NetBIOS name cache is consulted first, followed by broadcasting. Finally, if those two methods fail, the LMHOSTS file is checked.

Figure 29.1. In Microsoft networks, a b-node consults the LMHOSTS file when other methods fail.


You can find more information about b-nodes and other node designations that are used with NetBIOS names by reading "NetBIOS and NetBEUI" on the upgradingandrepairingpcs.com Web site.


The in-memory NetBIOS name cache is always consulted first. This cache can hold up to 100 entries. When a name is successfully resolved by the broadcast method or by a lookup in the LMHOSTS file, it's added to the name cache and can be resolved there from that point onward.

You can ensure that an entry will be placed in the name cache when the workstation boots by using the #PRE keyword for that entry in the LMHOSTS file:

175.110.32.31    yoko.ono.com    #PRE 


This can be useful for ensuring that servers that are accessed often by clients are resident in the memory cache, eliminating the need to perform a disk access to look up the entry in the LMHOSTS file.

Tip

You can force an update to the NetBIOS cache by using the command nbtstat -R to reload the cache from the LMHOSTS file. This is useful if you've just made edits to the file. Also note that if an identical name exists in both the HOSTS file and LMHOSTS file, the definition in the LMHOSTS file will be used.


Windows Internet Name Service

WINS is Microsoft's NetBIOS Name Server (NBNS) developed according to the details set forth in RFCs 1001 and 1002, and is based on a client/server architecture. Only Windows server operating systems can run the WINS service, and the server does not have to be a domain controller. In the traditional DNS server that originated on Unix systems, an administrator is responsible for manually editing files to maintain address-to-name mappings. WINS is a dynamic database. Name registrations are performed by unicast messages (direct contact) between the server and the WINS client. Because the WINS server does not have to be on the same network segment as the client, and because no broadcast messages clutter up network medium, WINS is a more efficient method of name resolution when compared to b-node functionality.

Note

If your network contains clients or applications that need a WINS server for name resolution, and they won't work with DNS, consider upgrading the clients or keeping a WINS server. More likely, consider replacing the client or NetBIOS applications.


The following are some of the important benefits of using WINS:

  • Ease of administration Updates to the database are dynamic. When a computer is moved to a different location and acquires a new address, it updates the WINS server when it boots. If DHCP is used on the network, moving the client computer requires nothing more than hooking it up to the network and booting the computer, provided the client has been configured to use Dynamic Host Configuration Protocol (DHCP) and WINS.

    Tip

    WINS was developed to provide name resolutions services for NetBIOS names. WINS is a dynamic database, so clients can obtain configuration information from a DHCP server and register this information in one or more WINS servers. Modern implementations of DNS servers also support dynamic updates. Therefore, this first benefit that WINS provides is no longer as important as it once was. In an all-TCP/IP network, you shouldn't have to use WINS unless you have older applications that require it.


  • Interaction with DNS Beginning with Windows NT 4.0, WINS has the capability to interact with Microsoft's DNS server, provided that you configure the client to do so. If properly configured, a non-Windows client can query the DNS server, which can then query the WINS server to obtain the address of a NetBIOS client if the DNS server does not find a name translation in its own database.

  • Static mappings If WINS is not set up to interact with the DNS server, you can place static mappings in the database for clients that do not have WINS client functionality. In a network composed of different operating systems, static mappings can help to integrate them into the Windows environment, making it easy for WINS clients to locate these computers.

  • Replication Although not specified in the RFCs, WINS servers are typically set up with replication partners. This means that over a given convergence time, all WINS servers in the network are updated with changes made on any one of them.

  • Fault tolerance Clients are typically configured to locate a primary WINS server and a secondary WINS server. Because the database is replicated at intervals, the secondary WINS server can continue to service all clients until the primary server is brought back online.

When to Use WINS

WINS was a good solution for resolving names before Windows 2000 came along. Beginning with Windows 2000, you don't necessarily need to install a WINS server on the network. This is because Windows 2000 clients can use DNS and the Active Directory to find out about other hosts on the network. However, if you have a network that's composed of multiple operating systems, such as Windows 98 or Windows NT computers, WINS can still be useful because all versions of Windows prior to Windows 2000 require NetBIOS name support. Some applications, such as SMS, might require NetBIOS.

Of course, NetBIOS name support doesn't mean that you need to install WINS. It depends on the topology of your network. On a small office LAN with only one physical cable segment (or a hub/switch) and just a few computers, NetBIOS broadcasts are probably sufficient for name resolution for these older clients and will not use up a large amount of bandwidth. However, if you operate a larger network that contains many segments and a large number of computers, or if you're just starting to introduce Windows 2000 or Windows Server 2003 servers into a network that already has older legacy clients or applications that use NetBIOS names, WINS is a good interim solution until you can plan an upgrade to remove these older clients and applications.

Configuring WINS Clients

To use WINS, a client must first be configured with the address of a WINS server. This can be done in one of two ways. First, you could configure the client manually, using a network properties page for the particular Windows operating system. Second, you could configure a DHCP server to provide the name of one or more WINS servers to a client if you use DHCP in your network. For more information about configuring WINS options using a DHCP server, see Chapter 28, "BOOTP and the Dynamic Host Configuration Protocol (DHCP)."

If your network consists of nothing but Windows 2000, Windows XP, or Windows Server 2003 computers, you won't need the WINS service. The Active Directory combined with DHCP and a dynamic DNS server provide all the name registration and resolution functionality you need. However, Windows 2000 clients can still be configured to use WINS. This might be necessary if you have a mixed network using clients from Windows 98, Windows NT, or even Unix or Linux clients that have Samba installed.

To configure a Windows 2000 client to use WINS, follow these steps:

1.

Click Start, Settings, Network and Dialup Connections.

2.

Right-click on the network connection you want to set up to use WINS and select Properties from the menu that appears.

3.

Click once on Internet Protocol (TCP/IP) and click the Properties button.

4.

Click the Advanced button at the bottom of the Properties page. The Advanced TCP/IP Settings Properties page is displayed. Click the WINS tab (shown in Figure 29.2).

Figure 29.2. Use the Advanced TCP/IP Settings Properties page to configure Windows 2000 clients to use WINS.


5.

Click the Add button. A dialog box pops up that you can use to enter the IP address of a WINS server. Enter the address and click OK. Continue using the Add button to add more WINS servers, if they're present on your network for backup purposes.

You'll also notice in Figure 29.2 that you can use the Edit and Remove buttons. To remove a WINS server, simply highlight the server you want to remove by clicking on it once and then click the Remove button. The Edit button can be used to change an entry. Highlight the entry and click the Edit button, and the same dialog box used for adding WINS servers pops up. The WINS server you've selected to edit appears in the fields on this dialog box. You can change any part of the IP address and click OK.

One final note about Windows 2000 clients that network administrators will appreciate: You don't have to perform a reboot of the computer after you add, edit, or remove WINS servers.

Client Name Registration and Release

For a client computer to register a name with the WINS server, it sends a name registration request to the server. This is a directed message, not a broadcast messagethat's why you have to configure the client to know the address of one or more WINS servers. If the name is not found in the database, the WINS server returns a positive name registration response to the client. The record is given a timestamp, and a renewal interval is also recorded in the record. The record is given an owner ID as well, which identifies the WINS server that originated (or in other words, owns) the record. When the record is replicated to other WINS servers, they use this ID to identify the original server.

After half of the renewal period has elapsed, a Windows client attempts to reregister its ownership of the name by sending the server a name refresh request. The re-registration process functions the same as the initial registration. By setting a time-to-live (TTL) value on each record, the WINS database can eventually be purged of records that are no longer valid.

Note

The term time to live is used by many protocols and services. Don't confuse the TTL value described here with the TTL field used in the IP packet header, for example. For IP packets, the TTL field is used to prevent a packet from getting stuck in a routing loop. Each time the IP packet passes through a router, this field is decremented by at least one and the packet is dropped when the TTL value reaches zero. WINS uses a TTL value to determine when to begin the process of getting rid of records that appear to no longer be in use because the client has not renewed the record registration. Later in this chapter, you'll see that DNS servers also use a TTL value.


The state of the name record changes over time depending on the status of the client. At any time, a record is either in the active state or it can be marked as released or extinct. At each state, a TTL is marked on the record and is used to determine when to change it to the next state.

A name can be released in two ways:

  • The name can be released explicitly if the client computer is shut down in a proper manner. The client sends a message to the server telling it to release the name.

  • The name is set to a released state by the WINS server if it does not receive a name refresh request before the renewal period expires.

When the name is released, the WINS server does not yet delete the record from the database. Instead, it marks the record as released, adds another timestamp (showing the time of the release), and then adds an extinction interval to the record. If the WINS server that receives the release is the original owner of the record, it does not propagate a record update to other WINS servers, which reduces replication traffic. If another WINS server that still has a record showing the name is active receives a request from another computer to use the name, it tries to contact the original owner and find out whether the name can be reused.

At certain intervals, the WINS server scavenges the database. If it finds a record whose extinction interval has expired, it marks the record as extinct. This state is often referred to as the tombstone state. When a record is marked as extinct, it receives another timestamp and an extinction time-out value. If a record has not been re-registered by the end of this final time-out interval, the scavenge process will finally remove it from the database.

If a WINS server receives an explicit release request from a client and the server is not the original owner of the record, it makes itself the new owner of the record. Instead of placing the record into the released state, it proceeds directly to the extinct state. Unlike records in the released state, records in the extinct state do get replicated at replication time. The reason that a WINS server immediately marks a record it does not own as extinct is so that the record will be replicated quickly and will get back to the WINS server that originated the record.

If a name is already in the database, the client can still be awarded ownership of it, depending on certain factors. If the name is in the released or extinct state, the server knows that it can reassign the name because the previous owner has released it. If the name is in the active state, the WINS server tries to contact the original owner. If the original owner does not respond, the WINS server reassigns the name to the node that's requesting it.

Note

In general, static entries made to the WINS database aren't subject to the scavenge process and remain in the database. However, the administrator can configure the server to operate differently by setting the Migrate On switch in the WINS Administrator Utility. If this switch is set, the static entry can be overwritten by a new name request if the original owner does not answer a challenge from the WINS server. The Migrate On switch is meant to be used when migrating a network from static entries to dynamic entries. This might be the case when you're upgrading your network with new client software, for example, and relieves the administrator of the burden of having to remove the static entries manually.


When a client workstation is moved to a new subnet and receives a new address, it sends a name registration request to the WINS server. The WINS server queries the old IP address, determines that the name is no longer in use, and then grants the name to the new IP address.

Tip

Not sure whether your workstation is using NetBIOS names? Use the NBTSTAT command at the Command Prompt. NBTSTAT -n will list the NetBIOS names in the workstation's local cache.


Static Name Entries

You can enter static entries into the WINS database using the WINS Manager utility. This is usually done for non-WINS clients, such as Unix workstations. Although you can configure the Windows client to use DNS to resolve these names, a static entry into the WINS database does two things. It makes name resolution faster because the client only has to query the WINS server. It also helps to prevent errors by preventing a WINS client from registering a name that's already in use by a non-WINS enabled client.

Name Queries

In Figure 29.3, you can see the process that a client computer goes through when trying to resolve a name using WINS servers. The steps it takes depend on whether it has one or two WINS servers in its configuration (primary and secondary WINS servers) and whether the node is configured as a p-node or an h-node.

Figure 29.3. Name resolution using WINS servers for p-node and h-node clients.


When a WINS server receives a name query request from a node, it returns a positive name response with one or more IP addresses associated with the NetBIOS name to the requestor via a UDP packet. If the WINS server does not have a record for the name, it sends a negative name response. If the client is configured with the address of a secondary WINS server, it attempts to resolve the name by contacting that server.

If the secondary server also returns a negative name response, the client either fails to resolve the name (if it's a p-node) or it uses a broadcast message as a last resort (if it's an h-node). If the computer that the client wants to contact is on the local network segment, the broadcast can succeed. If not, the client is unable to resolve the name to an IP address and will be unable to contact the other computer.

What Is the WINS Proxy Agent?

To provide access to the WINS server information for b-nodes that cannot query the WINS server directly, the concept of a proxy server was created. A proxy server listens to broadcast messages issued by a b-node on the local network segment and if the name being sought is in the proxy server's name cache, it returns a response to the b-node. If the name isn't in the proxy server's cache, it queries the WINS servers it knows.

When a proxy server is also configured to monitor name registration broadcast messages, it listens for these messages and sends a negative response to a b-node that attempts to register a name that exists in the WINS database. However, the proxy server does not make name registrations into the WINS database for a b-node. It merely responds to name registrations that conflict with the database.

To resolve names for b-nodes, the proxy server examines the subnet address of the b-node that's performing the name query. This is done so that the proxy server does not respond to name queries for nodes that are on the local subnet and can respond for themselves.




Upgrading and Repairing Networks
Upgrading and Repairing Networks (5th Edition)
ISBN: 078973530X
EAN: 2147483647
Year: 2006
Pages: 411

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net