Hi! This was fixed, will be available in next 3.9 patch release.

The "fix" was to write a small NXSL script to delete these nodes at which point they were rediscovered and added properly.

Apologies. I've been calling the constructor incorrectly. For anyone else who come's across this issue to call constructor you have to use new. Like below body = new JsonObject();

reporting package named netxms-reporting should be available in the repos

Thanks for your reply. Now I understand the different approaches. If you prepend the file path with * the "Event ID" becomes a field that is writable. Missed that before. It seems like you can do more flexible things with the traditional Log Parser. I use the current 3.9.156, but 3.8.something before didn't have the parameters set as well. Maybe if I use the Log Parser instead of the Windows Event Parser? Edit: Yes, indeed. It works if I use the Log Parser out of the Policies. But I guess that's better anyway.

Hi, I just had a similar version mismatch problem on debian with tomcat. There is a work folder in your tomcat/work/Catalina/localhost/ with a nxmc folder that I deleted. Then rename .war to nxmc.war to have the url as  :8080/nxmc/  Do all of this with tomcat stopped ! Resolved the issue I caused by deploying different version with the same name causing the mess in in the work folder. Regards Dawid

Figured out what was happening!  One node (working) was discovered with SNMP v2c and the other node (not working) v1.  Changed it to v2c and immediately they all worked!

Yes, export-import of configuration could be a simpler way. You can not export DCI configuration of a single node, so you have to move DCIs from a node to a template. "Copy to other node(s)" in DCI context menu does the movement to a template. You need to create an empty template first. Then in Tools->Export configuration you can export your templates. On the new system you can keep the DCIs in templates and just apply the templates to the nodes you need (it's usually more practical way to have all DCIs in templates). Or you can move the DCIs from template to node(s).

Hi, thx for the reply. Sorry if i am in late answering you. I will try and le tyou know. Thanks

Actually, I just figured it out. Thank you for your help!

The issue was that VPN tunnel between agent and server was NAT-ed and the packets from server was marked as peckets from router IP (not server IP)

Hi! I hope we will be able to make it part of 4.0 release (likely in autumn). It's not a firm commitment though and will be dependent on time and resource availability. Best regards, Victor

Have attached a template I use on the Netonix WS-12-250-AC/DC and WS-24-400A models. Probably has some stuff you're not interested in, but may be of help. Netonix example template.xml

it is working now it was wrong IP address it is not local machine but another one thank you for help

2.2.15 is an extremely old version. I highly recommend upgrading to current 3.8, there are very good chance that this issue is long fixed. Best regards, Victor

Hi, NXSL function "replace" was added only in 3.9 branch, which is not released yet. As for original geolocation issue - geolocation object constructor expects two floating point numbers as latitude and longitude. You have to manually convert d m' s" format into degrees. Best regards, Victor

Hi, could you please show data source configuration for dashboard elements? Also, could it be that you have access restrictions on DCI level? Best regards, Victor

Hello Victor, testet the Agent V3.8.425... and it worked like a charm...  Many thanks for the fast fix... Greetings Marco

The processing has several steps: trap arrives event generated event processed by EPP and some actions are executed. It's important to understand on what stage the delay are. Can you check timestamps in snmp trap log, event log and alarm log to see where it's delaying? Also, there's a built-in template for netxms server performance monitoring. If you upgraded from previous versions, that template does not get upgraded automatically (you need to change ImportConfigurationOnStartup server configuration parameter and restart the server, or you can take /share/netxms/templates/netxms_server.xml file from the file system of the server and import it using web/desktop client.

Let's try to exclude the option that transformation scripts get randomly delayed. Try wrapping transformation scripts in something like trace(0, $object->id . ":" . $dci->id . " tranformation script start"); ... trace(0, $object->id . ":" . $dci->id . " tranformation script end"); first parameter of trace() defines the log level. This way you should get some stats on the actual duration of the transformation scripts.