In TCP/IP-based networks involving routers and multiple segments, it isgenerally recommended that you implement WINS for name resolution andbrowsing support. However, as an alternative to WINS, it is possible tohave full domain browsing by using only LMHOSTS files on all computers,although there are some limitations that will be discussed in this article.
In either case, it is important to note that a client only participates in domain browsing when the client is using a workgroup name that is equivalent to the domain name (WorkgroupName = DomainName). Windows NTcomputers can also "join" the domain to gain this functionality, instead ofbeing in a workgroup.
This functionality of LMHOSTS-based domain browsing (over routers) has notbeen formally documented or tested by Microsoft, and may not be availablein future versions of the client and server operating systems. Use thisinformation with discretion.
"Browsing" in a Microsoft network should be considered a distributedservice provided by one or more computers. Each computer can fall intoseveral browser roles; however, this article focuses on the two mostimportant ones:
- Segment master browser (SegMB): This can be any Windows NT Server, Workstation, or domain controller. It can also be a Windows 95 or Windows for Workgroups 3.11 computer. It is responsible for maintaining a browse list of the computers on its local segment, forwarding that list to the domain master browser, and requesting the domain browse list from the domain master browser. The SegMB merges the domain list with its local list, and make that list available to any local client that requests it.
- Domain master browser (DomMB): This is the Windows NT primary domain controller (PDC). It is responsible for maintaining the browse list on its local segment (like a SegMB), as well as collecting browse lists from other (remote) segment master browsers with the same domain name (or WorkgroupName = DomainName). The DomMB merges the lists it collects, along with its local list, then redistribute the combined list back to all the remote SegMBs. Thus it is the central hub for maintaining the domain-wide browse list.
: The Windows for Workgroups browser requires updated files.
For more information, please see the following article in the Microsoft Knowledge Base:
Information on Browser Operation
In order for this distributed browse service to work, the SegMBs need a wayto determine exactly who the DomMB is. They can determine this by locatingthe computer that has registered the NetBIOS name "Domain<1b>", because that is only registered by the PDC (which also is the DomMB, as noted above).
For more information, please see the following article in the Microsoft Knowledge Base:
List of Names Registered with WINS Service
Domain Browsing with WINS
In a WINS environment, a SegMB would query WINS to determine who registeredDomain<1b>. In this case WINS acts as a convenient central resource for this information. There is one more benefit in having WINS to assistbrowsing: multi-domain browsing.
Multi-Domain Browsing with WINS
A PDC that is set up to query WINS periodically requests the list ofall domains that are registered in the database. (A domain is identified bya "Domain<1b>" registration in the database, and the associated IP address of the PDC that registered it.) The PDC combines this with its own domain browse list, and thus has a complete list of computers in itsdomain, as well as a list of other domains, all across the WAN. When thePDC then interacts with its SegMB's, it gives them this complete list. Youthen see the effect of this when you browse the network using File Manageror Network Neighborhood.NOTE
: That is the extent of WINS involvement with browsing. It is not involved in the browser election process, nor with helping a clientdetermine who its local segment master browser is, nor with helping theDomMB determine who the SegMBs are; that is done in the process when theSegMB first contacts the DomMB.
In certain networks it may not be valuable to use WINS; this can only bedetermined on a case-by-case basis. You can then use either LMHOSTS or DNSto resolve computer names; however, LMHOSTS are required for domainbrowsing, as well as other domain management issues such as databasereplication and domain secure channels.
Domain Browsing with LMHOSTS
Without WINS, you need special LMHOSTS entries that designate who allthe domain controllers are. This is done in the following convention:
22.214.171.124 ComputerName #PRE #DOM:DomainName
When a computer is booted, it reads these entries and store thempermanently in the NetBIOS name cache until the computer is powered down.(Because of this, it is best that these entries are last in the LMHOSTSfile, for subsequent LMHOSTS parsing efficiency.) All computers in thedomain needs one of these entries for each domain controller (in thelocal domain), as well as one for the PDC. Also note the exact order of#PRE #DOM, and that they are capitalized. The other names are not casesensitive.
Windows NT Segment Master Browsers
Having the above entries is sufficient for a Windows NT computer: Uponbecoming a Segment Master Browser, a Windows NT computer determines who thePDC is by sending a query (using the NetGetDcName API) to all LMHOSTSentries with the #DOM:<localdomain> designation. Only the PDC responds. The Windows NT computer then contacts the PDC, informs the PDC that it is a master browser, then continues the process of getting the domain browse list. The PDC then contacts the Windows NT computer to get its local segment browse list. This process repeats every 12 to 15 minutes.
Windows 95 and Windows for Workgroups Segment Master Browsers
These do not perform the NetGetDcName API, so they need entries in theLMHOSTS file that indicate who the PDC is. Assuming the example above isthe PDC of the domain, you would have two entries for a Windows 95 orWindows for Workgroups client:
126.96.36.199 controller1 #PRE #DOM:domainname 188.8.131.52 "domainname,,,,,\0x1b" #PRE
The first entry allows the PDC to act as a logon domain controller for theclient, the second entry allows the client browser service to explicitlyfind the PDC. Remember you will probably have multiple lines similar to thefirst line (for multiple domain controllers), but only one line with the\0x1b directive (to designate the PDC). Note that the domain name must bein quotes, and padded with spaces for a total of 15 characters before the\0x1b portion. (The example above shows commas for visual placeholders,however in a real LMHOSTS file these commas would be replaced with spaces).Also be aware that moving the PDC role to another Windows NT Server (viapromotion) will cause your \0x1b entry to be invalid. Options to fix this:
- Switch IP addresses on the controllers, so effectively the PDC alwayshas the same address. You would not need to change anything in the LMHOSTSfile.
- Change the \0x1b IP address in all the LMHOSTS files on the clients, or on the centrally distributed LMHOSTS file (if you are implementing that).
Note About NetBIOS Names
Every NetBIOS name is a full 16 characters in length; the first 15 are userdefinable (or padded with spaces), and the 16th character is reserved toidentify the network service that registered the name. The most familiarexample of a NetBIOS name is the ComputerName on any Microsoft networkingclient. When the client is booted, various client network services willregister the ComputerName along with their unique extension, such asComputerName<00> (workstation service), and ComputerName<20> (server service). In this case, the only difference between these two names is the 16th character - and that does make them individually identifiable. A client can register all of its names by broadcast, and by direct datagram to WINS, depending on the client node type. Other companies may also register NetBIOS extensions that are not reserved by Microsoft.
For more information, please see the following articles in the Microsoft Knowledge Base:
NetBIOS over TCP/IP Name Resolution and WINS
List of Names Registered with WINS Service
Your domain name is "Globe", your PDC NetBIOS name is "Mongo", and you haveother various backup domain controllers. Your LMHOSTS file would look likethis:
184.108.40.206 "globe \0x1b" #PRE 220.127.116.11 mongo #PRE #DOM:globe 18.104.22.168 otherdc1 #PRE #DOM:globe 22.214.171.124 otherdc2 #PRE #DOM:globe
To verify that you've entered these correctly, open a command window (DOSprompt) and look at your NetBIOS cache:
c:\> nbtstat -c NetBIOS Remote Cache Name Table Name Type Host Address Life [sec] ------------------------------------------------------------ globe <1B> UNIQUE 126.96.36.199 -1 MONGO <03> UNIQUE 188.8.131.52 -1 MONGO <00> UNIQUE 184.108.40.206 -1 MONGO <20> UNIQUE 220.127.116.11 -1 OTHERDC1 <03> UNIQUE 18.104.22.168 -1 OTHERDC1 <00> UNIQUE 22.214.171.124 -1 OTHERDC1 <20> UNIQUE 126.96.36.199 -1 OTHERDC2 <03> UNIQUE 188.8.131.52 -1 OTHERDC2 <00> UNIQUE 184.108.40.206 -1 OTHERDC2 <20> UNIQUE 220.127.116.11 -1
TIP: the <1B> entry will not show up if you do not have exactly 15characters in the name, or if you do not use quotes, or if you enter theforward slash "/0x1b" (as opposed to "\0x1b").
Multi-Domain Browsing with LMHOSTS
It is important to note that the main drawback to LMHOSTS browsing is thatit does not provide the automatic ability of multi-domain browsing. Aspreviously mentioned, the PDC will query WINS for a list of remote domainsand include that information in its browse list. However, the PDC will notparse the LMHOSTS file for the same information, nor will it include other\0x1b entries with the #PRE (cache) directive. Effectively, if your PDCdoes not query WINS, you will not see other domains through File Manager orNetwork Neighborhood. However, you can still browse other domainsmanually, (provided that you know the domain name and that you have specialentries in your LMHOSTS file), and there is still a chance that you maybrowse remote domains based on broadcasts.
Manual Method: this is accomplished by including a \0x1b entry for the PDCof any remote domain you want to browse. This technique applies to WindowsNT, Windows 95, and Windows for Workgroups. It is effective because of thefollowing sequence of events, necessary for remote domain browsing:
- The client determines who the PDC is of the remote domain through the domain<1b> name (for LMHOSTS this is done by having the \0x1b entry; for WINS it would be via query).
- The client sends a GetBackupList API request to the remote PDC
- The remote PDC responds with a list of up to three master browsers, potentially including itself.
- The client sends a NetServerEnum API request to one of the master browsers
- The master browser responds with his domain-wide browse list.
The "manual way" of getting this browse list is through a command window:
For WinNT computers: c:\net view /domain:<domainname>
For Win95 and WFW: c:\net view /workgroup:<domainname>
Broadcast Method: This works in the case of any network segment that hasmembers of multiple domains. There is a SegMB of each domain on the"mutual" segment, and each SegMB announces its domain via broadcast toa special NetBIOS name <01><02>_MSBROWSE_<02><01>. This broadcast packet includes the domain name and the computer name of the SegMB that announced it.
The SegMBs of other domains (on this mutual segment) listen for thisinformation, and add it to their local browse list. A SegMB on thissegment has now "discovered" other domains, and send the discoveredinformation to: the DomMB of his domain, and to local clients (in hisdomain) that request a browse list.
A client requests the local domain browse list (from a local SegMB) andsee the discovered domains in File Manager and Network Neighborhood. Whenthe client selects the discovered domain, he actually requests a browselist directly from the SegMB that made the announcement in the<01><02>_MSBROWSE_<02><01> packet. Furthermore, since this information was also sent to the client's DomMB, it is propagated to SegMB's on other segments that are part of this domain.
Clients on a remote segment can now leverage this information, and browsethe remote domain even though there is no remote domain member on theirsegment. However, this process is very volatile using LMHOSTS files,because you are dependent on the "discovered remote SegMB's" still beingactive. In a WINS environment, this remote browsing feature is much morestable because WINS provides information about the remote domains to yourPDC.
Things to consider:
- For domain logon and domain browsing to work via LMHOSTS, all computers require an LMHOSTS file that includes entries for all domaincontrollers and proper \0x1b entries, and the PDC requires an entry foreach remote segment master browser (if they are not already listed).
- Most likely every WAN computer is listed. This could be done mostefficiently by having one common LMHOSTS file that is distributed to allclients and servers; however, you must keep it updated with all proper IPaddress changes, and that could become an administrative burden.
- Seeing a computer in the browse list does not imply you can connect to it. If it is on your local segment, you can connect through broadcast; if it is on a remote segment, you need an LMHOSTS entry for it.