If clients successfully connect to clustered resources only when a specific node is the owner, a few possible problems could lead to this condition. Check the system event log on each server for possible errors. Check to make sure that the group has at least one IP address resource and one network name resource, and that clients use one of these to access the resource or resources within the group. If clients connect with any other network name or IP address, they may not be accessing the correct server in the event that ownership of the resources changes. As a result of improper addressing, access to these resources may appear limited to a particular node.
If you are able to confirm that clients use proper addressing for the resource or resources, check the IP address and network name resources to see that they are online. Check network connectivity with the server that owns the resources. For example, try some of the following techniques:
PING server's primary adapter IP address (on client network)
PING other server's primary adapter IP address (on client network)
PING IP address of the group
PING Network Name of the group
PING Router/Gateway between client and server (if any)
PING Client IP address
If the above tests work correctly up to the router/gateway check, the problem may be elsewhere on the network because you have connectivity with the other server and local addresses. If tests complete up to the client IP address test, there may be a client configuration or routing problem.
PING Client IP address
PING Router/Gateway between client and server (if any)
PING server's primary adapter IP address (on client network)
PING other server's primary adapter IP address (on client network)
PING IP address of the group
PING Network Name of the group
If the tests from the server all pass, but you experience failures performing tests from the client, there may be client configuration problems. If all tests complete except the test using the network name of the group, there may be a name resolution problem. This may be related to client configuration, or it may be a problem with the client's designated WINS server. These problems may require network administrator intervention.
If clients lose connectivity with both cluster nodes, check to make sure that the Cluster Service is running on each node. Check the system event log for possible errors. Check network connectivity between cluster nodes, and with other network devices, by using the procedure in the previous section. If the Cluster Service is running, and there are no apparent connectivity problems between the two servers, there is likely a network or client configuration problem that does not directly involve the cluster. Check to make sure the client uses the TCP/IP protocol and has a valid IP address on the network. Also, make sure that the client is using the correct network name or IP address to access the cluster.
If clients experience problems accessing cluster file shares, first check the resource and make sure it is online, and that any dependent resources (disks, network names, and so on) are online. Check the system event log for possible errors. Next, check network connectivity between the client and the server that owns the resource. If the data for the share is on a shared drive (using a physical disk resource), make sure that the file share resource has a dependency declared for the physical disk resource. You can reset the file share by toggling the file share resource offline and back online again. Cluster file shares behave essentially the same as standard file shares. So, make sure that clients have appropriate access at both the file system level and the share level. Also, make sure that the server has the proper number of client access licenses loaded for the clients connecting, in the event that the client cannot connect because of insufficient available connections.
If you create a new IP address resource or change the IP address of an existing resource, it is possible that clients may experience some delay if you use WINS for name resolution on the network. This problem may occur because of delays in replication between WINS servers on the network. Such delays cannot be controlled by MSCS, and must be allowed sufficient time to replicate. If you suspect there is a WINS-database problem, consult your network administrator, or contact Microsoft Product Support Services for TCP/IP support.
Network adapter configuration is one possible cause of intermittent access to the cluster, and of premature failover. Some autosense settings for network speed can spontaneously redetect network speed. During the detection, network traffic through the adapter may be compromised. For best results, set the network speed manually to avoid the recalibration. Also, make sure to use the correct network adapter drivers. Some adapters may require special drivers, although they may be detected as a similar device.