Troubleshooting Windows Server: Name Resolution & Connectivity Problems

Table of Contents

Understanding the Problem¶

Computers running Microsoft Windows 2000 Server or Microsoft Windows Server 2003 can encounter significant connectivity challenges under specific configurations. This typically occurs when the server is set up with the Routing and Remote Access service configured to accept incoming connections. A key factor in these issues is when the same server is also hosting the Domain Name System (DNS) or Windows Internet Name Server (WINS) services.

These problems manifest intermittently after a remote computer successfully establishes a connection to the Routing and Remote Access (RRAS) server. Connections can be initiated through a dial-up network or a Virtual Private Networking (VPN) connection. The symptoms often point towards failures in correctly resolving the server’s name to its appropriate network address, especially for clients on the local area network.

While this issue can affect various Windows 2000 or Windows Server 2003 installations, it is particularly noticeable on Small Business Server (SBS) deployments. This is often because SBS is frequently the sole server on the network, combining multiple roles like domain controller, file server, and sometimes RRAS, DNS, and WINS, making the described configuration quite common in those environments.

Symptoms of the Issue¶

When the described configuration leads to name resolution or connectivity problems, several symptoms may arise. These indicate that local computers are struggling to communicate with the server using its network name. The specific issues observed can vary depending on the server roles and services active on the problematic machine.

If Microsoft Internet Security and Acceleration (ISA) Server 2000 is running on the same RRAS server, local client computers may be unable to browse the web. This inability to access external websites happens regardless of whether clients use Web Proxy or the Microsoft Firewall Client, often resulting in browser errors like “The page cannot be displayed” accompanied by messages about not finding the server or DNS.

Clients using ISA Server 2000 may also experience problems when trying to update their Firewall Client configuration. Attempting to select “Update Now” in the Firewall Client Options dialog box might produce an error message indicating that the server is not responding to the update request. This error message could suggest possible causes such as the server not being an ISA Server or the server being down, neither of which accurately reflects the underlying name resolution problem.

A common diagnostic symptom is observed when attempting to ping the RRAS server from a local computer using its NetBIOS name or fully qualified domain name (FQDN). Instead of resolving to the server’s local network IP address, the name resolution process incorrectly returns a different IP address, specifically one assigned to the remote access connection. Attempts to ping this incorrect IP address will obviously fail from the local network segment.

If the RRAS server is designated as the master browser for the local network segment, clients may be unable to properly browse the list of computers within Network Neighborhood or My Network Places. This functionality relies heavily on correct NetBIOS name resolution, which is disrupted when the server’s NetBIOS name resolves to the incorrect, remote-access IP address.

On servers running Small Business Server 2000, accessing specific web-based administration tools might become impossible. For example, attempts to connect to the http://server_name/myconsole site, a common access point for SBS administration, can result in errors due to the server name resolving to the wrong IP address. This prevents the local network computer from establishing a successful web connection to the administration interface.

The system event logs on the RRAS server may also provide clues about the underlying issue. A specific event related to NetBIOS (Netbt) with Event ID 4319 is frequently observed. This event signifies that a duplicate name has been detected on the TCP network, indicating a conflict. The event data often contains the IP address of the machine sending the conflicting message, which in this scenario, is typically the PPP adapter’s IP address being announced or registered incorrectly.

Accessing shared resources on the server becomes problematic, leading to error messages when trying to open file shares or map network drives to the RRAS server. These common network operations depend on successful name resolution to locate the server by its name. When the name resolves to the unreachable remote access IP, these connection attempts will consistently fail.

Furthermore, if the RRAS server is also configured as a domain controller, the impact is more severe. Users attempting to sign into the network from client computers may receive error messages because the client cannot locate a domain controller to authenticate against. This happens because the client’s attempt to find a logon server using the domain name resolves to the problematic IP address.

In domain controller scenarios, errors also occur when trying to access file shares or map network drives to any shared resource within the domain, not just on the server itself. Client computers, such as those running Microsoft Windows 2000 Professional or Microsoft Windows XP Professional, may receive error messages like “No Logon Servers Available to Service your Logon Request,” highlighting the critical dependency on correct name resolution for domain services.

Root Cause Analysis¶

The fundamental reason behind these persistent name resolution and connectivity problems lies in the interaction between the RRAS service and the DNS/WINS services running on the same server. When a remote computer connects to the RRAS server via dial-up or VPN, the server dynamically creates a Point-to-Point Protocol (PPP) adapter. This adapter is essential for facilitating communication with the newly connected remote client, and it is assigned an IP address from the server’s configured pool or DHCP.

