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
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.
Trustworthy PDCs
In my February article, I suggested that you add an entry to each trusting domain controller's LMHOSTS file to specify which domain controllers in other domains that machine needs to trust. Such an LMHOSTS entry ensures that if you have to reestablish the trust relationship, your server doesn't trust an unreliable domain controller in the other domain. My contact agreed that such an LMHOSTS entry "provides fault tolerance in instances where the WINS servers are down." But she also pointed out that telling a domain controller to always trust a certain BDC in another domain can cause problems, because some trust communications require contact with the other domain's PDC. She's right; I forgot about that requirement.
When you tell a domain controller which machine to establish a trust relationship with, you need to tell it to contact the other domain's PDC. Just as every domain controller (including the PDC) registers the NetBIOS name domain name<1C>, the PDC registers the unique name domain name<1B>. You place this unique name in an LMHOSTS file to tell a computer to connect to a domain's PDC.
Suppose you have a domain named CATS, and the PDC for the CATS domain has the IP address 110.100.200.90. You set up a two-way trust relationship between CATS and another domain, and you want every domain controller in the other domain to be able to find the CATS PDC. Add the following line to each domain controller's LMHOSTS file:
Note that PDCs' NetBIOS names, like BDCs' NetBIOS names, must be 16 characters long. Thus, the CATS PDC registers a name that consists of the domain name, 11 spaces, and the hex 1B.
Providing domain controllers with the IP addresses of other domains' PDCs is useful, and it doesn't have the disadvantage that directing a machine to one BDC has. Recall that placing a <1C> entry in a workstation's LMHOSTS file instructs the workstation not to use WINS to locate a domain controller and renders the workstation blind to all the domain's other BDCs. You don't create a similar problem when you use a <1B> entry in an LMHOSTS file to identify a PDC. Your domain has only one PDC, so short-circuiting WINS doesn't cause the machine to ignore any computers that it might otherwise connect to. The only problem with specifying PDCs in LMHOSTS files is that if you promote a BDC to a PDC, you'll have to either go back and redo all your machines' LMHOSTS files or give the new PDC the old PDC's IP address.
Finally, I found that placing a <1B> entry in a domain controller's LMHOSTS file solves a compatibility problem between Windows 2000 (Win2K) and NT 4.0. Before I thought of specifying a PDC in my domain controllers' LMHOSTS files, I tried to establish a trust relationship between an existing NT 4.0 domain and several Win2K domains. For some reason, the NT 4.0 PDC couldn't find some of the Win2K domain controllers. I solved this problem by naming the Win2K PDCs in <1B> entries in the NT 4.0 machine's LMHOSTS file.
LMHOSTS files are useful in solving some standard WINS-connectivity problems. Thanks to my Microsoft correspondent for pointing out improvements to my LMHOSTS method.