The LMHOSTS Solution
How can my fictitious firm compel Chicago machines to use Chicago domain controllers? If users have Service Pack 4 (SP4) on their workstations, administrators can use SETPRFDC to connect Chicago machines to Chicago domain controllers. (For more information about the SETPRFDC utility, see "SETPRFDC," page 203.) Alternatively, administrators can use an LMHOSTS file to solve the problem, although this solution is a bit more labor-intensive than the SETPRFDC fix.
LMHOSTS is an ASCII file that you can place on an NT machine to help the machine find other computers using the other computers' NetBIOS names. If you have a machine named LEATHERBACK at IP address 165.109.30.21, you can tell another NT machine on the network how to find LEATHERBACK by adding the following line to the other NT machine's LMHOSTS file:
165.109.30.21 LEATHERBACK
However, if you have configured the NT machine to use a WINS server, the NT machine queries the WINS server first and looks in the LMHOSTS file only if WINS can't find LEATHERBACK. You can override this process and make an LMHOSTS entry supersede WINS by adding the #PRE metacommand to LMHOSTS, as follows:
165.109.30.21 LEATHERBACK #PRE
This LMHOSTS line ensures that when that machine is looking for LEATHERBACK, it looks only to 165.109.30.21 and doesn't query WINS at all.
How does this help you find domain controllers? Suppose LEATHERBACK is a domain controller in the SEATURTLES domain. LEATHERBACK identifies itself as a SEATURTLES domain controller by registering the NetBIOS name SEATURTLES<1C>, the domain name with a hexadecimal value 1C appended. All NetBIOS names must be exactly 16 characters long; NT pads shorter names, such as SEATURTLES, with blanks to the right, so LEATHERBACK's exact NetBIOS name is SEATURTLES<space><space><space><space><space><hex 1C>. (The #DOM metacommand supposedly performs the same function as this 1C stuff, but my Network Monitor experiments show that #DOM isn't a replacement for the hex 1C.) To force a machine to use LEATHERBACK as its domain controller, you need to create an LMHOSTS entry that represents this bizarre-looking name. The entry looks like
165.109.30.21 "SEATURTLES \0x1C" #PRE
You build this line by entering, in order, the IP address, a space, a quotation mark, the name of the domain—not the name of the domain controller—then enough spaces to make the name 15 characters long, the characters \0x1C, a quotation mark, and the #PRE metacommand. Put this LMHOSTS file in the Winnt\system32\drivers\etc directory on the NT machine that you want to force to use LEATHERBACK for logons. When that machine next boots and seeks a domain controller, it won't broadcast logon requests or query WINS; it will go straight to LEATHERBACK for logon.
This isn't an answer for every network that's having problems with authentications across slow links. This solution requires an LMHOSTS file on every workstation, and installing that many LMHOSTS files can be labor-intensive (although logon batch scripts can help reduce this workload).
The LMHOSTS solution can be a blessing in scenarios in which trust links between two trusted domains are constantly breaking. For example, suppose domain A and domain B trust each other. You reboot one of domain A's domain controllers, and because the domain controller knows about the domains' trust relationship, it looks for a domain controller in domain B to perform its users' domain B authentications. But if the domain A machine is unlucky, it might choose a domain B domain controller that isn't reliable. If the domain B machine fails and the domain A machine can't quickly find another domain B domain controller to partner with, the trust between the domains will break. You can solve this potential problem by using an LMHOSTS file to point domain A domain controllers to reliable domain B domain controllers.
Be aware that using LMHOSTS removes the automation and fault tolerance that NT's standard logon process provides. If the domain controller in a machine's LMHOSTS file isn't online when the machine tries to log on, the machine simply doesn't log on. LMHOSTS, can't fall back to WINS if the logon is unsuccessful. And you can't hedge your bets by adding the names of multiple domain controllers to LMHOSTS because NT machines use only the LMHOSTS file's last entry for each domain.
LMHOSTS is a nice solution for NT machines. Unfortunately, LMHOSTS can't force Windows 98 or Win95 workstations to log on to a particular domain controller. I haven't found a solution to the long-distance domain controller problem for Windows 9x machines.