Chapter 33 - Using LMHOSTS Files
Windows NT supports several different name resolution services to locate, communicate with, and connect to resources on the network. For example, a command to connect to an application server by using the server name must be resolved to an IP address in TCP/IP networks before the command can be successfully completed. This is referred to as name resolution.
If WINS servers are available on the network, the LMHOSTS file can be used to support the subnets that do not have a WINS server, and to provide a backup name resolution service in case the WINS server is not available. The LMHOSTS file provides a NetBIOS name resolution method that can be used for small networks that do not use a WINS server.
This chapter provides information about the following topics:
Using LMHOSTS File to Find Computers and Services
Windows NT versions 4.0 and 3.5x provide name resolution services for both NetBIOS computer names and Domain Name System (DNS) host names on TCP/IP networks. For an overview of all the Windows NT name resolution services for TCP/IP networks, refer to the chapter "Implementation Considerations" in the Windows NT Server Networking Supplement.
The LMHOSTS file is one method of name resolution for NetBIOS name resolution for TCP/IP networks. The other NetBIOS over TCP/IP (NetBT) name resolution methods that are used, depending on the computer's configuration, are:
Note NetBT is defined by RFCs 1001 and 1002. These RFCs define the different configurations — b-node, p-node, m-node, and h-node — that define how a computer attempts to resolve NetBIOS names to IP addresses.
By installation default, a Windows NT–based computer not configured as a WINS client or WINS server, is a b-node computer. A b-node computer is one that uses IP broadcasts for NetBIOS name resolution.
IP broadcast name resolution can provide dynamic name resolution. However, the disadvantages of broadcast name queries include increased network traffic and ineffectiveness in routed networks. Resources located outside the local subnet do not receive IP broadcast name query requests because, by definition, IP-level broadcasts are not passed to remote subnets by the router (default gateway) on the local subnet.
As an alternate method to IP broadcasts, Windows NT enables you to manually provide NetBIOS name and IP address mappings for remote computers by using the LMHOSTS file. Selected mappings from the LMHOSTS file are maintained in a limited cache of NetBIOS computer names and IP address mappings. This memory cache is initialized when a computer is started. When the computer needs to resolve a name, the cache is examined first and, if there is no match in the cache, Windows NT uses b-node IP broadcasts to try to find the NetBIOS computer. If the IP broadcast name query fails, the complete LMHOSTS file (not just the cache) is parsed to find the NetBIOS name and the corresponding IP address. This strategy enables the LMHOSTS file to contain a large number of mappings, without requiring a large chunk of static memory to maintain an infrequently used cache.
The LMHOSTS file can be used to map computer names and IP addresses for computers outside the local subnet (an advantage over the b-node broadcast method). You can use the LMHOSTS file to find remote computers for network file, print, and remote procedure services and for domain services such as logons, browsing, replication, and so on.
The Windows NT–based LMHOSTS method of name resolution is compatible with Microsoft LAN Manager 2.x TCP/IP LMHOSTS files.
Locating Remote Computers
Computer names can be resolved outside the local broadcast subnet if the remote computer name and IP address mappings are specified in the LMHOSTS file. For example, suppose your computer, named ClientA, is configured without the WINS client service, but you want to use TCP/IP to connect to a computer, named ServerB, that is located on another TCP/IP subnet. By default, your computer is a b-node computer that uses NetBIOS cache and IP broadcasts, and is enabled for LMHOSTS file lookup, by using an LMHOSTS file provided by your network administrator.
At system startup, the name cache on ClientA is preloaded only with entries from the LMHOSTS file, defined as preloaded by a special keyword, the #PRE keyword. For this example, ServerB is on a remote subnet outside of your local subnet IP broadcast area and is not one of the entries in preloaded cache. A strict b-node IP broadcast (as defined in RFCs 1001 and 1002) fails by timing out when no response is received. In this example, ClientA's IP broadcast to locate ServerB will time out, because ServerB is located on a remote subnet and does not receive ClientA's broadcast requests.
This example is summarized in the following steps:
Specifying Domain Controllers
The most common use of the LMHOSTS file is to locate remote servers for file and print services. But the LMHOSTS file can also be used to find domain controllers providing domain services on routed TCP/IP networks. Examples of such domain controller activities include domain controller pulses (used for account database synchronization), logon authentication, password changes, master browser list synchronization, and other domain management activities.
Windows NT primary domain controllers (PDCs) and backup domain controllers (BDCs) maintain the user account security database and manage other network-related services. Because large Windows NT domains can span multiple IP subnets, it is possible that routers could separate the domain controllers from one another or separate other computers in the domain from the domain controllers. In a network that does not use WINS servers, LMHOSTS name resolution can be used to allow client computers to connect to domain controllers located across routers on different subnets.
Using Centralized LMHOSTS Files
The primary LMHOSTS file on each computer is always located in the %systemroot%\System32\Drivers\Etc directory. With Microsoft TCP/IP, you can include other LMHOSTS files from local and remote computers.
Network administrators can manage the LMHOSTS files used by computers on the network by providing one or more global LMHOSTS files on a central server. Windows NT–based computers on the network can be configured to import the correct and up-to-date computer name-to-IP-address mappings.
Users can import the LMHOSTS file from remote computers on the network by using #INCLUDE statements in the LMHOSTS file or by selecting the Import LMHOSTS… option on the WINS Address tab of the Microsoft TCP/IP Properties page. See Figure 10.1 in the section "Configuring TCP/IP to Use LMHOSTS Name Resolution" later in this chapter.
Alternatively, an administrator can use the replicator service to distribute multiple copies of the global LMHOSTS file to multiple servers.
Note If network clients access a central LMHOSTS file, the computer on which the file is located must include the Registry parameter NullSessionShares for the LMHOSTS location. The NullSessionShares parameter is in the Registry key:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \LanManServer Parameters
For detailed information on Registry parameters, see online Help.
Creating the LMHOSTS File
Before configuring a computer to use the LMHOSTS file, you must create the primary LMHOSTS file on each computer, name the file LMHOSTS, and save the file in the %systemroot%\System32\Drivers\Etc directory.
You can create the file by using a text editor — for example, Notepad — to create, and change the LMHOSTS file because it is a simple text file. (An example of the LMHOSTS format is provided in the file named LMHOSTS.sam in the Windows NT %systemroot%\System32\Drivers\Etc directory. This is only an example file; do not use this file as the primary LMHOSTS file.)
The following sections describe the different types of entries that can be created and edited in the LMHOSTS file.
Creating Entries in the LMHOSTS File
Use the following rules to create and to edit entries in the LMHOSTS file:
The keywords listed in the following table can be used in the LMHOSTS file for Windows NT–based computers. (LAN Manager 2.x, which also uses LMHOSTS for NetBT name resolution, treats these keywords as comments.)
The following example shows how all of these keywords are used:
126.96.36.199 "appname \0x14" #special app server 188.8.131.52 printsrv #PRE #source server 184.108.40.206 localsrv #PRE 220.127.116.11 primary #PRE #DOM:mydomain #PDC for mydomain #BEGIN_ALTERNATE #INCLUDE \\localsrv\public\lmhosts #adds LMHOSTS from this server #INCLUDE \\primary\public\lmhosts #adds LMHOSTS from this server #END_ALTERNATE
In the preceding example:
The following sections further explain the use of the keywords #PRE, #DOM, #INCLUDE, and #SG.
Adding Remote System Names by Using #PRE
Using #PRE entries improves access to the identified computers because name and IP address mappings are contained in the computer's cache memory. However, by default, Windows NT limits the preload name cache to 100 entries. (This limit affects only entries marked with the #PRE keyword.)
If you specify more than 100 #PRE entries, only the first 100 #PRE entries are preloaded into the computer's cache. Any additional #PRE entries are ignored at startup and are used only if name resolution by the cache and IP broadcast fails. Windows NT then parses the complete LMHOSTS file which contains all the entries, including the #PRE entries that exceeded the cache limit of 100.
You can change the default maximum allowed #PRE entries by adding a MaxPreLoads value entry to the Registry. This value entry must be added to the following Registry key:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Netbt \Parameters
For example, the LMHOSTS file could contain the following information:
18.104.22.168 accounting #accounting server 22.214.171.124 payroll #payroll server 126.96.36.199 stockquote #PRE #stock quote server 188.8.131.52 printqueue #print server in Bldg 7
In this example, the server named stockquote is preloaded into the name cache, because it is tagged with the #PRE keyword. The servers named accounting, payroll, and printqueue would be resolved only after the cache entries failed to match and after broadcast queries failed to locate them. After non-preloaded entries are resolved, their mappings are cached for a period of time for reuse.
Adding Domain Controllers by Using #DOM
The #DOM keyword can be used in LMHOSTS files to distinguish a Windows NT domain controller from other computers on the network. To use the #DOM tag, follow the name and IP address mapping in LMHOSTS with the #DOM keyword, a colon, and the domain in which the domain controller participates. For example:
184.108.40.206 primary #PRE #DOM:mydomain #The mydomain PDC
Using the #DOM keyword to designate domain controllers adds entries to a domain name cache that is used to contact available controllers for processing domain requests. When domain controller activity such as a logon request occurs, the request is sent to the domain group name. On the local subnet, the request is broadcast and is picked up by any local domain controllers. However, if you use the #DOM keyword to specify domain controllers in the LMHOSTS file, Microsoft TCP/IP uses datagrams to also forward the request to domain controllers located on remote subnets. Adding more domain controllers in the LMHOSTS file will help distribute the load on all the controllers.
The following list contains guidelines for mapping important members of the domain by using the #DOM keyword.
Names that appear with the #DOM keyword in the LMHOSTS file are placed in a special domain name list in NetBT. When a datagram is sent to this domain using the DOMAIN<1C> name, the name is resolved first by using WINS or IP broadcasts. The datagram is then sent to all the addresses contained in the list from LMHOSTS, and there is also a broadcast on the local subnet.
Adding User-Defined Special Groups by Using #SG
You can group resources such as printers, or computers that belong to groups on the intranet, for easy reference, browsing, or broadcasting, by using the #SG keyword to define a special group in the LMHOSTS file. Special groups are limited to a total of 25 members. (If you are using WINS, they can also be defined by using the WINS Manager.)
Specify the name just as you would a domain name except that the keyword portion of the entry is #SG. For example:
220.127.116.11 printsrvsg #SG:mycompany #Specialgroup of computers
The preceding example results in a special group being created. In some cases you may want to just specify the name of a special group without specifying an IP address. This can be done by giving the name of the group preceded by #SG. For example:
printsrvsg #SG:mycompany #Specialgroup of computers
Addresses entered by using the LMHOSTS file become permanent addresses in the special group and can be removed only by using the WINS Manager.
Adding Multihomed Devices by Using #MH
A multihomed device is a computer with multiple network interface cards (NICs). A multihomed device can be defined by a single, unique name with which multiple IP addresses are associated.
You can provide multihomed name-to-IP-address mappings in the LMHOSTS file by creating entries that are specified by using the keyword #MH. An #MH entry associates a single, unique NetBIOS computer name to an IP address. You can create multiple entries for the same NetBIOS computer name for each NIC in the multihomed device, up to a maximum of 25 different IP addresses for the same name.
The format of the LMHOSTS entry that is used to specify name-to-IP-address mappings for multihomed devices is the same as the other keyword entries. For example, the entries required to map name to IP address for a multihomed device with two NICs are:
18.104.22.168 accounting #accounting server NIC 1 22.214.171.124 accounting #accounting server NIC 2
Defining a Central LMHOST File by Using #INCLUDE
For small- to medium-sized networks with fewer than 20 domains, a single common LMHOSTS file usually satisfies all workstations and servers on the intranet. An administrator can:
Use the #BEGIN_ALTERNATE and #END_ALTERNATE keywords to provide a list of servers maintaining copies of the same LMHOSTS file. This is known as a block inclusion, which allows multiple servers to be searched for a valid copy of a specific file. The following example shows the use of the #INCLUDE and #_ALTERNATE keywords to include a local LMHOSTS file (in the C:\Private directory):
126.96.36.199 primary #PRE #DOM:mydomain #primary DC 188.8.131.52 backupdc #PRE #DOM:mydomain #backup DC 184.108.40.206 localsvr #PRE #DOM:mydomain #INCLUDE c:\private\lmhosts #include a local lmhosts #BEGIN_ALTERNATE #INCLUDE \\primary\public\lmhosts #source for global file #INCLUDE \\backupdc\public\lmhosts #backup source #INCLUDE \\localsvr\public\lmhosts #backup source #END_ALTERNATE
Important This feature should never be used to include a remote file from a redirected drive because the LMHOSTS file is shared between local users who have different profiles and different logon scripts. Even on single-user systems, redirected drive mappings can change between logon sessions.
In the preceding example, the servers primary and backupdc are located on remote subnets from the computer that owns the file. The local user has decided to include a list of preferred servers in a local LMHOSTS file located in the C:\Private directory. During name resolution, the Windows NT computer first includes this private file, then gets the global LMHOSTS file from one of three locations: primary, backupdc, or localsvr. All names of servers in the #INCLUDE statements must have their addresses preloaded using the #PRE keyword; otherwise, the #INCLUDE statement is ignored.
The block inclusion is satisfied if one of the three sources for the global LMHOSTS file is available and none of the other servers is used. If no server is available, or for some reason the LMHOSTS file or path is incorrect, an event is added to the event log to indicate that the block inclusion failed.
Configuring TCP/IP to Use LMHOSTS Name Resolution
By default, the LMHOSTS name resolution method is enabled when TCP/IP is installed on a computer. You can disable LMHOSTS name resolution by clearing the Enable LMHOSTS Lookup checkbox on the WINS Address tab of the Microsoft TCP/IP Properties page. It is recommended that you do not disable LMHOSTS name resolution because it provides a backup name service for WINS servers that are off-line or unavailable.
To use an LMHOSTS file from a remote computer or different directory on the local computer, click Import LMHOSTS… as illustrated in the following figure.
Figure 33.1 Configuring TCP/IP to Enable LMHOSTS Lookup
Maintaining the LMHOSTS File
When you use an LMHOSTS file, be sure to keep it up-to-date and organized. Use the following guidelines:
Troubleshooting LMHOSTS Files
When using the LMHOSTS file, problems such as failure to locate a remote computer can occur because one or more of the following errors is present in the LMHOSTS file: