\[Editor's Note: Do you have something to share with other readers who visit Windows NT Magazine online? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (300 to 700 words) to [email protected] along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100. Reader to Reader submissions are the reader's opinion and do not necessarily represent the views of Windows NT Magazine.\]
The Missing Computers
Have you ever created a new subnet of your domain only to find that the new nodes don't appear in Network Neighborhood? Well, this is exactly what happened when the company I work for opened a new branch office.
We use frame-relay technology for our other five branch offices, but we wanted to use a VPN tunnel, a cost-effective solution that many companies are turning to, for the new branch. With our VPN connection, data leaves the host site via a fractional T-1 connection to the Internet using a Cisco 2611 router for security purposes. On the remote site, a cable modem receives the data via a Digital Subscriber Line (DSL) connection to the Internet and passes the data along to another Cisco 2611 router (to create the tunnel) and then to the LAN through an SMC switch.
When we initialized the VPN, we had the connectivity— we could contact all nodes on the remote site by pinging them from the host site— but the nodes wouldn't appear in Network Neighborhood from the host site or from other remote sites. As a result, we determined that our problem wasn't a NetBIOS name-resolution issue because we had instituted WINS and a LMHOSTS file, and both do a fantastic job of matching NetBIOS names and IP addresses. In fact, we could successfully run a Find Computer from a host-site computer using a remote-site PC's IP address or NetBIOS name. Therefore, we determined that our problem must be a browsing issue.
From the subnet, I ran the Microsoft Windows NT 4.0 Server Resource Kit utility browstat.exe and determined that an active master browser running was indeed running. Next, I checked the master browser's Event Viewer, and a repeated entry, event ID 3013, caught my eye. The entry's message said, "The redirector has timed out a request to WEB" (WEB being the domain's master browser back at the host site), which suggested that the subnet master browser was possibly running into problems when it attempted to send a datagram of the subnet computers back to the master domain browser.
If you've dealt with DSL, you know that the connection can be slower than a frame-relay connection, which we had become accustomed to in our other branch offices. The average ping time from the host site to a remote location over frame-relay was around 70ms, but for DSL it was closer to 180ms. I searched TechNet and found article Q148950, "Changing the Windows NT Redirector Time-Out Value," which discusses a similar scenario where the redirector would time out. I followed the brief procedure that the article presents and changed the Registry to increase the NT redirector timeout value from the default 45 seconds to 200 seconds. After we rebooted the master browser at the remote site, our problem disappeared. The browsers from both subnets could communicate, and the missing computers finally appeared in Network Neighborhood for much easier access.
—Will Dalton
[email protected]
