Communications failures between the enterprise console and your CCM Agents are going to fall into two categories:
If the communications link was working fine and then suddenly it has failed or is not working, chances are you have a problem with your network – Usually this will be either an equipment failure or someone has introduced a firewall rule blocking the ports, so you should check this first.
If you are setting up a new communications link and it just doesn’t work, then the first place to look is for a misconfiguration within the Halcyon software, then look to the network.
You should work through each step in this “how to…” in order from the start, to methodically check each item is working correctly.
You should work through the following steps in order and double-check them.
It is important that the device type specifies the correct OS type and that the Hostname or address is correct.
If you have configured hostnames (which is the preferred method) you will be using DNS. You need to ensure that DNS is resolving correctly. This is important especially if your Enterprise Console and CCM agent are resident in different domains.
Open a command prompt on the Enterprise Console and issue the command;
The name server should return the IP address of the CCM agent. This IP address MUST match the Device Manager entry.
Perform a reverse lookup to ensure the IP address resolves back to the hostname.
Perform the same operation on the CCM agent using the appropriate OS commands.
If Hostnames and IP addresses fail to resolve correctly you should speak to your DNS administrator and get the DNS entries corrected, then re-try the procedure above.
Alternatively, a quick way to bypass DNS temporarily would be to ensure there are suitable hostname entries in the host tables for the Enterprise Console and CCM agent.
Remember to add both the short hostname and the fully qualified domain name to your entries. E.g;
10.72.73.59 HAL720P9 HAL720P9.HALCYON.LOCAL
If you do this, then check the host name search priority is set to local entries first.
Changing this may affect applications on your CCM agent server, so proceed with caution.
NB: “ping” may not be permitted on your network.
Check that you can ping the CCM agent server from the Enterprise Console using the hostname. Open a command prompt and issue the command;
ping hostname -n 5
If this fails with “ping request could not find host” then the name is not resolving correctly either from DNS or from the host file. You should re-check those.
Then try using the IP address;
ping IP-ADDRESS -n 5
If either method fails with “Destination host unreachable” then the Enterprise Console cannot reach the target host or IP address. You should consult with your network team to resolve this.
Check that you can ping the Enterprise Console from the CCM agent server.
Perform the previous steps from the Agent Server to the Enterprise Console.
Once we have established that there is a route between the Enterprise Console and the IBMi, using ping, we now need to check to see if traffic is allowed through on the correctly configured port.
The Enterprise Console ALWAYS uses TCP port 15000. This cannot be changed at present.
CCM Agent servers always use port 15000.
If you cannot get two-way communications working it is most likely that the port is blocked at your firewall. This is what occurs in 99% of cases.
The firewall could be the Windows firewall on the Enterprise Console. It could be your domain firewall and if you are an MSP, and the CCM agent is located at a customer site, it could be the firewall at the customer end, so please check with your network teams first.
Remember the ports need to be open for traffic in BOTH directions (inbound and outbound).
The software is very simple – it can either connect or it can’t. If it cannot connect then the problem is very likely going to be a firewall blocking the traffic.
If you are convinced that the ports are open, you can use the following methods to diagnose the fault.
Starting from windows 7, the telnet client is a feature that must be installed, so it is not always available. However, within Powershell 4.0 and above you can use the test-netconnection command.
Check the powershell version by starting powershell.
Press the Windows key and type “powershell” <Enter>
test-netconnection hostname -port 15000
Here’s an example of a positive and a negative result…
If this comes back as negative – often a network team will say “your software is broken” – you can prove it is not by using this command on the Enterprise Server, connecting to the localhost, port 15000.
You can also list the active listening connections searching for port 15000, then check the task list.
The number returned on the right-hand column is the process ID (PID) of the process bound to that port.
Then use the tasklist command to search for that PID – which should be NMService.exe (The Halcyon Network Manager Service)
netstat -ano | findstr “PID 15000”
tasklist | findtsr PID
This will prove that the Halcyon software is running and listening on port 15000.
Use the Telnet command to connect to the Enterprise Console Server on port 15000.
NB: The Telnet protocol may be blocked on your firewall.
The following example is from a system operating AIX, you can do the same from Windows or Linux (Providing the telnet application is installed)
If telnet is not installed on Windows, you can use the test-netconnection command in PowerShell as detailed on the previous page.
If the port is open and the Halcyon Network Manager Service is running, you will see the message “Connected to” appear. At this point you can use CTRL-Z to terminate the connection
If there is no message, and after a period it will timeout, then the telnet to port 15000 has not worked.
Still have questions? We can help. Submit a case to Technical Support.