SAN MATEO (03/20/2000) - We have one physical network with two network IDs (204.xxx.xxx.x and 192.xxx.xxx.x). Any PC on the network could be given an address in either series. In this way all the PCs can access the other PCs on the network. Now we have implemented a WINS [Windows Internet Naming Service] server on the network. The WINS server is also the primary domain controller.
We have configured all the Microsoft Corp. Windows 95 machines to use this WINS server to log in to the domain, as well as for name resolution. All clients are also assigned a workgroup name. In every workgroup some PCs have 204 series and some have 192 series addresses. But when we browse a workgroup through Network Neighborhood, we can see only those PCs that share the same IP series. This is not two different networks. How can we get all PCs in the same workgroup to see each other?
Brooks: This is typical WINS. It's not really a problem; it's part of the way WINS and NetBIOS work. It doesn't matter if the two subnets are on the same wire; once you're up at this layer, you might as well have the systems on separate wires connected by a router.
I think what's going on here is that you've got both workgroups and a domain in play. The way you're going to get every machine to show up in Network Neighborhood (or net view) is to use the domain. Domains can handle routed networks because the central WINS server keeps track of machine names and addresses. When you browse the domain, you're really getting a list of machines from the WINS server.
Workgroups, however, are relics from Windows 3.0, and they weren't designed to be used in a routed environment. Even though NetBIOS may be running over IP, and your machine may register with a WINS server when it boots, the workgroup isn't going to see machines on another network. You can manually get to them with \\machinename, and NetBIOS will resolve the name against the WINS server, but I don't know a way to trick Windows into making machines from another network appear in workgroups.
Lori: One more thing that you could check is whether or not each subnet has its own master browser and whether or not that master browser contains an LMHost file containing each primary and backup domain controller. As Brooks mentions, there may be a problem using both workgroups and a domain; you may want to change this scenario or at least alter the names of the workgroups to match the domain name. (If the names match, then the clients will show up in Network Neighborhood.)There are several articles online to help with this issue. Microsoft's support pages (support.microsoft.com/support/kb/articles) discuss ways to browse across subnets when using TCP/IP and WINS. Some of these antidotes require changes to Registry settings. However, if you are unfamiliar with making these changes, you could wind up reinstalling the entire system, so proceed with caution.
Another suggestions is to place a WINS server on each side of your subnet. Or it may be time to install a hardware router (from Cisco, for example), as they are designed to use multiple route tables, whereas Windows NT is designed for a single route table.
Viewing the source with IE5
We thank reader Richi Jennings for sending us some advice this week. "Your recent column about the default for saving Web pages in Internet Explorer 5 reminded me of a work-around that I've used in the past. [See "How to work around IE 5.0's defaults while saving Web pages," Feb. 28.] This also is a great way to save those pages that refuse to save dynamically generated pages from a CGI or ASP (application service provider) program.
"I always use this when booking a hotel room or a rental car on the Web, and want to save the confirmation page. If you use File|SaveAs, IE 5 often will not save the page you're seeing.
"The work-around is to use View|Source in IE. This pulls up in Notepad the actual HTML for the page you're looking at. Now, you can choose File|SaveAs 'HTML only,' by simply typing in the full file name (such as hotelbooking.html) and clicking OK."
Brooks Talley is senior business and technology architect for InfoWorld.com.
Lori Mitchell is a senior analyst in the Test Center. Send your questions for them to email@example.com.