Thank you very much.

Thanks, issue registered: https://github.com/netxms/netxms/issues/3428

Alex, Thanks or the update and I appreciate the work around. It worked great !!

If it was upgraded and the version is still stuck, the servlet container is most likely serving the old version from its work directory. In that case:     Stop the container (the NetXMS WebUI service, if installed with the Windows installer)     Delete the contents of the work directory — C:\NetXMS-WebUI\jetty-base\work with the installer's default prefix; the location may differ for other containers or a custom setup     Start the container again After that, do a full page reload in the browser.

Thanks for the detailed report. The missing zone record is not what's breaking discovery. Object ID 4 is a built-in object: the server creates the Default zone in memory at every startup, and the code paths that use it (including active discovery) handle it correctly whether or not a row exists in zones / object_properties - the row only gets written once the zone is actually modified, e.g. when the first subnet is placed into it. So on a freshly initialized database the tables being empty is expected, and this is not specific to SQLite or to Windows. The error message in the log is misleading, though, and the zone should be persisted at first startup instead of being re-created every time. I've opened https://github.com/netxms/netxms/issues/3410 for that. For the discovery problem, which is a separate issue, please check the following: Discovery type. In Server Configuration, check NetworkDiscovery.Type. If it is 0 (disabled), the "Scan" action will enqueue addresses but nothing will pick them up. For active scanning of configured ranges it must be 2 (active) or 3 (active and passive). Enable discovery debug output. Either start the server with a higher debug level, or set it at runtime without a restart:     nxadm -c "debug tag poll.discovery 6" Then run the scan again and watch netxmsd.log. At level 6 you will see, per address, whether the host responded to the probe and - if it did - whether the potential node was rejected and why ("IP address already known at node ...", "rejected by discovery filter", etc.). Reset it afterwards with nxadm -c "debug tag poll.discovery off". Probing method. By default active discovery only uses ICMP ping. If the target hosts do not answer ICMP, nothing will be found. Check NetworkDiscovery.ActiveDiscovery.EnableSNMPProbing and NetworkDiscovery.ActiveDiscovery.EnableTCPProbing, and make sure ICMP is not blocked between the server and the scanned range. Discovery filter. If a filter script is configured, a responding host can still be dropped. The level 6 log above shows this explicitly. Address ranges. Verify that the ranges under Network Discovery -> Active Discovery Targets are the ones you expect, and that they are IPv4 - IPv6 ranges are skipped by active discovery. If you post the poll.discovery log from a scan run, I can tell you where it stops.

Thanks for the suggestion — I've opened an issue for it: https://github.com/netxms/netxms/issues/3409 At the moment all backup-related read operations (list of backups, latest backup, individual backup by ID) are gated only by "Read" access on the node, so anyone who can see the node can also pull the full device configuration with whatever it contains. Splitting that into a separate right for the backup list and another for viewing/exporting the actual content makes sense to me. There are a few things to settle first — mainly what the default should be for existing installations, and the fact that the object access rights mask is nearly out of free bits — so I'll discuss it with the team before we implement anything. Feel free to add your thoughts to the issue.

It seems that SNMP has some problems on the PDU when it receives requests for OIDs that are not fully implemented. I changed the snmp-Testoid to 1.3.6.1.4.1.19536.10.1 using the Custom Attribute "snmp.testoid". Capabilities detection and DCIs for temperature using SNMPv2 and SNMPv3 include alarm generation now work as expected. Now implementing DCIs for current amps and volts and alarming for this.

That's more or less expected with the current caching: the client caches tiles under .nxmc4 and doesn't invalidate them when the tile server changes, so you can get stale/missing tiles from the previous server — which is why clearing the cache fixed it for you. I've filed a ticket to key the cache by tile server URL so switching servers invalidates automatically and you won't need to clear it by hand. Thanks for tracking it down.

Ticket: https://github.com/netxms/netxms/issues/3398

Thanks very much!

Hi, Thanks, my bad. Fixed now.

Hi Alex, thanks for the hint. I give it a try... Greetings Marco

nxdbmgr actually do this migration for all images - but stock images (there are 9) are deleted by the upgrade process before the actual migration. Current build of both debs and rpms have workaround for that, and it's completely fixed in upcoming 6.2.1.

Hi, The problem is the servlet container version, not Java. The NetXMS 6.2 web client (nxmc-6.2.0.war) is built against the Jakarta Servlet API (jakarta.servlet.* namespace) and requires a container that supports it. You are running Tomcat 9.0.58, which still uses the older javax.servlet.* namespace. Because of that, Tomcat 9 cannot load the application's context listeners, which is exactly the "One or more listeners failed to start" / "Context startup failed" error you see. The ClassCastException about ObjectStreamClass$Caches is a harmless secondary warning. It comes from Tomcat's cleanup routine running on a newer JDK while it tears down the already-failed context - it is not the cause. That is also why switching from JDK 17 to 21 made no difference; the JDK was never the issue. To fix it, deploy the WAR on a container that supports the Jakarta Servlet API: Tomcat 10.1 or later - on Ubuntu use the tomcat10 package, webapps directory /var/lib/tomcat10/webapps. Jetty 11 or later is also fine (Jetty 11/12 support the Jakarta Servlet API). Java 17 or 21 works with either. Do not run it under Tomcat 9 - the javax vs jakarta namespace difference cannot be bridged by a config change or a different JDK.

For XML error - I don't see it in current development version log, so changes are that it's already fixed, pls double-check when v.6.2 is out. For MIB error - I guess MIB compiler is failing on some specific MIB file. You can try removing some of your MIB files until you find which one is causing the issue (you can remove half of them, recomplie, then another half, etc...). Or you can just share your whole MIB file collection.

Make sure that IP address in node's Properties -> Communications is correct. Then run Configuration Poll on that node. If it's still not working, try enabling debug, from Tools -> Server Console: debug syslog 6 and check server log lines when your device sends something.

This is logical flaw in exclusion processing. I've registered an issue: https://github.com/netxms/netxms/issues/3349 Will be fixed as part of 6.2.0 release. Best regards, Victor

Just added physical interface marking in FortiSwitch driver.

Thank you!

Thanks a lot for your help. I'll give it a try.