Web Console Connection Refused on one server

We have an application cluster setup. When I am on Server#1, I get the connection refused error. If I failover to Server#2, everything connects properly. The Tools|Options settings are identical. Any suggestions on what may be the difference?

Thanks.

Jason

Hi,

Does the cluster share the same IP address for both nodes? If not, do you connect to the correct IP address?

Do you run the web server hosting web console code on the same system, I mean is that part of the cluster? If yes, does it connect to the cluster IP or local IP address?

Any chance of a firewall blocking connections on Server1?

The web console is on a separate server outside of the cluster. The cluster share the same IP and we are referring to it by name not IP on the logon form. We verified there are no firewall rules blocking activity.

This sounds like the cluster is not configured to failover that connectivity port

Isn't the port controlled by the 24x7 service? When I run the netstat I see the port listening on Server#2. If I failover to Server#1, the port is not listening here. The service is up and running and defined in the options to use this port on this server.

Port is not listening?

You said previously that all Tools/Options settings are the same and I assumed that I don't need to bother to verify that the other scheduler is configured to listen for network connections too.

Please ensure that Tools/Options -> Network settings are the same in both scheduler nodes and that the "server" mode is enabled in both places.

Both have the "distributed server" enabled.

The next step is to verify the scheduler is actually listening

1. Please check there are no errors like "cannot start listener, port is in use" or similar reported in scheduler.log
2. Run netstat –a -b command on each node and check that port 1096 is actually active and it is 24x7.exe process that is listening on that port and not some other application.

If there are no errors, and netstat indicates that port 1096 is active, then the problem is in the cluster config. Otherwise the error should indicate the cause of the problem.