NetXMS Support Forum

Hi,

MAC address is stored - it's the MAC Address column on your second screenshot. What is empty there is IP address.

Connection history is built from switch forwarding tables, so it always knows MAC, and takes IP from the node this MAC belongs to. 10.61.67.118 is not a node in NetXMS (Node and Interface columns are empty in the search result), so there is nothing to take it from. IP address search finds the pair differently, by reading ARP caches.

Resolving IP from ARP for hosts which are not nodes is not implemented, I've created feature request: https://github.com/netxms/netxms/issues/3760

If these hosts are added as nodes, new history records will probably have both IP and node filled.

Автоматически — нет. У сервера есть проверка собственной связи (Beacon.Hosts), но к потере связи она привязывает только SYS_NODE_DOWN. SYS_NODE_UNREACHABLE от нод через тоннель и за прокси, а также SYS_NODE_UP и ваши icmp ok не коррелируются. На это завёл тикет: https://github.com/netxms/netxms/issues/3753

Настройками шквал "Node up" убирается так:

• В Server Configuration задать Beacon.Hosts — два-три внешних адреса через запятую (не шлюз локальной сети, он при пропаже интернета продолжит отвечать) — и перезапустить сервер. При потере связи со всеми адресами сервер генерирует SYS_NETWORK_CONN_LOST, при восстановлении — SYS_NETWORK_CONN_RESTORED; стандартные правила держат на это время аларм с ключом NET_CONN_LOST.
• Добавить правило на SYS_NETWORK_CONN_RESTORED, выше стандартного "Terminate NetXMS server network connection loss alarm when connection restored": действие DoNothing, Delayed by 15m, timer key UPLINK_RECOVERY.
• Из правил 26, 32 и 34 вынести Normal MailAlarm (вместе с его "Do not run if timer ... is active") в отдельное правило, стоящее непосредственно перед исходным: те же source и event, флаг "Accept correlated events" как у исходного, "Stop event processing" не включать. В исходном остаются Terminate alarms, DoNothing и Cancel timers.
• В каждом из трёх новых правил — filtering script:
  
  Code Select Expand
  return FindAlarmByKey("NET_CONN_LOST") == null && CountScheduledTasksByKey("UPLINK_RECOVERY") == 0;

Отдельное правило нужно потому, что скрипт в фильтре исходного правила отключил бы вместе с письмом и закрытие аларма, и отмену таймеров.

Note: в течение 15 минут после восстановления связи письма "Node up" и "icmp ok" не отправляются вообще, в том числе от нод, которые в это время действительно поднялись. Алармы при этом закрываются как обычно.

Hi,

This is a bug on server side, not your configuration - I've created a ticket: https://github.com/netxms/netxms/issues/3752

That get-request is SNMPv3 engine ID discovery, which means QNAP sends informs rather than traps - for informs sender first has to ask the receiver for its engine ID. Since 6.1 server checks credentials of every packet coming to the trap port before it looks what kind of packet it is. Discovery request has empty user name by design, so it's rejected as "USM user name does not match" and never answered. Your other devices send plain v3 traps, which don't need discovery.

Until it's fixed, turn credential check off for this node only: add custom attribute SysConfig:SNMP.Traps.ValidateCredentials with value false to the NAS node. No restart needed, but it requires server 6.2.3 or later. I haven't tested this with QNAP.

Note: authenticated v3 messages are still verified with the node's keys, so user name, authentication and encryption in QNAP trap settings should match SNMP credentials of the node (or separate trap credentials on node's SNMP property page).

Hi,

most likely this is not a hang - installer is waiting for database initialization, which runs in separate console window. If initialization fails, that window shows the error and "PRESS ANY KEY TO CONTINUE", and it can end up behind the installer window. With SQLite it usually fails either because folder in "Path to database file" does not exist (file is created automatically, folder is not), or because database file is already there from previous attempt.

Log switch does not change anything here. On second run installer finds existing installation and "Initialize database" is not checked by default, so this step is just skipped - which also means database may still be not initialized. Is NetXMS Core service running and can you log in?

If not, please share what you entered as path to database file and last lines of C:\NetXMS\log\netxmsd.log.

Hi Andrea,

