Resolving RAS browsing problems
I hate Remote Access Service (RAS). I mean, I really hate RAS. Or rather, I hate dial-up connections and the vagaries of phone line quality, busy signals, and irritating squawks from modems. (I never dare turn off my speakers, because the speakers are often a system's only indicator of why a connection won't go through.) I hate dial-up connections so much that since 1995 I've had a frame relay connection from both my office and my house to the Internet. This connectivity isn't cheap (it costs me about $350 per month), but it's worth the price. I would pay for Asymmetric Digital Subscriber Line (ADSL) or two-way cable modem connections if
I could, but unfortunately I don't have access to those technologies where I live.
Back to Basics
Recently, however, I began using dial-up connections again. I'm doing a lot of writing at a remote site, a beach house in a spot that's relaxing but a bit bandwidth challenged. I set up a server back home as a RAS server, and I dial in to it from my beach house to grab files and read my mail.
As I looked at my Internet mail via RAS one day, I remembered that I've
received a fair amount of mail from people wondering how to get Network
Neighborhood to work with RAS. The problem occurs in the following scenario: A user sits at home or in a hotel room at a Windows NT Workstation or Windows 95 computer and uses Dial-Up Networking (DUN--the name of the client side of RAS) to dial in to her company's NT network. She knows she connects fine because she can ping machines inside the company's network. But when she opens Network Neighborhood, she sees only her workstation.
I had a Win95 OEM Service Release (OSR) 2.1 workstation at the beach, so I decided to try using it as a DUN client to connect to my network at home. The network is a domain named ORION, so I set the Win95 machine's workgroup name to ORION. I dialed in to my network at home and connected without trouble. I pinged all the computers on my network. Then, I opened the Win95 machine's Network Neighborhood. Sure enough, the only machine in ORION was PRESARIO, my Win95 computer. I rebooted the machine in NT Workstation and got a similar result.
The Trail of Bugs
Because I could ping computers on the network but couldn't view
machine names, I figured the problem was a NetBIOS naming problem. To resolve the problem, I tried creating an LMHOSTS file that contained the names of the ORION domain controllers. LMHOSTS is an ASCII file that opens Win95's Windows directory or NT's winnt\system32\drivers\ etc directory.
You can create LMHOSTS files in Notepad or any other editor, but don't include a file extension on them. (For more information about LMHOSTS, see "Inside a NetBIOS Name Resolution," March 1997.) I chose to open the Winnt\system32\drivers\etc directories on my domain controllers because domain controllers are usually the machines that contain the information that drives Network Neighborhood; they're the browse masters for NT domains. My LMHOSTS file looked like
210.43.52.40 Betelgeuse #DOM:ORION #PRE
210.43.52.51 Rigel #DOM:ORION #PRE
The 210.43.52.x numbers are the IP addresses of ORION's domain controllers, Betelgeuse and Rigel.
LMHOSTS didn't fix my Win95 problem, but it helped NT Workstation. After I created LMHOSTS, NT Workstation required me to press F5 to refresh Network Neighborhood. But when I did, all the ORION domain's machines appeared.
I erased the LMHOSTS file, and through the DUN phone book, I forced the
TCP/IP stack to look to the Windows Internet Naming Service (WINS) server back home for NetBIOS name resolution. This solution also seemed to fix the problem in NT Workstation but not in Win95. If you're running NT Workstation 3.51, you might have to take one more step: Run NetBEUI. I know this solution sounds odd, but NT 3.51 dial-up clients have trouble browsing the network unless they're running NetBEUI. My limited experience with NT 4.0 dial-up clients suggests that they browse fine using TCP/IP, as long as they have an LMHOSTS file or a connection to a WINS server.