NetXMS Support Forum

The names of parameters changes at some point. A newer template version is shipped, but NetXMS with default settings does not overwrite the templates (with the idea that user could have changed the out of the box templates).
It's Server Configuration setting "ImportConfigurationOnStartup". By default it's "Only missing elements", so you can either delete the template and restart the server (but you will loose DCI history), or you can set it to "Always" and restart the server.

The third option - you can import that template manually (Tools -> Import Configuration), here's the file: https://raw.githubusercontent.com/netxms/netxms/master/contrib/templates/netxms_server.xml

The issue is fixed and will be available in 3.6 which will be released this week.

Да, я не очень разбираюсь в Tomcat, но это ж форум, тут любой может высказаться.

Веб интерфейс с какой-то определенной версии NetXMS перестал работать с 7 Tomcat, нужен 8-й. Какая у вас версия NetXMS и что именно вы хотите поставить - web интерфейс или web api - не очень понятно. Ну и в целом - поддержка на Centos 7 гарантированно обеспечивается только для коммерческих клиентов: https://www.netxms.org/documentation/adminguide/installation.html?highlight=tomcat#operating-system

Веб интерфейс это вот это: https://netxms.org/download/releases/3.5/nxmc-3.5.90.war
а у вас в файлике написано NetXMS REST API - это по идее другя вещь - WEB API.

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.