The core of the problem is that the server, hosting both RRAS and DNS or WINS services, may incorrectly register the IP address of this newly created PPP adapter within its DNS or WINS database. The registration process is often automatic, intending to make the server’s name resolvable on the network. However, registering the remote access adapter’s IP address is detrimental to clients on the local area network.

When a local computer attempts to access the server by its name (NetBIOS name or FQDN), it queries the DNS or WINS server, which in this case is the same machine experiencing the issue. Because the PPP adapter’s IP address has been registered, the DNS or WINS server might return this specific IP address as the resolution for the server’s name.

Consequently, the local client computer then attempts to establish a connection to the server using this incorrect IP address—the IP assigned to the PPP adapter. From the perspective of the local network, the PPP adapter’s IP address is typically unreachable or exists on a different logical segment not directly accessible without routing that isn’t typically configured for standard client-to-server LAN communication. Since the local computer cannot establish a network connection to the PPP adapter’s IP address, all subsequent attempts to access resources (file shares, administrative consoles, domain services) or communicate with the server using that resolved name fail.

Comprehensive Resolution Steps¶

The primary objective in resolving this issue is to prevent the Routing and Remote Access server from registering the IP address assigned to its PPP adapter within the DNS or WINS database. By ensuring that only the IP address(es) associated with the server’s local network adapter(s) are registered and discoverable by local clients, name resolution will correctly direct traffic to the reachable interface. The steps to achieve this depend on whether the server is running DNS, WINS, or both.

Preventing DNS Registration¶

If the Routing and Remote Access server is also hosting the DNS service, specific configurations are required to control which IP addresses are published. These steps ensure that DNS queries from local clients return the server’s local network IP address rather than the PPP adapter’s IP. You should follow the procedures in this section only if DNS is installed and running on the server experiencing the connectivity problems.

Configuring DNS and Netlogon Registry Settings¶

Modifying the system registry is a key part of controlling DNS registration behavior. Two specific registry values, one for the DNS service and one for the Netlogon service, need to be added or modified.

1. Open the Registry Editor:

   • Select Start, then select Run.
   • Type regedit in the Run dialog box.
   • Select OK. This will launch the Registry Editor application.

2. Locate and configure the PublishAddresses value for the DNS service:

   • Navigate to the following registry subkey:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
   • On the Edit menu, point to New.
   • Select String Value.
   • Enter the following name for the new value: PublishAddresses
   • Double-click the newly created PublishAddresses value to edit its data.
   • In the Value data field, type the IP address of the server’s local network adapter. If the server has multiple local network adapters and you need to publish more than one IP address, separate the addresses with spaces. This value explicitly tells the DNS service which IP addresses are valid for publication, overriding the default behavior which might include the PPP adapter IP.

3. Locate and configure the RegisterDnsARecords value for the Netlogon service:

   • Navigate to the following registry subkey:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
   • On the Edit menu, point to New.
   • Select DWORD Value.
   • Enter the following name for the new value: RegisterDnsARecords
   • Double-click the newly created RegisterDnsARecords value to edit its data.
   • In the Value data field, type 0. This value (0) instructs the Netlogon service not to automatically register A records (host records mapping names to IP addresses) in DNS. This is particularly important on domain controllers where Netlogon is responsible for registering service location (SRV) records and host (A) records necessary for domain functions. By disabling automatic A record registration here, we prevent Netlogon from potentially registering the PPP adapter IP, while relying on the PublishAddresses value for the correct host A records managed by the DNS service itself.

4. Close Registry Editor.

5. Restart the DNS and Netlogon services:

   • Select Start, point to Programs or All Programs, point to Administrative Tools, and then select Services.
   • In the Services console, locate DNS Server. Right-click it and select Restart.
   • In the Services console, locate Netlogon. Right-click it and select Restart.
     Restarting these services is necessary for the registry changes to take effect and for the services to update their registration behavior.

Manually Adding A Records in DNS (Domain Controllers Only)¶

The previous step involving RegisterDnsARecords=0 prevents Netlogon from automatically registering host (A) records. While this stops the registration of the problematic PPP adapter IP, on domain controllers, Netlogon is crucial for registering various DNS records needed for domain functionality, including A records for the domain controller itself. Therefore, if the server is a domain controller, you must manually create the necessary A records in DNS to ensure that the server’s name resolves correctly to its local network IP address.

