Revelations about these less-than-perfect NT features
In this month's column, I'll bring to light some of Windows NT 4.0's dirty little secrets. Although I consider NT 4.0 to be reasonably solid, it has a few loose ends that can cause users and administrators stress. These loose ends are NT services that break easily or never worked correctly. I call these fragile services glass jaws. One of NT's most notorious glass jaws is Windows Internet Naming Service (WINS).
NT's Achilles' Heel
WINS easily wins the "Most Broken NT Component" award. WINS performs dynamic NetBIOS name-to-IP address mapping and resolution on Microsoft networks. Systems register their names and IP addresses with WINS servers, and WINS-enabled clients query WINS servers with a computer's NetBIOS name to identify the IP addresses of remote machines. This functionality is crucial to the operation of many applications and network and OS services.
WINS usually works well in single-site networks that have only one or two WINS servers. However, problems arise when you extend a WINS infrastructure to a routed, multisite IP network. In such networks, you configure WINS servers as push, pull, or push-and-pull replication partners with WINS servers in your enterprise's other sites. Through this replication, the sites share name-to-IP address databases, a process that facilitates enterprisewide name resolution and browsing. However, WINS server replication frequently results in corrupted WINS databases. In addition, WINS has problems handling multihomed NT servers and workstations, as NetBIOS-over-TCP/IP name conflicts and other entries in WINS servers' event logs demonstrate. These problems result in networkwide name-resolution and browsing problems that necessitate extreme action (e.g., purging and rebuilding the WINS database) to resolve. You can use special WINS database entries or disable specific WINS-related bindings (e.g., the NetBIOS bindings) on one of the adapters via the Network Control Panel applet to remedy the multihomed name conflicts. However, this solution isn't well documented.
A Pain in the RAS
Why discuss WINS problems in a column about Remote Access Service (RAS)? The WINS problems I've described can wreak havoc with your RAS clients and servers, especially affecting NT's Routing and RAS (RRAS). For example, WINS can cause an annoying NetBIOS name conflict when you disconnect a WINS-configured laptop from the network and dial in to your RAS server before WINS has expired the name it registered to the laptop's NIC. In this situation, your RAS client can't connect to the network. Although this dilemma isn't network threatening, it illustrates that TCP/IP-based Windows networking functionality depends on proper WINS operation. You can use WINS Administrator or WINSCL to manually remove the WINS client registration.
Another example is WINS servers' rejection of RRAS servers that attempt to establish Virtual Private Network (VPN) connections to their counterpart RAS servers via Point-to-Point Tunneling Protocol (PPTP). The receiving RRAS server's NT Event Viewer shows a mysterious message informing you that it can't project the remote computer's name onto the network. To cure this problem, try restarting WINS on the receiving RRAS server's network. If this solution fails, you might need to reinitialize the WINS database on the receiving RRAS server's network. (You might have to reinitialize both sites' WINS databases if the WINS servers are replication partners.)
Another Dirty Secret
RRAS isn't defect-free. Mutual authentication of RRAS servers is a common problem. For example, a remote office RRAS server dials the primary office server and establishes a connection, but the remote RRAS server doesn't respond when the primary office server attempts to make a reciprocal connection. I've found this problem usually requires a full reboot of the remote office's RRAS server.
This solution isn't convenient. After all, you don't want to take your West Coast office offline because RRAS can't properly reestablish its VPN. RRAS needs to be more robust—organizations depend on this service to establish corporate WAN connections.
Until Microsoft fixes these NT glass jaws, large organizations have valid reasons to question NT's enterprise readiness. As a result, NT's deployment and acceptance in the enterprise market will suffer.