A Workaround for When Workgroup Networks Won't Work A Cure for a Common Workgroup Network Conundrum Ron Pacchiano
Ten PCs – some wireless, some not – a network without a server, and office workers who need to share info can add up to a great deal of frustration. Here's networking guru Ron Pacchiano's advice and recommendation.
Q.
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, including myself, seems to be able to resolve.
Our office network is made up of 10 computers in a workgroup configuration. All of the computers are connected to a D-Link wireless router. Of these 10 computers, four are connected wirelessly. At least half of these machines have data on them that needs to be shared among the office staff. From any of the six PCs that are physically wired to the router, there is no problem accessing this data . All of the machines are visible in Network Neighborhood, but for some reason none of the wireless PCs can see or access any of the other workgroup PCs. This is in spite of 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, though, 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 are running a combination of Windows XP and Windows 2000 Professional. File and Print Sharing is enabled, and NetBIOS over TCP/IP is enabled on both the wired and wireless interfaces. I've tried upgrading all of the drivers, and each wireless PC is using a different type of wireless adapter. Two have an integrated wireless adapter, one is PC card-based, and the other is using 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 to be useless.
So as of now I am not only disgusted but officially out of ideas. Any advice you can offer that might help to resolve this situation would be greatly appreciated. Thank you!
A.
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 are apparently having similar problems. Unfortunately, no one had posted a viable solution to the problem — at least not a confirmed or reliable one. As you mentioned, many people were recommending disabling WPA (but not WEP), while some others suggested making a few registry changes, none of which looked too promising.
I myself have run into this problem on one or two occasions, and getting around it has always proven to be difficult. Personally, I feel that 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 could be the cause of 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. That said, the only thing I can suggest you try is 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 in the past, this has worked for me.
An LMHOSTS file, for those 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%\SYSTEM32\DRIVERS\ETC directory in Windows 2000 and Windows XP. The file is named LMHOSTS.SAM. After you make the appropriate changes to the file, it must be saved as LMHOSTS (without the SAM extension, or any other extension for that matter) before it can be used. This is important to note because sometimes Notepad will inadvertently add a TXT extension to the end of a document's filename. A .txt extension would prevent the file from functioning properly.
The format of the LMHOST file is typically the IP address and system name, followed by 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. An example of the contents of an LMHOSTS file would be:
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 such as 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. So I would recommend that you assign a static IP address to each system, at least until you upgrade to a client/server environment where the LMHOSTS file will no longer be needed. (Some shops, though, do put the name and IP address of a domain controller in the LMHOSTS file of a dial-up machine to speed up authentication.)
Some additional LMHOSTS configuration information can be found in the Microsoft Knowledge Base. This article applies to Windows XP systems, and this one applies to Windows 2000 systems.
One last thing I would like to point out — at 10 workstations, you're quickly approaching the limits of a practical workgroup. Some of the problems associated with the workgroup model are the fact that there is no centralized authentication system that maintains the user and PC accounts on the network. This means that the majority of the communication that takes place on the network is being controlled by one PC that somehow took it upon itself to be the network's Master Browser. As you have already discovered, this can be problematic.
In a client/server environment, there are numerous ways for PCs to find each other. Inclusion in the Active Directory, NetBIOS broadcast, WINS servers, and DNS servers. All of these would help prevent the problem you're currently experiencing. So until you upgrade, I think the LMHOSTS file is your only recourse. I hope this helps.
