NetXMS Support Forum

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.

The identical value on both switches is expected, not the fault. 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2 is hwMstpiBridgeID, and under V-STP the M-LAG pair presents itself as one logical bridge, so both chassis report the same bridge ID. In your case that ID (AC:5E:14:7F:89:01) is xA's own dot1dBaseBridgeAddress, which you can see in xA's Hardware Inventory tab.

NetXMS reads that OID specifically to handle this - see https://github.com/netxms/netxms/issues/3353, fixed in 6.2.0. Without it, STP discovery invents a link to the M-LAG peer on every downstream port. Which server version are you running? If it is older than 6.2.0, upgrade first and re-run a configuration poll plus a topology poll on both switches.

The peer-link and keepalive links in your screenshots look correct: the six Eth-Trunk0 members (40GE5/0/34-35, 40GE6/0/34-35, 40GE7/0/34-35) and 10GE4/0/47 all resolve to the right peer and match your diagram. Two other things do look wrong, and neither can come from STP discovery:

1. On both switches, MEth0/0/0 and 10GE2/0/1 list the switch itself as peer node, pointing at each other. STP discovery cannot produce a self-link - it skips a bridge that resolves to the local node.

2. 40GE6/0/6-9 on xA linked to 10GE4/0/42-45 on xB. These ports are DOWN/Disabled, and a down port has no forwarding or blocking STP state, so STP would not report them. They are also absent from your diagram.

Could you widen the Interfaces table and show the "Peer discovery protocol" column? It is cut off in both screenshots, and it is the one field that tells me which discovery source created these links (STP, LLDP, CDP, or FDB). Also confirm whether 40GE6/0/6-9 were ever cabled to xB - if they were, these may just be stale cached links.

Hi
After upgrade from version 6.1.4 to 6.2.1 web interface shows incompatible version between server and client (webui). Both have been updated by installers from web. Installation on windows

Do I miss something ?

I sincerely need your help troubleshooting abnormal PeerNode recognition on Huawei S16808 switches. Screenshots of network topology and device links in NetXMS are attached.
Below are nxsnmpwalk commands and outputs against the Huawei private OID on both switches:
plaintext
root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.99.2 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 00 00 AC 5E 14 7F 89 01

root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.99.3 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 00 00 AC 5E 14 7F 89 01
Could you please help identify the root cause and advise a fix? Many thanks.

Очистил таблицу, сервер завелся нормально. Благодарю!

TRUNCATE

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:

1. 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).

2. 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".

3. 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.

4. Discovery filter. If a filter script is configured, a responding host can still be dropped. The level 6 log above shows this explicitly.

5. 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.

**Environment**
- NetXMS Server version: 6.2.1 (Build 6.2-514-g2e01d869eb)
- Platform: Windows (server installer: netxms-server-6.2.1-x64.exe)
- Database backend: SQLite
- Install type: fresh install, Compact install type, SQLite selected as database type during setup

**Summary**
On a completely fresh install with SQLite as the database backend, `nxdbmgr init` reports "Database initialized successfully" and generates an admin password as expected, but the mandatory Default zone object (ID 4) is never actually written to either the `zones` or `object_properties` tables. This causes the server to log the following error on every startup:

    *E* [obj.init] NetObj::loadCommonProperties() failed for Zone object Default [4]

**Reproduction steps**
1. Run netxms-server-6.2.1-x64.exe on Windows, choose Compact install type
2. On the "Initialize Database" screen, select Database type: SQLite, provide a valid path to database file (e.g. C:\ProgramData\NetXMS\netxms.db). Note: an initial installer attempt with an invalid database path (folder only, no filename) failed as expected with a clear "unable to open database file" error — this is unrelated to the bug below, which was confirmed independently on a subsequent clean init using a fully valid file path.
3. Complete the installer
4. Run `nxdbmgr.exe init` manually (in my case this was a clean re-init after deleting the .db file; behavior is identical to the installer's own init)
5. Start the NetXMSCore service
6. Inspect C:\NetXMS\log\netxmsd.log — the zone load error appears on every single startup, including immediately after a fresh, successful init

**Verification**
Ran the following queries directly against the fresh SQLite database via `nxdbmgr -o batch`:

    SELECT * FROM zones WHERE id=4;
    SELECT * FROM object_properties WHERE object_id=4;

Both return zero rows. `nxdbmgr check` reports no errors ("Zone object properties [PASSED]"), suggesting the checker validates referential integrity of existing rows rather than confirming that mandatory well-known objects (like the Default zone) exist at all.

**Impact**
Because the Default zone object is malformed/missing, the Network Discovery "Scan" action (triggered from the Management Console, for both manually-scanned subnets and scheduled active discovery) silently fails — the client-side confirmation dialog fires normally, but nothing is logged server-side and no discovery activity occurs. No error is surfaced to the user in the console.

**What I've tried**
- Full clean reboot of the host — error persists identically
- Complete deletion and reinitialization of the SQLite database file — error persists identically on the fresh init
- `nxdbmgr check` — reports no errors

This looks like a genuine defect in how `nxdbmgr init` seeds the SQLite database on Windows, rather than an environmental or user-configuration issue, since it reproduces identically on a from-scratch database. Possibly related to NX-2867 ("Disable 'Create database and database user before initialization' if SQLite selected in Windows installer"), though I can't confirm that's the same root cause.

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.

DROP TABLE IF EXISTS package_deployment_jobs;

или

TRUNCATE TABLE package_deployment_jobs;

?