NetXMS Support Forum

In the properties of node, which you are trying to poll under Communications there is "Primary host name". This is the address of agent to which netxms server is connecting. Take this address and add it to MasterServer line of agent config after comma.

Your debug approach looks to be correct. There also could be also some information under "nc" tag.
Is the actual .py script executed?

I've tried like this, it's working:
Command=/bin/bash -c "/bin/echo ${recipient} ${text} >> /tmp/sss.txt"

What exact version of netxms are you using?

There was a bug recently that upgrade command was actually not executed.
The upgrade however is uploaded.
You can create agent action that executes CMD.EXE /C "C:\NetXMS\var\nxagent-3.9.334-x64.exe" /VERYSILENT /SUPPRESSMSGBOXES /LOG /FORCECLOSEAPPLICATIONS /NORESTART
and it should do the job.
You can create agent configuration policy in a template and apply this template to your nodes - this way you can distribute this action to your agents.

If you install netxms agent on these machines (and add the address of your netxms server to MasterServer or ControlServers or Servers in agent configuration) then netxms would be able to get information about network interfaces. The other option is if SNMP daemon is running on the machines.
Without that netxms can only see that there is a machine and can ping it to check if it's running. But it can not determine that two addresses belong to same machine.

Most probably this means, that the address of your netxms server is not in MasterServers line of agent configuration.

If the agent is on the same machine as the server, the default configuration for the agent includes MasterServers=127.0.0.1, but the node that is automatically created refers to external address of the machine.

Maintenance mode only suppresses event generation, but data collection and status propagation is still happening. If the nodes are temporarily decommissioned, you can put the to unmanaged state (node context menu - Object-Unmanage) - then they will stop affecting parent container status.

Changing of interface expected state is possible from NXSL script. We currently do not have option to keep NSXL scripts in templates, so you have to use some sort of global script for this.
Hook::ConfigurationPoll is a good place - it's a standard hook script that is executed on each configuration poll.

A simple example is this:
interfaces = GetNodeInterfaces($node);
foreach(i : interfaces)
{
SetInterfaceExpectedState(i, "IGNORE");
}

but you need a bit more advanced script. You can check, if node is assigned to particular template (in this case node becomes a child object of the template, so you can use e.g. $node->isDirectParent(template_object) method to check this).

You can use mapping tables to keep list of interfaces that should be in "UP" or "DOWN" state if you need to.

Please inform, if you need more information or examples.

I did not test this, but probably it does not support format with \ in the database address field. Try just IP address there.

Anyways, all that the installation wizard does is creating C:\NetXMS\etc\netxmsd.conf and launching
nxdbmgr init
(which is located in C:\NetXMS\bin).

So you can adjust the .conf file and run nxdbmgr init manually. When it succeeds, you can start Netxms Core service.

Do you actually have MS SQL database installed?

It should work the same as for regular Postgres and other databases. There were performance fixes recently, so upgrading to the most recent versions is recommended.

Nxdbmgr requires to stop netxmsd, so you may prefer backup by some postgres means instead.

Yes, sure, if NetXMS Core service is stopped, it's won't poll anything.

На ноде можно сделать internal DCI, например ICMP.ResponseTime.Average или ICMP.PacketLoss. И дальше на него threshold.

https://www.netxms.org/documentation/adminguide/icmp-ping.html#icmp-response-statistic-collection

So, if I understand correctly, the error "Broadcast Storm ended duration ..." was produces by some other equipment, not NetXMS.

First of all, it would be good to understand, how the monitoring is performed. How many nodes are there in NetXMS. How many nodes per production plane? How these nodes are being polled - is it SNMP or something else? Are there any NXSL scripts used for monitoring?

The recommendation would be to set up a test environment - just another computer with netxms that would be monitoring e.g. just one of your your plants, or may be just some of it's nodes.

There should not be too much difference in how 3.9 is polling the devices, but it could be that e.g. there are some additional SNMP requests performed on each status poll.

The other useful tool is Wireshark - you can install it on the same machine where NetXMS is running. It will capture all network packets (you can limit it e.g. to one IP address), so you can have information on how many packets there are per minute. At least for SNMP, if there are a lot of excessive packets, you can look inside and see what exactly OID is requested.

Here's a build that should have this issue fixed: https://cloud.radensolutions.com/s/8cgm7fBWHjr92ZS

Could be good, if you can clone this installation to some test system, which can be upgraded to test what could be the issue.