Creating Entries in the LMHOSTS File
Use the following rules to create and to edit entries in the LMHOSTS file:
- An entry consists of a computer's IP address followed by at least one space or tab and the computer's NetBIOS name.
You cannot add an LMHOSTS entry for a computer that is a DHCP client, because the IP addresses of DHCP clients change dynamically. To avoid problems, make sure that the computers whose names are entered in the LMHOSTS files are configured with static IP addresses.
Each entry must be on a separate line. The final entry in the file must be terminated by a carriage return.
NetBIOS names can contain uppercase and lowercase characters and special characters. If a name is placed between double quotation marks, it is used exactly as entered. For example "AccountingPDC" is a mixed-case name, and "HumanRscSr \0x03" specifies a name with a special character.
Every NetBIOS name is 16 bytes long. The user-definable portion of the NetBIOS name is the first 15 characters. The16 th character is set by default to identify the network client service that registered the name. The most familiar example of a NetBIOS name is the computer name on any Windows-based computer. When the computer is started, the Microsoft Network Client services are started and register their names, which consist of the computer name plus a unique 16 th character. For example, the name < computer_name [0x00]> is the Microsoft Workstation service; the name < computer_name [0x20]> is the Microsoft Server service. As you can see, the only difference between these two names is the 16 th character. The 16 th character makes it possible to uniquely identify each of the network client services running on the computer.
Entries in the LMHOSTS file can represent computers running Microsoft® Windows® 2000 Server, Microsoft® Windows® 2000 Professional, Microsoft® Windows NT® Server, Microsoft® Windows NT® Workstation, Microsoft® Windows® 95, Microsoft® LAN Manager, and Microsoft® Windows® for Workgroups 3.11 with Microsoft TCP/IP. There is no need to distinguish between different platforms in the LMHOSTS file.
The pound sign (#) is usually used to mark the start of a comment. However, it also designates special keywords, as described in Table H.1.
The keywords listed in the following table can be used in the LMHOSTS file for Windows 2000–based computers. (LAN Manager 2. x , which also uses LMHOSTS for NetBT name resolution, treats these keywords as comments.)
Table H.1 LMHOSTS Keywords
Support for nonprinting characters in NetBIOS names. Enclose the NetBIOS name in double quotation marks and use \0x nn notation to specify a hexadecimal value for the character. This enables the proper functioning in routed topologies of custom applications that use special names. However, LAN Manager TCP/IP does not recognize the hexadecimal format, and so you cannot use backward compatibility if you use this feature.
Used to group multiple #INCLUDE statements. Any single successful #INCLUDE statement in a group causes the group to succeed.
Used to mark the end of a group of #INCLUDE statements.
#DOM:< domain >
Part of the NetBIOS name–to–IP address mapping entry that indicates that the IP address is a domain controller in the domain specified by domain . This keyword affects how the Browser and Logon services behave in routed TCP/IP environments. To preload a #DOM entry, the #PRE keyword must appear first in the entry. #DOM groups are limited to 25 members.
#INCLUDE < file name >
Forces the system to seek the file specified by file_name and parse it as if it were part of the LMHOSTS file. Specifying a Universal Naming Convention (UNC) < file name > allows you to use a centralized LMHOSTS file on a server. If the server on which < file name > exists is outside of the local broadcast subnet, you must add a preloaded entry for the server that precedes the entry in the #INCLUDE section.
Part of the NetBIOS name–to–IP address mapping entry that designates the entry as a unique name that can have more than one address. The maximum number of addresses that can be assigned to a unique name is 25. The number of entries is equal to the number of network adapters in the computer.
Part of the NetBIOS name–to–IP address mapping entry that causes that entry to be preloaded into the name cache. By default, entries are not preloaded into the name cache but are parsed only after WINS and name query broadcasts fail to resolve a name. The #PRE keyword must be appended to entries that also appear in #INCLUDE statements; otherwise, the entry in the #INCLUDE statement is ignored.
#SG < name>
Part of the NetBIOS name–to–IP address mapping entry that associates that entry with a user-defined special (Internet) group specified by name . The #SG keyword defines Internet groups by using a NetBIOS name that has 0x20 as the 16th byte. A special group is limited to 25 members.
The following example shows how all of these keywords are used:
220.127.116.11 "appname \0x14" #special app server
18.104.22.168 printsrv #PRE #source server
22.214.171.124 localsrv #PRE
126.96.36.199 primary #PRE #DOM:mydomain #PDC for mydomain
188.8.131.52 machinename #SG:sg26members
184.108.40.206 multihome26 #MH
220.127.116.11 multihome26 #MH
#INCLUDE \\localsrv\public\lmhosts #adds LMHOSTS from this server
#INCLUDE \\primary\public\lmhosts #adds LMHOSTS from this server
Note the following characteristics of the preceding example:
The servers named printsrv , localsrv , and primary are designated with the keyword #PRE as entries to be preloaded into the NetBIOS cache at system startup.
The servers named localsrv and primary are also identified in the #INCLUDE statements as the location of the centrally maintained LMHOSTS file.
The server named "appname \0x14" includes spaces in its name and contains a special character after the first 15 characters. Since its name includes spaces, the name and the special character are enclosed in double quotation marks.
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 their names and IP addresses are contained in the computer's cache memory. However, by default, Windows 2000 limits the preloaded 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. When neither the cache nor IP broadcasts lead to name resolution, Windows 2000 parses the complete LMHOSTS file, including the #PRE entries that exceeded the cache limit of 100.
You can change the default maximum allowable #PRE entries by adding the entry MaxPreloadEntries to the registry. This entry must be added to the following registry subkey:
MaxPreloadEntries has a default and minimum value of 1000 entries for Windows 2000 and Windows NT, versions 3.x and 4.0; the maximum value is 2000 entries. For Windows 9x, the default and minimum value is 100 entries, and the maximum value is 500 entries.
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
For example, the LMHOSTS file could contain the following information:
18.104.22.168stockquote#PRE#stock quote server
22.214.171.124printqueue#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 are resolved only after the cache entries failed to match and after broadcast queries failed to locate them. After resolving the names of hosts whose entries in the LMHOSTS file are not designated for preloading, Windows 2000 keeps the NetBIOS name–to–IP address mappings 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 2000 domain controller from other computers on the network. To use the #DOM tag, follow the NetBIOS name and IP address of the domain controller in the LMHOSTS file with the #DOM keyword, a colon, and the domain in which the domain controller participates. For example:
126.96.36.199 primary#PRE#DOM:mydomain#The mydomain PDC
Using the #DOM keyword to designate domain controllers causes the computer to add entries to a cache of domain names that the computer uses to contact available controllers to process domain requests. When domain controller activity, such as a logon request, occurs, the computer sends requests to the domain group name. On the local subnet, the computer broadcasts the request, and it is picked up by any local domain controllers. However, domain controllers on remote subnets also receive the requests, because Microsoft TCP/IP uses datagrams to forward the request to domain controllers located on remote subnets when you use the #DOM keyword to specify domain controllers in the LMHOSTS file. Adding more domain controllers in the LMHOSTS file will help distribute the domain requests load across all domain controllers.
When mapping important members of the domain by using the #DOM keyword, use the following guidelines:
#DOM entries should be preloaded in the cache by using the #PRE keyword. Note that the #PRE keyword must precede the #DOM keyword in the LMHOSTS file.
For each local LMHOSTS file on a Windows 2000 computer that is a member in a domain, there needs to be #DOM entries for all domain controllers in the domain that are located on remote subnets. This ensures that logon authentication, password changes, browsing, and so on, work properly for the local domain.
Local LMHOSTS files on all servers that can be backup domain controllers needs to contain the primary domain controller's name and IP address, plus mappings for all other backup domain controllers. This ensures that promoting a backup domain controller to primary domain controller does not affect the promoted domain controller's ability to offer all services to members of the domain.
If trust relationships exist between domains, all domain controllers for all trusted domains must also be listed in the local LMHOSTS file.
For domains that you want to browse from your local domain, the local LMHOSTS files needs to contain at least the name and IP address for the primary domain controller in the remote domain. Again, backup domain controllers in remote domains must also be included so that promotion to primary domain controller does not impair the ability to browse remote domains.
Names that appear with the #DOM keyword in the LMHOSTS file are placed in a special domain cache for NetBT. When a datagram is sent by NetBT 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 a broadcast on the local subnet is also sent.
Adding User-Defined Special Groups by Using #SG
You can group resources, such as printers or computers that belong to groups on an intranet, by using the #SG keyword to define a special group in the LMHOSTS file. Special groups are limited to a total of 25 members.
You specify the special group name just as you would specify a domain name except that the keyword portion of the entry is #SG. The following example creates the special group mycompany:
188.8.131.52 printsrvsg#SG:mycompany #Specialgroup of computers
In some cases, you might want to specify only the name of a special group without specifying an IP address. This can be done by not entering the IP address in the otherwise complete entry, as in the following example:
printsrvsg#SG:mycompany #Specialgroup of computers
Adding Multihomed Devices by Using #MH
A multihomed device is a computer with multiple network adapters. A multihomed device can be defined by a single, unique name with which multiple IP addresses are associated.
You can provide multihomed NetBIOS name–to–IP address mappings in the LMHOSTS file by creating entries that are designated as multihomed with the keyword #MH. An #MH entry associates a single, unique NetBIOS computer name with an IP address. You can create multiple entries for the same NetBIOS computer name for each network adapter 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 NetBIOS name–to–IP address mappings for multihomed devices is the same as the other keyword entries. The following example shows the entries required to map names to IP addresses for a multihomed computer with two network adapters:
184.108.40.206 accounting#MH#accounting server NIC 1
220.127.116.11 accounting#MH#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 the demands of all workstations and servers on the network. An administrator can use the Windows 2000 Replicator service to maintain synchronized local copies of the global LMHOSTS file, and use centralized LMHOSTS files, as described in this section.
Use the keywords #BEGIN_ALTERNATE and #END_ALTERNATE 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 keyword #INCLUDE to include a local LMHOSTS file (located in the directory C:\Private) and the keyword #_ALTERNATE to include servers maintaining copies of the same LMHOSTS file:
18.104.22.168primary#PRE #DOM:mydomain#primary DC
22.214.171.124backupdc#PRE #DOM:mydomain#backup DC
#INCLUDE c:\private\lmhosts#include a local lmhosts
#INCLUDE\\primary\public\lmhosts#source for global file
#INCLUDE \\backupdc\public\lmhosts#backup source
#INCLUDE \\localsvr\public\lmhosts#backup source
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 directory C:\Private. During name resolution, Windows 2000 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 statements are 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.