Without a doubt, the most common RAS questions I get relate to name resolution. Most of the name-resolution problems that readers write me about tend to display similar symptoms: "My TCP/IP-based RAS clients dial in to my network, and the server authenticates them with no problems. The RAS clients can ping every machine on the network, including the WINS server; however, they're unable to resolve any name on the network. My only solution has been to use HOSTS or LMHOSTS on the local RAS client."
In previous columns, I've discussed several potential causes for RAS name-resolution troubles, including some nasty WINS foibles that can wreak havoc on RAS. (For more information about name-resolution problems, see Watch Your RAS, September 1999, May 1999, April 1999, and February 1999.) This time, I have another candidate for the WINS weirdness category—an odd Windows NT bug that prevents RAS clients from resolving names through WINS.
When I first encountered this problem in the field with one of my clients, the primary symptom was an inability to remotely log on to the domain. The system presented us with the all-too-familiar message No domain controller was available to validate your password. However, I quickly discovered that the problem's underlying cause was an inability to properly communicate with WINS. We could ping the WINS server from the RAS client, but when we used the Microsoft Windows NT Server 4.0 Resource Kit Winscl tool to run WINS server connectivity tests, the results showed that something odd was afoot. (For more information about Winscl, see Mark Minasi, This Old Resource Kit, "WINSCL," August 1998.) Although Winscl could contact the WINS server, name-resolution queries and almost all the other Winscl commands returned a failure status to the client. A deeper investigation of the problem proved that RAS clients weren't the only ones affected by this problem: LAN-based clients weren't communicating with WINS, either. However, the LAN users and administrators didn't notice problems because the local systems were resorting to broadcasts to resolve names over TCP/IP after the point-to-point (i.e., WINS) resolution efforts failed. By default, RAS clients can't resolve names by broadcast; thus, they became the canaries in this coal mine.
To begin solving this problem, I examined WINS. Sure enough, an examination of the WINS database (using WINS Manager) revealed that a problem existed: Rather than showing owner records that represented the client's internal IP addresses that the client had configured to register with the WINS server, the WINS database showed a peculiar owner record IP address of 0.225.0.184. After scouring Microsoft's Web site for a solution, I found the Microsoft article "Unusual Addresses Like 1.10.0.184 Showing in WINS Database" (http://support.microsoft.com/ support/kb/articles/q156/2/04.asp). This article discusses a problem in which strange IP address entries appear in the WINS database. The article also shows a phantom IP address nearly identical to my client's strange IP address. Although the article doesn't mention WINS resolution as a victim of this problem, the article suggests a possible solution: Reorder the network bindings on the Control Panel Network applet's Bindings tab so that the LAN adapter for the WINS Client (TCP/IP) protocol entry, rather than a RAS WAN wrapper entry, appears first. An inspection of the bindings order on the problem system revealed that the server listed a RAS WAN wrapper entry ahead of the server's NIC. After we changed the WINS Client bindings order to list the server's NIC first, we rebooted the server and cleared the WINS database of all traces of the phantom entries. At that point, RAS clients could resolve names and log on to the network.
The bindings order has caused other network and RAS-related problems that I've encountered, so this problem's resolution wasn't a complete surprise to me. However, I was amused to notice that the Microsoft article lists "weird funny bogus strange" in its Additional query words section. I didn't know Microsoft uses bogus as an indexing keyword. However, in this case, I definitely agree.