1. Open the DNS Management console:

   • Select Start, point to Programs or All Programs, point to Administrative Tools, and then select DNS.

2. Navigate to the Forward Lookup Zone for your domain:

   • In the DNS console tree, expand the server object (your server’s name).
   • Expand the Forward Lookup Zones folder.
   • Select the folder corresponding to your local domain name (e.g., mydomain.local).

3. Manually create the primary A record for the domain controller:

   • On the Action menu, select New Host (A or AAAA)….
   • In the IP address text box, type the IP address of the server’s local network adapter.
   • Leave the Name box empty. When left empty in the domain zone, this creates an A record for the domain name itself (often represented as “(same as parent folder)”).
   • Ensure the Create associated PTR record check box is selected. This is good practice for reverse DNS resolution.
   • Select Add Host.
   • You will likely receive a message stating “(same as parent folder) is not a valid host name. Are you sure you want to add this record?”. This is expected; select Yes to confirm. This manually creates the A record mapping your domain name to the server’s local IP.

4. Check if the server is a Global Catalog server:

   • Open Active Directory Sites and Services: Select Start, point to Programs or All Programs, point to Administrative Tools, and then select Active Directory Sites and Services.
   • In the console tree, expand the Sites folder.
   • Expand the site containing your server.
   • Expand the server object (your server’s name).
   • Right-click NTDS Settings and select Properties.
   • On the General tab, look for the Global Catalog check box. If it is checked, the server is a global catalog server and you must continue to the next step. If it is unchecked, you are done with the manual DNS steps for this server.

5. If the server is a Global Catalog server, manually create the GC-specific A record:

   • Return to the DNS console.
   • Under the Forward Lookup Zones folder for your domain, expand the domain folder, expand the _msdcs folder, and then select the gc folder. This folder contains records specifically for global catalog servers in your domain.
   • On the Action menu, select New Host (A or AAAA)….
   • In the IP address box, type the IP address of the server’s local network adapter.
   • Leave the Name box empty. This creates an A record for the gc sub-domain name (also represented as “(same as parent folder)” within this context).
   • Ensure the Create associated PTR record check box is selected.
   • Select Add Host.
   • When you receive the “(same as parent folder) is not a valid host name. Are you sure you want to add this record?” message, select Yes. This manually creates the necessary A record linking the global catalog name for your domain to the server’s correct local IP.

Following these steps ensures that even with automatic Netlogon A record registration disabled, the essential DNS records for the domain controller and global catalog (if applicable) point to the reachable local network IP address, allowing clients to locate domain services correctly.

Preventing WINS Registration¶

If the Routing and Remote Access server is also running the WINS service, you need to prevent the PPP adapter’s IP address from being registered in the WINS database. This is crucial for NetBIOS name resolution, which is still used by many applications and for browsing the local network (like in Network Neighborhood). These steps apply if WINS is installed and running on the server, unless the server is running Small Business Server 2000 SP1, Small Business Server 2000 SP1a, or Windows Small Business Server 2003. These specific versions of Windows Server are pre-configured by default to prevent the registration of the PPP adapter’s IP address in the WINS database, mitigating this particular aspect of the problem out-of-the-box.

Disabling NetBIOS over TCP/IP for Remote Access¶

One method to prevent the PPP adapter’s IP registration in WINS is to disable the NetBIOS over TCP/IP (NetBT) protocol specifically for remote access connections. This is achieved by adding a specific registry value.

1. Open the Registry Editor:

   • Select Start, then select Run.
   • Type regedit in the Run dialog box.
   • Select OK.

2. Locate and configure the DisableNetbiosOverTcpip value for the Remote Access service:

   • Navigate to the following registry subkey:
     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\IP
   • On the Edit menu, point to New.
   • Select DWORD Value.
   • Enter the following name for the new value: DisableNetbiosOverTcpip
   • Double-click the newly created DisableNetbiosOverTcpip value to edit its data.
   • In the Value data field, type 1. Setting this value to 1 disables the NetBT protocol for all remote access connections handled by this server.

3. Close Registry Editor.

4. Restart the Routing and Remote Access service:

   • Select Start, point to Programs or All Programs, point to Administrative Tools, and then select Services.
   • In the Services console, locate Routing and Remote Access. Right-click it and select Restart.
     The Routing and Remote Access service must be restarted for this setting to be applied to new and existing remote connections.

Important Considerations:

