A Workaround When Workgroup Networks Won’t Work

I am the owner/operator of a small real estate company in Florida. In addition to my many regular responsibilities, I am also the company’s technology manager. Now I’m the first to admit that I don’t know everything about computer networks, but I do know enough that I have been able to keep the office up and running for a couple of years now. Recently, however, I came across a rather strange problem that no one seems to be able to resolve.

Our office network is made up of 10 computers in a workgroup configuration. All of the computers connect to a D-Link wireless router. Of these 10 computers, four connect wirelessly. At least half of these machines have data that needs to be shared among the office staff. I don’t have any trouble accessing data from any of the six PCs that are physically wired to the router. All of the machines appear in Network Neighborhood, but, for some reason, none of the wireless PCs can see or access any of the other workgroup PCs &#151 despite the fact that both the wired and wireless PCs can ping each other and have access to the Internet.

A few weeks ago you did a Q&A column that addressed an issue similar to this one. In the article you suggested that enabling NetBIOS over TCP/IP should help relieve the problem. I tried that and the other methods you suggested in the article, but none of them worked for me.

The really weird thing about the situation is that if I take one of the wireless PCs and disable the wireless adapter, then connect it to the network using the integrated 10/100 Ethernet adapter, all of the computers in Network Neighborhood become accessible. As soon as I switch back to the wireless adapter alone, the connection disappears and I get a message that says something like “You might not have the rights to access this network resource.”

I am at a lost to explain this. The wireless PCs run a combination of Windows XP and Windows 2000 Professional. I’ve got both File and Print Sharing and NetBIOS over TCP/IP enabled on both the wired and wireless interfaces. I’ve tried upgrading all of the drivers, and each wireless PC uses a different type of wireless adapter. Two have an integrated wireless adapter &#151 one PC card-based and the other uses a wireless bridge. I even tried changing my wireless router with a regular router and an access point, but the network exhibited the same symptoms. Some people suggested that perhaps WEP was interfering with it, so I disabled it. No change. I even got so desperate that I tried changing the SSID name to match the workgroup name. That didn’t work either. I tried contacting D-Link’s technical support group, but that proved useless.

As of now, I am not only disgusted but officially out of ideas. I appreciate any advice you can offer that might help resolve this situation. Thank you!

Believe it or not you’re not alone in your wireless network difficulties. While researching your problem, I did a search in Google’s newsgroups and discovered that a lot of people were apparently having similar problems. Unfortunately, no one had posted a solution to the problem &#151 at least not a confirmed or reliable one. As you mentioned I saw many people who recommended disabling WPA (but not WEP) and some others suggested making a few Registry changes. None of which looked too promising.

I’ve run into this problem on one or two occasions, and getting around it has always proved to be difficult. Personally, I think part of the problem stems from the fact that you’re using a workgroup network configuration as opposed to a more reliable client/server setup.

As far as what’s causing the problem, the only thing I can think of is that the wireless adapters aren’t broadcasting the NetBIOS information. I’m not sure why that is, but all the symptoms seem to point to that conclusion. Try creating a LMHOSTS file for each of the wireless PCs. As long as they can ping each other and TCP is configured correctly, the LMHOSTS file should be all you need to get past this problem. It doesn’t necessarily explain the cause of your affliction, but at least I can say with confidence that this has worked for me.

An LMHOSTS file, for those of you not familiar with it, is a static table that resolves a host name to an IP address and assists with remote NetBIOS name resolution on computers that for one reason or another cannot respond to NetBIOS name-query broadcasts. You can find a sample LMHOSTS file in the %SYSTEMROOT%SYSTEM32DRIVERSETC directory in Windows 2000 and Windows XP. The file is named LMHOSTS.SAM. After you make the appropriate changes to the file, you must save it as LMHOSTS (without the SAM extension) before you can use it. This is important to note because sometimes Notepad inadvertently places a TXT extension to the end of a document you’ve created. This would prevent the file from functioning properly.

The format of the LMHOST file is typically IP address, system name and the extension .#PRE. Following any entry in the file with the characters .#PRE will cause the entry to be preloaded into the name cache for faster resolution. Here’s an example of the contents of an LMHOSTS file:

• 192.168.1.110TDS-SERVER #PRE
• 192.168.1.111FRONT-DESK.#PRE
• 192.168.1.112ADMIN.#PRE
• 192.168.1.113TDS-CAMERA.#PRE
• 192.168.1.114TDS-WS.#PRE
• 192.168.1.115HELPDESK.#PRE

By running NBTSTAT -r (the r must be in lower case) from a command prompt, you can see if your name requests are being resolved by broadcast or WINS. An LMHOSTS lookup will appear as a broadcast. NBTSTAT -c will show the contents of the name cache that is loaded from the LMHOSTS file each time you boot.

The LMHOSTS.SAM sample file has much more information on the available extensions that can be used in the configuration. The file also contains information for other things like configuring it to point to a domain controller.

It is important to remember that since an LMHOSTS file contains a static computer name to IP address mapping, it may cause conflicts if you are also using DHCP to dynamically assign IP addresses on the same network. I recommend that you assign a static IP address to each system &#151 at least until you upgrade to a client/server environment where the LMHOSTS file will no longer be needed. Although, some shops put the name and IP address of a domain controller in the LMHOSTS file of a dial-up machine to speed up authentication.

You can find additional LMHOSTS configuration information in the Microsoft Knowledge Base &#151 one for Windows XP systems and another for Windows 2000 systems.

One last thing I’d like to point out: At 10 workstations you’re quickly approaching the limits of a practical workgroup. The workgroup model doesn’t have a centralized authentication system that maintains the user and PC accounts on the network. This means that one PC &#151 that somehow took it upon itself to be the network’s Master Browser &#151 controls the majority of the communication that takes place on the network. As you have discovered, this can be problematic.

In a client/server environment, there are numerous ways for PCs to find each other, such as inclusion in the Active Directory, NetBIOS broadcast, WINS servers and DNS servers. All of these help prevent the problem you’re currently experiencing. Until you upgrade, I think the LMHOSTS file is your only recourse. I hope this helped.

Adapted from PracticallyNetworked.com, part of the EarthWeb.com Network.