This is fixed, fix will be part of release 5.1. Best regards, Victor

Just fixed the issue, fix will be included into release 5.1.0. Best regards, Victor

Please provide more details

Task handler Agent.DeployPackage expects parameter string as set of key=value entries separated by semicolons. Currently only one key is supported - "package". So if you have package with ID 123 then setting task parameter to package=123 should do the trick. Best regards, Victor

Thanks!

@victor said in Expected number of connections: This is firewall design problem in my opinion, as this is perfectly normal traffic pattern. Sure, understood. Because firewall keeps connection state table entry hanging around for 60s this exacerbates the apparent "issue".

Just fixed it. Official fix will be in 5.1, but if you need it to work in 5.0, you can rebuild web API from source branch stable-5.0 - fix is backported here as well. Best regards, Victor

Just added new handler type Agent.ExecuteCommand - it will be available in version 5.1. Best regards, Victor

You can do type conversion this way: b = Math::Floor(12.34); b = int32(a); println(typeof(b), b); b = int64(a); println(typeof(b), b); b = uint32(a); println(typeof(b), b); b = uint64(a); println(typeof(b), b); b = real(a); println(typeof(b), b); b = boolean(a); println(typeof(b), b);

Fixed

Coming back to this issue, would you have any more feedback for us, please? Did you try disabling DHCP? We had a look at our test setup and found similar pattern of events as you posted on 11.09.24. We checked remote node in question and could see server reboot and link fluctuations, so the events were reflecting server NOK status. We dont see any pattern that would indicate any generic issues with the product. Please also try to check remote node messages file for timeframe in question.

Sure, welcome. Thank you for your feedback.

Hi, we have checked .jar client on Ubuntu and Redhat and those seem to match maps text colour in the standard client for Windows; all those are black. Could you please let us know what flavor Linux you are using and which client version? Does Restore Defaults button help at all?

Hi, thank you for your feedback https://track.radensolutions.com/issue/NX-2600 has been created for this.

Hi, here would be example from documentation and the script needs to be executed on the node where agent with "EnableWebServiceProxy=yes" is running. webSvc = $node.getWebService("web_service_definition_name"); result = webSvc.get(); println(result.httpResponseCode); println(result.document); If this agent is on your NetXMS server node, you can use GetServerNode() instead of $node, this way you can run this script in context on any node.

Great, thanks for the update

Hi Auguste Just further on my colleagues feedback above - those " call to curl_easy_perform failed (28: Operation timed" error messages seem to be pretty notorious for resolving and there are several steps suggested, very much trial and error approach. Is there a firewall of any kind between netxms server and your mail server or on either of node themselves? If yes, please try to disable it and perform a new test. If it still fails then you may wish to set up concurrent tcpdump on server and also on mail server, then perform another test and see with Wireshark if any packets are reaching and where the delay is.

Hi! You can use object queries. Go to Tools -> Find Object, and use the following query (I assume you are using NetXMS 5.x): with Device = { node.name }, ExpectedState = { ['UP','DOWN','IGNORE'][expectedState] }, CurrentState = { ['UNKNOWN','UP','DOWN','TESTING','DORMANT','NOT PRESENT'][operState] } type == INTERFACE You will get list of all interfaces with expected state and current state (with some extra default columns). Then you can export resulting table to CSV by selecting "Export all to CSV" from view menu or toolbar (in top right corner). Best regards, Victor

Just fixed it. Fix will be included into next release. Thank you for debugging and providing steps to reproduce! Best regards, Victor

Hi, we have replicated reported issue in our labs and there's a bug in CountEx metric for Windows. A fix will be available in the next release.