Share via

Client-to-cluster connectivity problems

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Client-to-cluster connectivity problems

What problem are you having?

  • Clients cannot connect to virtual servers.

  • Clients cannot access resources.

  • A node cannot communicate on a network.

  • Clients cannot access a group that has failed over.

  • Clients cannot attach to a cluster file share resource.

  • Clients cannot access a cluster resource.

  • Client can detect all nodes but cannot detect a virtual server.

  • Clients cannot connect to a virtual server and the system event logs on the client computers contain Kerberos authentication errors.

Clients cannot connect to virtual servers.

Cause:  The client might not be using the correct network name or IP address to access the cluster.

Solution:  Make sure that the client is accessing the cluster using the correct network name or IP address.

Cause:  The client might not have the TCP/IP protocol correctly installed and configured.

Solution:  Make sure that the client has the TCP/IP protocol correctly installed and configured.

Depending on the application being accessed, the client can address the cluster by specifying either the resource network name or the IP address. In the case of the network name, you can verify proper name resolution by checking the NetBT cache (using the Nbtstat.exe utility) to determine whether the name had been previously resolved. Also, confirm proper WINS configuration, both at the client and through the WINS Administrator.

If the client is accessing the resource through a specific IP address, ping the IP address of the cluster resource and cluster nodes from a command prompt.

For more information on Nbtstat.exe, see Nbtstat.

For instructions on how to troubleshoot connectivity problems, see Troubleshoot client-to-virtual server connectivity.

Cause:  The client may be attempting to connect to an incorrect node after a failover.

Solution:  Make sure that the routers are configured correctly. For more information, see article Q244331, "MAC Address Changes for Virtual Server During a Failover with Clustering" in the Microsoft Knowledge Base.

Clients cannot access resources.

Cause:  Both your private network and the primary network are down.

Solution:  If your server cluster nodes are multihomed and use a private network to communicate, the primary network can be down and the Cluster service can still function normally.

If the private network is lost between nodes, resources that are configured to do so will fail over to the node that has ownership of the quorum resource. Each of the other nodes will stop its Cluster service.

Cause:  A node might have lost connectivity with the network.

Solution:  If you suspect a node has lost connectivity with the network:

  • Confirm that the connection configuration settings are correct for each connection. To do this, open Control Panel, then double-click Network Connections. Right-click a connection and click Properties.

  • Check WINS or DNS to make sure that they are properly configured.

  • Confirm that the static IP addresses being used by the Cluster service are still in place and are not being used by other resources on the network.

A node cannot communicate on a network.

Cause:  If a node cannot communicate on a network, it might lack a physical connection to the other nodes, or the other nodes might not be connected to one another.

If the cabling has failed, the Cluster service might not have received the heartbeat of the node and so failed the resources owned by that node over to other nodes in the cluster. The node can no longer communicate to clients on a network.

Solution:  Check the hub and local cabling, both to the network and to the cluster disks.

Clients cannot access a group that has failed over.

Cause:  There might not be a physical connection between the cluster nodes and the group that failed over has also failed to come online.

Solution -- step 1:  Confirm that you have a physical connection between the cluster nodes.

  • Make sure that the network cabling has not failed or been damaged.

    If the cabling has failed, the Cluster service might have failed over the resources to another node.

  • Ensure that the storage device cabling has not failed.

  • If the nodes are separated by one or more hubs, check the connectivity through all hubs.

Solution -- step 2:  Bring the group back online.

Clients cannot attach to a cluster file share resource.

Cause:  WINS or DNS might not be correctly configured.

Solution:  Make sure that WINS or DNS are correctly configured.

If you are using WINS, run WINS Manager on the WINS server; then, on the Mappings menu, click Show Database. Make sure that each node and the cluster are registered in the WINS database and that the registrations are active.

For more information on WINS and WINS Manager, see the Networking Guide in the Microsoft Windows Server 2003 Resource Kit.

Cause:  Your security policies might not allow the client to access the file share.

Solution:  Make sure that your security policies allow the client to access the file share.

The client must have the right to log on to the file share, or the Guest account must be enabled for the client to have access.

Clients cannot access a cluster resource.

Cause:  Either the IP Address resource or Network Name resource for the group in which the resource is contained is not online.

Solution:  Check the group dependencies; the resource is supposed to be dependent on either the IP Address or the Network Name resource. Ensure that the IP Address and Network Name resources are online in the resource group. From the client computer, try to ping the IP addresses of the virtual server and individual nodes.

Cause:  Either the client or the cluster computer is not configured for either WINS or DNS.

Solution:  Make sure that the cluster nodes are configured properly for name resolution using either WINS or DNS, and make sure that clients are configured to use the same form of name resolution.

Cause:  The client is attempting to access the cluster from a different subnet, and DNS is not correctly configured.

Solution:  Configure the cluster nodes and client computer to use WINS or DNS. If you use DNS, add a DNS address record for the cluster in the DNS database.

Client can detect all nodes but cannot detect a virtual server.

Cause:  The virtual server might not have its own IP Address and Network Name resources.

Solution:  Make sure that the virtual server has its own IP Address and Network Name resources, and that both resources are online.

Your servers must have an address and a name on the network for any other server or client to properly recognize that the servers are on the network.

Cause:  One or more nodes are not correctly configured to use WINS or DNS.

Solution:  Make sure that all nodes are correctly configured to use WINS or DNS.

Clients cannot connect to a virtual server and the system event logs on the client computers contain Kerberos authentication errors.

Cause:  The cluster might have used a previously-created computer object for the virtual server. When the virtual server's Network Name resource is brought online for the first time after Kerberos support has been enabled, the cluster changes the object's password. Active Directory then replicates this change to all domain controllers in the cluster. However, because of replication latencies, clients connecting to this virtual server might receive a Kerberos ticket encrypted with the old password. This can result in Kerberos authentication errors.

Solution:  Wait until the new password has been replicated to all domain controllers, or force replication using the repadmin and replmon command-line tools, available in the \Support\Tools folder on your operating system installation CD.

For information on monitoring and troubleshooting replication issues, see Troubleshooting replication.

For information about how to obtain product support, see Technical support options.