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.
Second Half of the Riddle
When I guessed that NetBIOS was the culprit, I was half right; LMHOSTS and
WINS fixed NT Workstation. However, NetBIOS wasn't the problem with the Win95 machine. I tried to use Find, Computer to help out the Win95 computer. Find, Computer worked, but even after the workstation found Betelgeuse, the domain controller didn't show up in the workstation's Network Neighborhood. Why not? According to Microsoft, Win95 machines don't necessarily report in Network Neighborhood all the computers they can find because of a bug in the interface between NetBIOS and TCP. The computer resolves NetBIOS names all right, but it can't pass the results to TCP. Here's how the Win95 problem happens.
Locally, you connect your laptop to your corporate intranet with a high-speed direct connection such as an Ethernet PC Card board. When you connect, your workstation receives an IP address from a Dynamic Host Configuration Protocol (DHCP) server. NT binds the IP address to your workstation's PC Card board and stores the DHCP configuration information in the Registry.
When you're about to leave for a trip, you disconnect the computer from the network, but you don't remove the PC Card board. When you arrive at your destination, you hook up a modem and dial in to your corporate RAS server. When Win95 powers up the PC Card board, it checks the board for information because it remembers that the board once had an IP address from a DHCP server. Win95 can't renew the DHCP lease on the PC Card board, but unfortunately, that fact doesn't make the OS deactivate the card.
Here's the weird part of the problem. When you dial in to your corporate intranet, you get an IP address for your DUN connection from the network's DHCP server via its RAS server. However, although the IP address that your system gets from DHCP via the modem is up and running, and although the IP address that your system's PC Card board received days before is no longer functional, your Win95 browsing traffic tries to use the currently dormant PC Card board. The result is that browsing (i.e., Network Neighborhood) doesn't work.
Cracking the Case
What can you do about this problem? You have several options. You can pop
the PC Card board out of the laptop. Reboot and redial, and your problems will likely go away. But that solution isn't always an option; this problem can occur in any situation in which the workstation has one TCP/IP stack running on a network card and another on a dial-up connection. If you connect a home computer to a small home network but also use the computer to dial in to work, you might see the same behavior. People who dial in to a central office from a branch office can fall prey to the Win95 problem. Microsoft recommends that those folks build an alternative hardware profile that doesn't include the network card. That answer isn't bad, but now you have an even better solution.
Microsoft offers two Win95 patches that you can install on your client systems. One patch replaces DUN and lets Win95 perform Point-to-Point Tunneling Protocol (PPTP) dial-ups. The other patch works with the first to fix the Win95 browse problem. You can download both patches from Microsoft's Web site.
The DUN update is msdun13.exe, which Microsoft last updated in September 1998. I would give you the URL at which you can find msdun13.exe, but Microsoft's Web site relies so heavily on Active Server Pages (ASP) that the URL would be four lines long. Instead, go to http://www.microsoft.com/msdownload/ and look in the Support Drivers, Patches & Service Packs section for the Windows95 Shareware and Utilities link. Click the link, and you'll reach another page that lists a couple dozen patches and fixes for Win95. Click Windows Dial-Up Networking 1.3 Performance and Security Update for Windows 95 and follow the links to download the 2.2MB file.
The other file you need is smaller, about one-tenth the size of msdun13.exe. If you're running Win95 in its original August 1995 version or Win95 OSR 1, you need the rasupd.exe patch. If you're running Win95 OSR 2 or OSR 2.1, you need the ras2upd.exe file. As far as I can tell, the only way to get these files is to look up the Microsoft article "Err Msg: No Domain Server Was Available to Validate" at http://support.microsoft.com/support/kb/articles/q154/4/34.asp?FR=0. (The TechNet version of the article doesn't include the RAS patches.) Or on Microsoft's Web site (http://www.microsoft.com), click Support, then Support Online. The Web site will walk you through a form that asks for personal information that Microsoft requires you to provide before it gives you the update files. (You pay for a product that doesn't work, then Microsoft makes you provide your name for junk mail lists before handing over the fix. Hmmm...) On the Support Online search page, select the Specific article ID number option and search for article Q154434. The article contains hotlinks for downloading rasupd.exe and ras2upd.exe. Download the file you need, and apply it. You'll solve the case of the empty Network Neighborhood.