NetXMS Support Forum

Timer cancellations are related to server actions that are launched when an event happens. In event processing policy you can configure an action that is executed and set execution delay (in seconds). When event happens, the action will be scheduled. To be able to cancel this particular action we need to mark it somehow. This is done with timer key. This field can have macro fields in it, so e.g. for every node or node-dci combination, etc this field can be unique.

Then we can have another record in event processing policy that can have timer cancellation action. It has the same timer key. If that happens before the timeout goes out, the scheduled action will be cancelled. If not, the action will happen.

Hi!

NetXMS has a tool called nxdbmgr that has an option for database migration. It is launched like this:
nxdbmgr migrate old.configuration.file
The idea is that this tool is launched on the system you are migrating to. In the regular netxms configuration file on that system you have all the configuration for the new database. And you have another configuration file that has connection parameters to the database you are migrating from - that file name is given to nxdbmgr as parameter.
Before migration you have to initialize the new database by running nxdbmgr init.
netxms server should be stopped so no new data appears in the database during migration.
Migration is only supported on the same version of the database. So you can install 2.2.17 on the new system, do the migration and the do the upgrade.
A more recommended way is to upgrade first and migrate then (in that case you would use newer nxdbmgr that possibly has some bugs fixed) - but for that you would need to compile libprce32, so I would try the above approach first.

Support for WMI queries returning lists or tables will be made available in 3.1 version.

Currently WMI subagent does not support data presentation as table or list, it just takes first from received values. We are planning to implement this at some point of time.

Capabilities are stored as a bitfield in that long integer, here you can find which bit represents what capability: https://www.netxms.org/documentation/datadictionary-3.0/#t-nodes

So, transformation scripts, as well as other scripts in NetXMS are written in NXSL - custom scripting language. It's syntax is resembling C language syntax. Language documentation can be seen here: https://www.netxms.org/documentation/nxsl-3.0/

Here's a sample script:

if ($1 == 9) {
  return "x64";
}
else if ($1 == 0)
{
  return "x86";
}
else
{
  return "unknown: ".$1;
}


$1 is the raw value (after step 1 of transformation), so in this case it's either 0 or 9. Other variables are also available in the script, e.g. $node in the node object to which the DCI belongs to. $node->name would be the name of the node.

You can use trace function to print debug information to server's log file, first parameter of trace is debug level on which the information is printed
trace(0, $node->name)

P.S. For me only the following syntax of the parameter worked on Win7:
WMI.Query(root\CIMV2,SELECT * FROM Win32_Processor, Architecture)

В 3.0 у events добавлены теги, по ним можно фильтровать список events.

In the SQL query output that you sent above you can see lines like this:
<formatString>%*s</formatString>
%*s should be replaced to some other format, where letter comes right after % character.

NetXMS server should be stopped when editing the database.
Care should be taken when editing the database, it's recommended to do database backup prior to editing.

Alternatively you can wait when NetXMS 3.1 will be out - hopefully this will happen by the end of next week.

In Server configuration parameters there's a parameter called ImportConfigurationOnStartup. By default it's set to "Only missing elements". In this mode, server imports default templates only if such template is not present in the system. Import happens on each server startup. If template is present, server does not overwrite it.
This means that you can modify the template and it will not get overwritten. If you delete it, it will get recreated on next server startup.

Currently $dci is not supported when a script is called from event processing. For SYS_THRESHOLD_EVENTs DCI ID is passed as 5-th parameter of $event:

trace(1, "Script on SYS_THRESHOLD_EVENT: DCI ID: ".$event->parameters[5]+0);
trace(1, "Script on SYS_THRESHOLD_EVENT: DCI name: ".GetDCIObject($node,($event->parameters[5]))->name);
trace(1, "Script on SYS_THRESHOLD_EVENT: Interface name: ".GetDCIObject($node,($event->parameters[5]))->relatedObject->name);


Yes, I just tested a SYS_NODE_DOWN event and it made sound in the Android app.
Do you have alarm generation configured in Event processing policy for your event?

Server console is not analyzing double quotes - enquoted arguments are just passed to the script as string having quotes on both ends, that's why it's not matching.

In android app in settings -> Alarms there is section "Customize alarms by severity". If you click, e.g. critical alarms there, you can select sound for that severity level. By default it is set to "Silent".

Hi!

The first thing to check is if netsvc subagent is loaded on the agent that is performing the check.
It's the concept of NetXMS that agent performs only a part of checks and many checks are done by subagents that have to be congigured in agent configuration file: https://www.netxms.org/documentation/adminguide/agent-management.html#agent-configuration-files

А какая сейчас выдача при полном запросе конфигурации ноды?

What happens, if you restart management console? If you restart netxms server?