More LMHOSTS Tips

In February, I explained how to use an LMHOSTS file to force a Windows NT workstation to use a particular domain controller ("Pick Users' Domain Controller," February 1999). I received an interesting response to the column from a Microsoft expert on the topic. Like many Microsoft sources, she prefers that I not use her name because she can't speak for Microsoft. In a nutshell, her point was that you need to make sure you have a good reason for implementing LMHOSTS because of the effect an LMHOSTS policy can have on IS support personnel. She also pointed out a problem with my February column's LMHOSTS method for establishing reliable trust relationships.

Revisiting LMHOSTS Basics
Suppose you have an NT workstation that presents No domain controller found errors when users try to log on to the network. These errors often occur mysteriously—the domain controller is on the same network segment as the workstation, but the workstation can't find it. I explained in February that one solution to this error is to build a strange-looking entry in an LMHOSTS file.

Every domain controller registers with the domain's WINS server a 16-character name that consists of the domain name, followed by enough spaces to make the domain name 15 characters long, and a hexadecimal 1C. (Domain controllers separately register unique names with WINS.) WINS name resolution requires spaces before the hex 1C because all NetBIOS names are 16 characters long. When a workstation needs to find a domain controller, it searches the network for a machine that has registered a NetBIOS name consisting of the domain name and the hex 1C.

Typically, a workstation finds a domain controller by broadcasting the request If any domain controllers can hear me, please log me on. Soon after this broadcast, the workstation asks its WINS server for a list of all the domain controllers that the WINS server knows about, and the workstation sends individual logon requests to each domain controller on the list. The workstation logs on to whichever domain controller responds to its logon requests first.

However, you can create an entry in a computer's LMHOSTS file to specify which domain controller the computer needs to connect to. For example, if a domain named Colors has a domain controller named Purple at IP address 100.200.110.44, you can include

100.200.110.44 "COLORS
  \0x1C" #PRE

in the workstation's LMHOSTS file to help the workstation find the domain controller. The good thing about LMHOSTS files is that they remove the question of which domain controller a workstation might log on to. The bad thing about LMHOSTS files is that they limit each machine to one domain controller. If the domain controller that an LMHOSTS file names isn't working, the workstation won't broadcast a logon request or contact its WINS server for a list of domain controllers.

Using LMHOSTS also requires that you create or modify an LMHOSTS file on every workstation, a requirement that creates a lot of work for a network support team. The Microsoft expert who responded to my February column drove home this problem. She said, "IS engineers aren't happy when they're told to use LMHOSTS files, unless it's solely for troubleshooting—trust me, I know!"

My source suggested that as long as you have enough local domain controllers, your users will consistently log on to a local domain controller without requiring an LMHOSTS solution. She estimated that six domain controllers can handle logons for 1000 users. I don't have that many users, so I can't say whether this estimate is reasonable. However, I expect that six domain controllers need a lot of RAM and 100Mbps or faster Ethernet connections to support 1000 users.