Check if you are getting any loss of functionality when you get this alert e.g., loss of QOS etc. How soon does this alert clear? It could be that the server hosting the probe is busy at that time. If there is no loss of functionality you could block this alert using nas pre-processing rule.

That said, exchange_monitor uses four other probes to monitor Exchange:

-perfmon-ntservices-ntevl-processes

1) The first thing to check is that the most current probes are deployed and running.

2) Is this a one-time alarm or is it happening frequently?

3) If the alarm is occurring frequently, then we'll need to see level 3 exchange_monitor logs (when the services check fails), as well as the exchange_monitor config file to go deeper into the issue.

***The above comments aside, if similar communication issues are happening with other probes on a few robots then you should check for potential communication issues/network connectivity.***

Try doing a telnet FROM the hub TO the robot on port 48000 and telnet FROM the robot TO the hub on port 48002. If telnet-ing from the robot to the hub fails try a tracert TO the hub from the robot and see if its successful/slow etc.

You can also check the transfer rate in the Hub probe GUI under the Hubs Tab, via rt-click. There is no 'magic number' but you should have at least a 200 KB/sec transfer rate or higher for the hub in question.

You might try setting the hostname and IP explicitly in the robot(s) config via the GUI if you can open it or via Raw Configure or in the robot.cfg file itself if you have access and then restart the robot and see if it behaves better afterwards.

In some cases this error can be caused by Anti-Virus/network filtering interfering with the communication. If that is the case, configure an exception for All Nimsoft Programs/Nimsoft directory.