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:
110.100.200.90 "CATS
\0x1B" #PRE
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.