NetXMS Support Forum

With current API we need to set all fields related to propagation to modify anything there:
node = session.findObjectByName("ttt")
if node:
    md = NXCObjectModificationData(node.objectId)

    # copy existing properties
    md.statusPropagationMethod = node.statusPropagationMethod
    md.statusCalculationMethod = node.statusCalculationMethod
    md.fixedPropagatedStatus = node.fixedPropagatedStatus
    md.statusShift = node.statusShift
    md.statusTransformation = node.statusTransformation
    md.statusSingleThreshold = node.statusSingleThreshold
    md.statusThresholds = node.statusThresholds

    # new value
    md.statusPropagationMethod = AbstractNode.PROPAGATE_DEFAULT

    session.modifyObject(md)

Also, it's possible to change propagation setting from NXSL, that should be easier and you can do this e.g. from interface creation hook.

And it's also possible to change what the default settings are - it's set in Configuration -> Server configuration.

There's no out of the box configuration for this. If on Linux you can create a server action that executes logger. There should be something similar for Windows.

I would create a DCI on that node of type Internal with parameter Dummy. Set custom schedule for this DCI so that it will be collected once per day at some time. In transformation script of this DCI:
return $node->state & NodeState::Unreachable;
This DCI will be 1 if node is unreacheable or 0, if reacheable (or you can modify that in the transformation script).
Then just create a threshold for this DCI and probably a separate event for this.

Alternatively you can use a scheduled task that is calling a script, that would do the same.

Да, есть такое. Через несколько дней выйдет 3.6, там не будет больше этого пункта в UI т.к. все настройки сертификатов унесены в серверный конфиг.
Параметр в серверном конфиге будет называться TrustedCertificate (переименован из ServerCACertificate) - это будет общий параметр и для туннелей и для авторизации.

Have a look at the below example:

from org.netxms.client.objects import Node

for name in open("nodes.txt").readlines():
    node = session.findObjectByName(name.strip())
    if node:
        md = NXCObjectModificationData(node.getObjectId())
        newFlags = node.getFlags() | Node.NF_DISABLE_SNMP
        md.setObjectFlags(newFlags)
        session.modifyObject(md)


There's 18 seconds between Checking SNMP... and the next line of this configuration poll, this means that SNMP commnunication step has timed out. This basically means that SNMP device did no answer.
- Check Communication -> SNMP settings in properties of the node - if version and community string is correct.
- you can check with wireshark or tcpdump what OIDs NetXMS is requesting during configuration poll. E.g. for SNMP v2 request for these OIDs is sent:
    1.3.6.1.2.1.1.2.0
    1.3.6.1.2.1.1.1.0
    1.3.6.1.4.1.35160.1.1.0
Try running e.g.
snmpget -v 2c -c public node-ip-address 1.3.6.1.2.1.1.1.0
at the command line on the machine where NetXMS is running. Will it return any data?

"Use this DCI for node status calculation" is in properties of DCI, see attached screenshot.

Try logging into NetXMS management console by administrative user and check that that user has "View all alarm categories" right (or belongs to a group that has this right set). It's in Configuration -> User manager.

Hi!

If you open Object Details -> Overview, there's column "Capabilities" on the right hand side. There's is property called "isSNMP". If it's "Yes", it means that NetXMS has detected that the device is SNMP capable and is querying it via SNMP. Capabilities are detected on Full Configuration poll. So if you problematic devices have "No" there, try doing Full Configuration Poll.

P.S.
In netxms debug console it's possible to filter out some of the things by the debug tad. e.g. you can issue
debug client.* 0
to turn off debug messages for management console.
debug client.* -1
will return debugging for this debug tag to default.

Currently object tool filter uses OR logic, if multiple custom attributes are specified.
Possible workaround could be to have a script in Configuration Poll hook, that would set custom attribute C if A and B are set.
Or if you need only two things to consider, you can use a custom attribute and adding nodes to a special empty templates - logic between several types of filters is AND.

AND logic between several custom attributes could be implemented somewhere in the future. It would be good if you could describe your use case in more details.

.

So overall there are three things can affect node status:

- Alarms
- Status of node interfaces
- DCIs that have "Use this DCI for node status calculation" option set.

A node can nave alarm that belong to some alarm category that is not visible to given user. There is user right "View all alarm categories" that should be set for administrative users. Could be that this right did not get set after one of the upgrades.

How status of interfaces is transferred to node depends on status propagation settings for interfaces and status calculation settings for a node. If these are not default then node status could be different from status of underlying interfaces.

Check DCIs if "Use this DCI for node status calculation" is not set.

nxdbmgr - NetXMS utility for database operations has built-in mechanism for database migration.

nxdbmgr migrate <source>

where source is the name of netxms configuration file that points to the database you are migrating from. There's a number of options that allow to skip DCI data, etc and it's possible to migrate DCI data afterwards after starting NetXMS with the new database.

There's an outdated wiki post on that, it does not list all possible options: https://wiki.netxms.org/wiki/How_to_migrate_to_another_database

There's a big delay after "Checking SNMP..." line, which means that NetXMS is not getting any reply from the device.
Try running
snmpget -v 2c -c public DEVICE_IP 1.3.6.1.2.1.1.1.0
on NetXMS server - there should be some output. If there's none, please check community string and SNMP protocol versions supported by the device.

Make a script in scrip library, e.g. GetNodeName:
r = "";
for (n : GetAllNodes())
{
  if (n->ipAddr == $event->parameters[1])
  {
    r = n->name;
    break;
  }
}
return r;

In event template call it like this:
*OSPF State change* %[GetNodeName] %1 from %2 to %3

The script will be called in the context of the event, so the first parameter of the event where you have the IP address will be available there.

Please share the text output of full configuration poll