Need a Name-Resolution Solution?

A tip to avoid a pesky name-resolution problem

In the past few months, I've discussed a few bizarre RAS problems. This month, I share insights about a name-resolution problem that is virtually guaranteed to happen to administrators who change the network adapter on their RAS server. Read on to learn how you can avoid this RAS gotcha.

I first discovered this problem when one of my clients upgraded its RAS server's hardware. The server upgrade was straightforward and relatively problem-free because the client used disk-to-disk imaging software to copy data from the existing system to the new server. The hardware RAID controller installed on the new server required support, but the only Windows NT driver change that the new hardware platform required was a driver to support the server's dual-channel network adapter. Otherwise, the new NT installation was identical to the existing and properly functioning server configuration.

Everything seemed to be working well until RAS clients dialed into the server. They reported an inability to access the Microsoft Exchange Server, but I suspected that the underlying problem was name resolution. Further investigation confirmed this suspicion: RAS clients could successfully connect and ping all machines on the network, but they couldn't resolve any network machine names, including their Exchange Server. I jumped to the conclusion that WINS was the culprit in this case. I assumed that WINS had corrupted its Jet database, so I cleared the WINS database. I was surprised to discover that clearing WINS didn't help, nor did manipulating the LMHOSTS files and using the nbtstat—R commands to purge and reload the files' NetBIOS over TCP/IP (NetBT) name table. Apparently, WINS wasn't the source of the problem.

After a bit of head scratching and some further diagnostics at the RAS client and the new RAS server, a ray of light appeared during a battery of ping tests. When any machine on the network pinged the RAS server, the server replied from an address that didn't belong to its Ethernet adapter. I identified the IP address the server was using as the address of one of the RAS server-created adapters (i.e., an interface the server uses to communicate with incoming RAS clients). After musing over what would cause NT to issue a RAS-assigned IP address ahead of an actual network adapter's address, I realized that the problem must lie in the network bindings order.

Let's review the network bindings order and how NT makes services, protocols, and adapters work together. High-level network components and services (e.g., RAS, WINS) are bound to certain network transport protocols (e.g., TCP/IP, NetBEUI, IPX/SPX), which in turn are bound to network adapter drivers (i.e., your Ethernet adapter's driver or a RAS adapter/remote access WAN wrapper). To see these relationships, go to the Bindings tab of the Network applet in Control Panel. On this tab, you can list bindings by adapter, protocol, or service. The bindings order dictates the preference order in which higher-level services and applications use transports and adapters.

The problem with my client's RAS server was that TCP/IP was bound to all the RAS adapters first and the system's Ethernet adapter last. This address order caused the server to use the RAS-assigned IP address to reply to local Ethernet clients who queried the server by name. This address order also caused RAS clients to fail name-resolution requests because the WINS server was registered on the Ethernet adapter but the server was advertising a different IP address.

When I reviewed the events that led up to the problem, I discovered that when you add a network adapter to a RAS server, the server adds the adapter to the bottom of the network bindings order list. This placement can affect services that are sensitive to the bindings order. So, when you add a new network adapter to a RAS server, be sure to have the system's Ethernet adapters bound to each network transport protocol before any RAS bindings. Otherwise, your RAS clients might become name-challenged.