Recently, I received a multitude of email messages about a problem in which RAS clients can't browse a remote Windows NT network. The following excerpt from one of these messages details the symptoms of this common problem:
"I use RAS to connect to an NT domain from a Windows 95 workstation that is a member of the workgroup with the same name as the NT domain. I know my system is connected because I can ping and run Net Use commands; however, the machines in the domain/workgroup on the other side of the RAS connection don't appear in my machine's Network Neighborhood. I can use Find Computer to find the other machines, but they still don't appear in Network Neighborhood. I tried putting an LMHOSTS file on the RAS client, hardwiring the address of the WINS server into the RAS client, and using NetBEUI, to no avail."
I boiled down to the most common causes of these RAS-related browsing problems. If you're having browser-related problems with a RAS client, use the following checklist to diagnose and solve your problem.
Wacky workgroups. On the Identification tab of Control Panel's Network applet, ensure that you set the RAS client's workgroup name to the same name as the remote NT domain or workgroup that you're dialing into. This setting is the most common cause of RAS-related browsing problems.
Watch your WINS. If you're using only IP, be sure that you're registering the client with a WINS server on the remote network. This registration happens automatically if you're using DHCP to assign RAS client addresses and if you configure your DHCP scope to provide WINS server information. (If you use DHCP to assign RAS clients' WINS addresses, load NT Service Pack 4—SP4—on the RAS and DHCP servers. Otherwise, you might run into the DHCP leaking problem I discussed last month.) However, if you're using static addressing or if you don't configure your DHCP scope to provide WINS server information, you need to use the Specify name server addresses option in the Dial-Up Networking Phonebook Entry Properties dialog box to manually assign the WINS server addresses on each RAS client that dials in. Another trick that increases the reliability and performance of IP-only RAS connections is to use LMHOSTS files on the RAS clients. This setup speeds name resolution.
Multihomed mayhem. When you use TCP/IP and WINS, avoid using a multihomed WINS server—especially if that server is also the domain master browser or segment master browser. Multihomed master browser systems provide the domain master browser (i.e., the PDC) with information from only one NIC and might not provide a complete server list.
Protocol pitfalls. If you're using only the IPX/SPX protocol for a RAS connection, you won't be able to browse a remote network. To browse a remote network, you must also use NetBEUI or TCP/IP. NetBEUI is the most hassle-free and self-healing protocol for RAS-related browsing on a single network segment.
Use that gateway. If you're using TCP/IP on the RAS connection, verify that you've selected the Use default gateway on remote network option in the TCP/IP settings of the Dial-Up Networking Phonebook Entry Properties dialog box. If you don't select this option, you can have problems if the WINS server on the remote network is on a different subnet than the RAS server.
Allow access. Verify that you selected the Allow RAS clients to access entire network option on the NT RAS server. Selecting this option lets the RAS client communicate with machines other than the RAS server.
Browse list brevity. If Network Neighborhood lists a partial browse list or only the RAS server, ensure that all of the missing servers share at least one common protocol with the RAS server because browsing works on a per-protocol basis. So, if you're dialing in with only NetBEUI on a network that contains two servers running NetBEUI (e.g., the RAS server and another server), those are the only two servers you'll see in a browse list.
Be unique. Each RAS client that you use to dial in must have a unique name on the network. If the remote client is a laptop that was recently connected via a LAN connection, allow enough time for the browse list to drop the machine before dialing in. Otherwise, a conflict can occur.
Verifying the items on this list will solve most of your RAS-related browsing problems. The remaining 1 percent are usually anomalous problems that require solutions that range from performing a repair of a corrupted WINS database to reinstalling the OS on the RAS client.