It's not in the Admin Guide yet (I've opened a ticket to add it). For now the documentation is the README next to the extension itself: https://github.com/netxms/netxms/blob/stable-6.2/src/agent/extensions/vcenter/README.md

It's not a subagent - it's a Python agent extension (6.2.0 and later) built on pyvmomi. The agent starts the script and keeps it running, and the script polls vCenter (or a standalone ESXi) once a minute. Setup in short:

• Install pyvmomi on the agent host: pip install pyvmomi
• Add the extension block to nxagentd.conf and restart the agent:
  
  Code Select Expand
  *extensions/vcenter
Mode = spawn
Command = /usr/bin/python3 /usr/share/netxms/extensions/vcenter/nxagent-vcenter.py   # adjust to where your package installed it
Environment = VC_HOST=vcenter.example.com
Environment = [email protected]
Environment = VC_PASSWORD=secret

• Import the template vmware_vcenter_esxi.json and apply it to the node where that agent runs. It creates DCIs for every VM, host and datastore, with thresholds and alarms. It's in share/netxms/templates on Linux server installs, and also on GitHub: https://github.com/netxms/netxms/blob/stable-6.2/contrib/templates/vmware_vcenter_esxi.json

Hi,

Yes, Module = mcp enables it, and you'll want Module = aitools as well - most of the tools the MCP server exposes come from that module.

The module has no settings of its own. It adds the endpoint to the server's built-in HTTP listener, so port and address are set in the [WEBAPI] section of netxmsd.conf:

Module = mcp
Module = aitools

[WEBAPI]
Address = any    # default is loopback only
Port = 8000      # default

The endpoint path is fixed: http://<server>:8000/mcp (streamable HTTP transport). No separate web service is needed - the listener is part of netxmsd and enabled by default. Module = webapi only adds the REST API endpoints, MCP doesn't depend on it.

Clients authenticate with an "Authorization: Bearer <token>" header. Issue a persistent token in the user's properties, and give that user the "Use AI assistant" system right, otherwise requests get 403.

You're right that this isn't documented, ticket: https://github.com/netxms/netxms-doc/issues/87

Hi,

This is a bug in the server, not your configuration: https://github.com/netxms/netxms/issues/3682

Here's what's actually happening: when the node leaves maintenance mode, the server re-generates threshold events for every threshold whose state changed during maintenance. That's where your two "task running" events at 04:00 came from. Those events can be processed while the node is still flagged as in maintenance, and then they get correlated to the "maintenance enter" event, which is why they reference 8766568. By default, EPP rules ignore correlated events, so the rule that should terminate the alarm never sees them. It's a timing race, which is why it only happens sometimes.

Workaround until it's fixed: enable Accept correlated events on the EPP rule that terminates the alarm on OS_PROCESS_OK. As a side effect, the alarm will also be terminated when the task recovers while the node is still in maintenance, which is probably what you want anyway. If the same rule also creates the alarm, split it into two rules and set the flag only on the terminating one. Otherwise alarms will be created during maintenance too.

Hi,

Confirmed, this is a bug in the 6.2 management client, not in the server or your setup. Since 6.2.0 the Auto-link action sends an empty node list to the server, so it reports success and creates nothing. Layer 2 maps are not affected because their links are built by the server from topology data. Fix is tracked in https://github.com/netxms/netxms/issues/3681 and will be in the next 6.2 release.

Until then, "Link objects" still works, but it links two objects at a time and doesn't bind the link to interfaces.

it's fixed already: https://github.com/netxms/netxms/issues/3674

Yes, it's already fixed in the code and will be in 6.2.6, which isn't released yet: https://github.com/netxms/netxms/issues/3656. Only the agent on the Windows machine needs to be updated.

Hi,

Still not fixed - nothing in 6.2.4 or 6.2.5 changed this part of the agent. Remaining problem is now tracked in https://github.com/netxms/netxms/issues/3621 (#3137 was closed after the split).

To move it forward, please post:

• exact warning lines from the server log - package name in them shows which part of the agent produces the duplicates
• nxagentd log with debug level 6 for tag "winnt", covering a full logon and logoff
• System.InstalledProducts table taken twice - once with a user logged on, once without
• whether these are RDS/terminal servers, and whether profiles are roaming, FSLogix or UPD

Hi Marco,

Yes, this is a bug in the Windows agent: https://github.com/netxms/netxms/issues/3656

