NetXMS Support Forum

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.

The backtrace pins it exactly: it's a bug in our MariaDB driver, triggered by an oversized entry in the image library.

Since 6.2 images are stored in the database instead of as files, and the driver allocates the buffer for a field on the stack, sized by the length of that field. Server worker threads get a 1 MB stack by default, so an image over roughly 780 KB overflows it and the process dies the moment anything asks for that image - which is what opening the dashboard does. The upgrade migrates existing image files into the database, so an image that had been fine for years starts crashing the server right after.

Two steps to get you running again.

1) Add to netxmsd.conf and restart the server:

DefaultThreadStackSize=8M
That raises the worker stacks and stops the crash right away.

2) Find the image and replace it with a smaller one:

SELECT guid, name, category, LENGTH(image_data) FROM images ORDER BY LENGTH(image_data) DESC LIMIT 5;
Anything near or above 1000000 is the one. Re-upload a downscaled version through the image library - listing and re-uploading are safe, only fetching the image bytes crashes.

Ticket is https://github.com/netxms/netxms/issues/3637 - the driver should allocate large fields on the heap, not the stack.

Hi,

Fastest way to pin this down is to run the server under gdb and let it stop at the crash - the backtrace names the code path directly.

apt install netxms-dbg
systemctl stop netxms-server
gdb /usr/bin/netxmsd
run -D3
# open the dashboard in the client, wait for the crash
bt

Post the bt output here.

netxms-dbg is required - without it the backtrace is just hex addresses and tells us nothing. Without -d or -S netxmsd stays in foreground, which is what we want; it also starts interactive console there, so add -q if that gets in the way of gdb.

Note: Scripts.RestrictWriteAccess has no effect here. Dashboard element scripts run under user security context, not the read-only one that parameter controls, so toggling it changes nothing either way.

Hi,

Not fixed - I've reopened https://github.com/netxms/netxms/issues/3137. It was closed against a different fix (#3240) that only covered part of the problem.

Your combination is not the version mismatch Filipp mentioned - agent 6.2.3 and server 6.2.2 both contain everything from that work, so the "server must also be 6.2" note does not apply to you.

What is left: the agent can still change the reported user name, and sometimes the display name, for the same Store package between two polls, without signalling that the data is incomplete. Since 6.1 the server treats package name plus user as the package identity, so any such change comes out as a remove plus an install. Most likely triggers are a user profile whose registry hive is not on disk while the user is logged off (roaming profiles, FSLogix, UPD), and a failed SID-to-username lookup.

To tell which one you are hitting, please post:

• 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

Workaround is poor. There is no way to exclude Store packages from the inventory, and the inventory is collected on every configuration poll. Since 6.1 SYS_PACKAGE_INSTALLED and SYS_PACKAGE_REMOVED carry the user name as an event parameter, but filtering on it only removes half of each pair - the other half is reported as a system-wide package with empty user.

Hi,

"Driver Error" is as generic as it looks - it only means the driver loaded, your config parsed, and the POST to the webhook came back with something other than HTTP 200 and a body of exactly "ok". A transport failure, a non-200 code and an error string from Slack all end up as that same message. (If the driver itself were missing or unloadable you'd get "Driver not initialized" instead, so that part is fine.)

To get the actual error, in Tools -> Server Debug Console:

debug ncd.slack 7
debug nc 7

then send again and look in the server log (path is set by LogFile in netxmsd.conf, /var/log/netxmsd by default). It will be one of:

• Call to curl_easy_perform() failed - transport level: DNS, TLS, firewall. Note the Slack driver has no proxy option, so if this server reaches the internet through a proxy, that alone will stop it.
• Error response from webhook: HTTP response code is N
• Error response from webhook: <text> - Slack's own error, e.g. channel_not_found or invalid_payload.

Two things worth checking before you do that:

• url must be a classic incoming webhook - https://hooks.slack.com/services/T.../B.../... - which replies with the literal string "ok". A Workflow Builder trigger URL (https://hooks.slack.com/triggers/...) replies with JSON instead, and the driver will report Driver Error even though Slack accepted the message. This is the easiest one to get wrong right now, since Slack pushes you towards Workflow Builder.
• Recipient is mandatory for this driver and goes out as the Slack channel override. If it names a channel that doesn't exist you get channel_not_found back.

Your post shows url= with nothing after it - assuming that's just removed for the forum, but worth confirming the value actually saved.