Pick Users' Domain Controller

Use an LMHOSTS file to control which domain controller logs on your users and network machine

In October 1998, I attended the Microsoft Professional Developers Conference and the Networld+Interop conference. I always enjoy these types of events because they let me meet lots of Windows NT Magazine readers. An attendee of one of the October events asked me a question I'd heard before: "Can I control which domain controller logs my users on?" This question is a good one, and the answer is yes—if you're using NT machines.

Long-Distance Relationship
To envision a situation in which specifying a user's domain controller would be useful, consider an imaginary firm that uses NT. The business has headquarters in Chicago, Illinois, and a branch office in Galway, Ireland. The company has 200 people and two domain controllers in Galway and 1000 people and six domain controllers in Chicago, with a couple of 64Kbps frame relay connections linking the two sites. To make the example simple, I'll say the company uses only one domain.

At 8:00 a.m. Central time each day, all the company's Chicago users power up and log on. Some users' logons are sluggish, and those same users experience slowness in other operations, such as browsing Network Neighborhood. However, when the users reboot their systems later in the day, the sluggishness disappears.

What is the users' problem? Network sluggishness and the reboot fix are symptoms of many problems, but most likely, the users' NT machines have attached to an Irish domain controller across one of the company's 64Kbps links.

To find a domain controller, an NT system asks the local Windows Internet Naming Service (WINS) server for a list of all the domain controllers that it knows about. While it's waiting for the WINS server to respond, the computer broadcasts a request to be logged on, essentially shouting to the network, If a domain controller receives this message, it needs to log me on! NT machines always send a broadcast message when they log on. This practice increases the probability that local domain controllers log on NT computers. (For information about NetBIOS names and name resolution, see "Inside a NetBIOS Name Resolution," March 1997.)

The WINS server that the NT machine contacts delivers a list of up to 25 of that domain's domain controllers—WINS remembers only the past 25 domain controllers it has heard of. The workstation sends an invitation to each domain controller on the WINS server's list, asking the domain controllers to log it on. The first domain controller that responds to the NT machine's many logon requests logs the computer on.

So why might Galway's domain controllers, which the Chicago machines connect to via the slow WAN link, respond more quickly than the Chicago domain controllers to the logon request? Well, at 8:00 a.m., everyone in Chicago is trying to log on, so the Chicago domain controllers are busy. In addition, the fictitious firm might have committed the common error of running WINS server software on its domain controllers. This practice is unwise because WINS servers and Primary Domain Controllers (PDCs) are both busiest at the start of the day. Every system on the network is logging on—which keeps the PDCs busy—and simultaneously registering its name with WINS—which keeps the WINS servers busy. Early morning is a rough time for PDCs that double as WINS servers.

In contrast to the Chicago PDCs, which at 8:00 a.m. are trying to log on 1000 users at the same time, Galway's machines are loafing along, responding to occasional authentication requests, because in Ireland it's 2:00 p.m. When these machines receive a cry for help across the WAN, they respond—and they respond quickly compared with the overloaded Chicago PDCs. The result of this scenario is that some Chicago NT workstations (or even Chicago NT servers, because some firms reboot their servers every week or so) now look to machines thousands of miles away for their authentications. When users sit down at their machine and type their name, password, and domain name, their workstation verifies their user account with a computer across the Atlantic. The users receive rotten response times, and folks in Galway who are trying to access Chicago servers across the WAN link experience delays because the unnecessary authentication traffic is choking the transatlantic link.

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. (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 x1C" #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 x1C, a quotation mark, and the #PRE metacommand. Put this LMHOSTS file in the Winntsystem32driversetc 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.