Client-to-cluster connectivity problems

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 ! address to access the cluster. Solution: "ake sure that the client is accessing the cluster using the correct network name or ! address. Cause: The client might not have the TC!# ! protocol correctly installed and configured. Solution: "ake sure that the client has the TC!# ! protocol correctly installed and configured. $epending on the application being accessed% the client can address the cluster by specifying either the resource network name or the ! address. n the case of the network name% you can verify proper name resolution by checking the &et'T cache (using the &btstat.e)e utility* to determine whether the name had been previously resolved. Also% confirm proper W &+ configuration% both at the client and through the W &+ Administrator. f the client is accessing the resource through a specific ! address% ping the ! address of the cluster resource and cluster nodes from a command prompt. ,or more information on &btstat.e)e% see &btstat. ,or instructions on how to troubleshoot connectivity problems% see Troubleshoot clientto-virtual server connectivity.

Cause: The client may be attempting to connect to an incorrect node after a failover. Solution: "ake sure that the routers are configured correctly. ,or more information% see article -.//001% 2"AC Address Changes for 3irtual +erver $uring a ,ailover with Clustering2 in the "icrosoft Knowledge 'ase.
Clients cannot access resources.

Cause: 'oth your private network and the primary network are down. Solution: f 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. f 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 4uorum resource. 5ach of the other nodes will stop its Cluster service. Cause: A node might have lost connectivity with the network. Solution: f you suspect a node has lost connectivity with the network6

Confirm that the connection configuration settings are correct for each connection. To do this% open Control Panel% then double-click Network Connections. 7ight-click a connection and click Properties. Check W &+ or $&+ to make sure that they are properly configured. Confirm that the static ! 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: f 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. f 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 : Confirm that you have a physical connection between the cluster nodes.

"ake sure that the network cabling has not failed or been damaged. f the cabling has failed% the Cluster service might have failed over the resources to another node.

5nsure that the storage device cabling has not failed. f the nodes are separated by one or more hubs% check the connectivity through all hubs.

Solution -- step !: 'ring the group back online.

Clients cannot attach to a cluster file share resource.

Cause: W &+ or $&+ might not be correctly configured. Solution: "ake sure that W &+ or $&+ are correctly configured. f you are using W &+% run W &+ "anager on the W &+ server8 then% on the "appings menu% click Show #atabase. "ake sure that each node and the cluster are registered in the W &+ database and that the registrations are active. ,or more information on W &+ and W &+ "anager% see the Networking Guide in the Microsoft Windows Server 2003 Resource Kit. Cause: 9our security policies might not allow the client to access the file share. Solution: "ake 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 :uest account must be enabled for the client to have access.
Clients cannot access a cluster resource.

Cause: 5ither the ! Address resource or &etwork &ame resource for the group in which the resource is contained is not online. Solution: Check the group dependencies8 the resource is supposed to be dependent on either the ! Address or the &etwork &ame resource. 5nsure that the ! Address and &etwork &ame resources are online in the resource group. ,rom the client computer% try to ping the ! addresses of the virtual server and individual nodes. Cause: 5ither the client or the cluster computer is not configured for either W &+ or $&+.

Solution: "ake sure that the cluster nodes are configured properly for name resolution using either W &+ or $&+% 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 $&+ is not correctly configured. Solution: Configure the cluster nodes and client computer to use W &+ or $&+. f you use $&+% add a $&+ address record for the cluster in the $&+ database.
Client can detect all nodes but cannot detect a virtual server.

Cause: The virtual server might not have its own ! Address and &etwork &ame resources. Solution: "ake sure that the virtual server has its own ! Address and &etwork &ame resources% and that both resources are online. 9our servers must have an address and a name on the network for any other server or client to properly recogni;e that the servers are on the network. Cause: <ne or more nodes are not correctly configured to use W &+ or $&+. Solution: "ake sure that all nodes are correctly configured to use W &+ or $&+.
Clients cannot connect to a virtual server and the system event logs on the client computers contain $erberos authentication errors.

Cause: The cluster might have used a previously-created computer ob=ect for the virtual server. When the virtual server>s &etwork &ame resource is brought online for the first time after Kerberos support has been enabled% the cluster changes the ob=ect>s password. Active $irectory then replicates this change to all domain controllers in the cluster. ?owever% 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 @+upport@Tools folder on your operating system installation C$.