Process.Count never sees the most recently started process on the machine. So it returns 0 while your EXE is the newest running process, and goes back to 1 as soon as something else starts after it - that's why it looks random. It's not specific to 6.2, so downgrading won't help. Process.CountEx and the other Process.* metrics have the same problem.

Until it's fixed: if the process runs as a service, monitor the service instead (service name, not display name; 0 means running):
System.ServiceState(ServiceName)
Otherwise, with the WMI subagent loaded (SubAgent = wmi.nsm in nxagentd.conf), this returns the real count:
WMI.Query(root\cimv2,"SELECT ProcessId FROM Win32_Process WHERE Name='yourapp.exe'",%%count%%)

Hi,

Bundled OpenSSL only exists in the Windows builds - the agent, server, client and web UI installers ship libcrypto-3/libssl-3 DLLs. Linux packages link against the system OpenSSL and the Docker images inherit Debian's, so on those platforms your distribution's updates already cover this and there's nothing for us to ship.

None of the 16 are exploitable in NetXMS. They land in code paths we don't use at all - CMS, PKCS#7, DANE, CRMF, OCB/SIV and the RSA KEM. NXCP encryption uses RSA with OAEP padding, and certificate revocation is handled by our own code rather than OpenSSL's CRL machinery. The remaining few need gigabyte-scale inputs that a TLS handshake can't deliver. That includes CVE-2026-45447, the only High on your list: PKCS7_verify() is not called anywhere in the codebase.

The Windows DLLs will still be updated, because version scanners flag them regardless of reachability. It's a bigger change than a patch bump this time: OpenSSL 3.0 reached end of life on 7 September and 3.0.22 is the final release of that branch, so we're moving the Windows build to 3.5 LTS rather than to a newer 3.0. Tracked in https://github.com/netxms/netxms/issues/3643 - no date yet.

If you need it cleared sooner, you can drop newer libcrypto-3/libssl-3 DLLs into the agent's bin directory yourself; OpenSSL keeps ABI stable across the 3.x series, so 3.5 works in place. Two caveats: they'll be overwritten on the next agent upgrade, and they won't carry our code signature.

Hi,

Confirmed bug, not a configuration problem - your community is configured in the right place. Filed as https://github.com/netxms/netxms/issues/3639

Discovery does try the communities from Network Credentials and does find the working one, but it is discarded before the node object is created, so every discovered node starts on the default "public". Affects all versions since 6.1.0.

Normally this repairs itself: the configuration poll that runs right after node creation tests "public", fails, falls back to the credentials list and writes the correct community back. It does not repair when the device answers "public" as well - the poll tests the node's current community first and stops as soon as it gets any response. That is most likely what you are hitting, since it happens on every device. Worth confirming on one:

nxsnmpget -v 2c -c public 10.61.200.26 .1.3.6.1.2.1.1.2.0
Anything other than a timeout means the device accepts "public" and the automatic correction will never kick in.

Correcting the community on the node stays the workaround until the fix ships - Node::setSNMPCommunity() is available in NXSL if you want to fix existing nodes in bulk.

Unrelated: SNMP.Agent.CommunityString is the community for the server's own built-in SNMP agent (disabled on your server), not for polling, so it has no effect on discovery.

Hi,

nxmc is already jakarta — it's built against jakarta.servlet-api 6.0 and its web.xml declares Jakarta EE 10, so ee10 in your setup is correct. What's failing is that the file you deployed as nxmc-6.2.4.war is not the web UI, it's the Legacy Web API war (netxms-websvc). That one is still javax/EE8 and under ee10 it fails exactly like this.

Two things in your log point at it: the missing class is javax/servlet/http/HttpServlet, which nxmc has no reference to at all, and the context starts as "NetXMS REST API" — that display name comes from the API war's web.xml, the web UI war has no display name.

Check with:

unzip -p /usr/share/jetty-base/webapps/nxmc-6.2.4.war WEB-INF/web.xml | head -8
The web UI war has xmlns="https://jakarta.ee/xml/ns/jakartaee" and version="6.0". What you have will show <display-name>NetXMS REST API</display-name> and version="2.4".

Re-download nxmc-6.2.4.war from the Web Interface Binaries section — the two files sit next to each other there — and it deploys into your existing ee10 setup unchanged.