• Disabling NetBIOS over TCP/IP for remote access connections will prevent remote access clients from browsing the local network using NetBIOS methods (e.g., through My Network Places or Network Neighborhood). They may still be able to access resources if they know the server/resource name and IP address and can resolve them via DNS (if configured) or if the application uses direct IP connections.
• Adding this registry value might cause remote access connections to fail for computers running older operating systems that rely more heavily on NetBIOS for connectivity, such as Microsoft Windows 98 or Microsoft Windows NT 4.0 Workstation computers.
• For this DisableNetbiosOverTcpip registry value to function correctly on Windows 2000 Server, the server must be updated to Service Pack 3 (SP3) or a later version (like SP4). If you are running an earlier version of Windows 2000 Server (SP2 or earlier) and do not apply the necessary service pack, the Routing and Remote Access service will not recognize or utilize this registry value, and the issue will not be resolved.

Clearing the WINS Database¶

After preventing future problematic registrations by disabling NetBIOS for remote access connections, it’s important to clear any existing incorrect entries (specifically, the PPP adapter’s IP address registered under the server’s name) from the WINS database.

1. Open the WINS Management console:

   • Select Start, point to Programs or All Programs, point to Administrative Tools, and then select WINS.

2. Navigate to Active Registrations:

   • In the W WINS console tree, expand the server object (your server’s name).
   • Right-click Active Registrations.
   • Select Delete Owner….

3. Delete the problematic owner entries:

   • In the Delete Owner dialog box, select the IP address of the server’s PPP adapter. This is the incorrect IP address you want to remove.
   • Determine the scope of the deletion:
     • If your WINS server does not have any replication partners (it’s a standalone WINS server), select Delete from this server only.
     • If your WINS server has one or more replication partners, select Replicate deletion to other servers (tombstone). This marks the entry for deletion and replicates this request to all replication partners, ensuring the incorrect entry is removed throughout the WINS environment.
   • Select OK.

The WINS server will gradually rebuild its database as computers on the network register their NetBIOS names. To expedite this process and force Windows-based computers on the network to register their NetBIOS names immediately, you can open a command prompt (cmd.exe) on those computers and run the command nbtstat -RR. This command purges the local NetBIOS name cache and then rereads the names.

Here is a summary table for the registry modifications required:

Service	Registry Subkey	Value Name	Type	Data	Purpose
DNS	HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters	PublishAddresses	REG_SZ	Local NIC IP(s)	Explicitly list IPs the DNS service should publish (space-separated).
Netlogon	HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters	RegisterDnsARecords	REG_DWORD	0 (Zero)	Prevent Netlogon from automatically registering A records.
RRAS	HKLM\System\CurrentControlSet\Services\RemoteAccess\Parameters\IP	DisableNetbiosOverTcpip	REG_DWORD	1 (One)	Disable NetBIOS over TCP/IP for remote access connections.

Note: The RegisterDnsARecords setting is primarily relevant for domain controllers. The DisableNetbiosOverTcpip setting is primarily relevant for preventing WINS registration of the PPP adapter IP.

Alternative Workaround¶

As an alternative approach to directly modifying DNS and WINS registration behavior, you can configure the Routing and Remote Access service to assign IP addresses to remote access clients from a static pool. The key to this workaround is ensuring that this static pool of IP addresses resides on a different IP subnet than the local network segment where your client computers and the server’s primary network adapter reside.

The benefit of this configuration is that even if the RRAS server were to register the PPP adapter’s IP address (which would be from the static pool on the different subnet) in DNS or WINS, local network clients would still not typically attempt to connect to it. When a local client tries to reach the server by name, and DNS/WINS returns an IP address from the remote access subnet, the client recognizes that the IP is not on its local subnet. Standard network behavior dictates that the client would then attempt to route the connection request. However, the intended destination for local communication is the server’s local network IP address, which should still be correctly configured and accessible. Clients will continue to use the server’s proper local IP for communication within the LAN, either through cached entries or by resolving the name correctly if the manual DNS/WINS configurations for the local IP are also in place. This workaround effectively isolates the problematic registration by placing the remote access IPs onto a segment that local clients do not consider their direct connection path to the server name.

Implementing this involves accessing the RRAS configuration, typically by right-clicking the server in the Routing and Remote Access console, selecting Properties, navigating to the IP tab, and configuring it to use a static address pool instead of DHCP. You would then define a range of IP addresses for this static pool, ensuring that the network portion of these IP addresses (defined by the subnet mask) is distinct from the network portion of the IP addresses used on your local LAN segment.

Please share your experiences with these issues and the solutions you have implemented in your environment.