NetXMS Support Forum

You can easily test it - just take any node, select Execute script from the context menu and paste your script there. Your script will be executed in the same way as when a template executes it on nodes.

In addition, when you execute it that way you can use println() commands to print, so you can use it for debugging purposes.

Here's a fixed version:

if (!$node)
   return false;

pn = $object.platformName.toLowerCase();
if (pn != null && pn.startsWith("windows"))
   return true;

sd = $object.sysDescription.toLowerCase();
return (sd != null && sd.contains("windows"));
$object always exists, so there's no need to check for that. NXSL never had LowerCase() or StrStartsWith() functions, did you use an AI to generate this?

Could be that during the execution of the first script it deleted all the duplicates.

Hi, 

The problem is that "apt upgrade" automatically started nxdbmgr background-upgrade.
But there's currently no lock mechanism, so starting it manually ended up in it running two parallel processes of it. 
Lock will be added in a future version. Currently just don't run nxdbmgr background-upgrade after the upgrade (you can check with ps command that it actually running). 

Hi!

Sorry, it took a while, we've had some vacations here. 

I've replicated this behavior if there's more then one path of inheritance for the custom attribute - e.g. a node is present in two containers. Created a ticket for that: https://track.radensolutions.com/issue/NX-2831

You probably have several hierarchies under Infrastructure which contain same nodes in them. If so, for now the fix could be to avoid multy-path inheritance by creating custom attributes only on one container under Infrastructure. The reason is that currently custom attributes are not handled correctly in such situation, there's another ticket for that, possibly related to the one I've just created: https://track.radensolutions.com/issue/NX-2717

Log should be specified as:

*Microsoft-Windows-TaskScheduler/Operational

(if you open Properties for that log in Windows Event Viewer, the correct name is in the Full Name field)

Table DCI summary tables work, I've tried in the new API, but it should be same in the old one under /summaryTable/adHoc

curl -s -X 'POST' 'http://127.0.0.1:8000/v1/dci-summary-tables/adhoc-query'  -H 'Authorization: Bearer xxxxxxxxxxxxxxxxxxx' -H 'Content-Type: application/json'  -d '{ "objectId": 2, "tableDefinition" : { "flags": 2, "dciName": "Network.Interfaces" } }'
P.S. flags are the following:
/
 * Summary table flags
 */
#define SUMMARY_TABLE_MULTI_INSTANCE      0x0001
#define SUMMARY_TABLE_TABLE_DCI_SOURCE    0x0002

/
 * Summary table column flags
 */
#define COLUMN_DEFINITION_REGEXP_MATCH    0x0001
#define COLUMN_DEFINITION_MULTIVALUED     0x0002
#define COLUMN_DEFINITION_BY_DESCRIPTION  0x0004

Do you see file(s) with configuration from your policin in this folder?:
C:\Windows\System32\ config\systemprofile\AppData\Local\nxagentd\config_ap

(files have .xml extension, but inside there should be plain-text agent configuration). 

There's StartupDelay parameter in agent config. Setting it to some time in seconds should prevent server connection to the agent for that time. Pls give us update if this helps. 

Well, not so sure now, will check how this works. But don't think it's currently exposed to the API

For historical reasons all events, also related to specific interface are generated on the node object. 
Object selector in EPP currently allows selection of interfaces, but this is a bug, this will be fixed. 

If you don't need events for specific interfaces you can
- change interface expected state to "Ignore"
- unmanage an interface
- if you still need this in EPP, it could be done by EPP filter script

We don't have a concept of DCI summary table from table DCIs. 
One option is to have a number of single-value push DCIs, then in transformation script of your table DCI you can push values into these. 
Or, via the API you can call   /objects/{object-id}/execute-script endpoint and call a script that would return the data you need. 

This can be discussed with developers, but we need to understand the use case in details. 

So the idea is to keep like misc metainformation about the node? Would be nice if you can share a screenshot of what you keep there (via PM if needed). 

As a brainstorm - this can be just stored in node's comments as markup-formatted table. Or yes, to use Table DCI for that. You can have a context dashboard that automatically opens in a tab and displays contents of that table. 

Yes, tables with script source are collected on schedule. Also you can force collection by using 
forcePoll() method of DCI class (https://netxms.org/documentation/nxsl-latest/#_instance_methods_8)

Yes, in this case you'll have one script for all nodes. Buy you can call other scripts from that script. And you can pass parameters to that script (in metric field in DCI's properties)

After policies are deployed agent should be restarted, as it reads configuration on it's startup. 

Agent logs it's configuration to it's log when it starts - you can check the log. Or you can get agent's list "Agent.RunningConfig" - it will contain current configuration. 

If things feel wrong - you can put
DebugLevel = 6
to agent's config - it will collect detailed log, during configuration poll this log should contain info on what's happening with the policies. 

Also pls inform what are server and agent versions. 

Hi, 

Sorry, vacation time here so answering was delayed. 

Setting number of samples to 24 means that all 24 samples should return "true". It would trigger only if 24 consecutive data collections will return different value. So not what we need here. 

We don't have built-in thing for "no changes within given time", so we will use a bit of scripting. In the Transformation page of your DCI put the following: 

oldValue = GetDCIRawValue($node, $dci.id);

if (oldValue != $1) {
  $node.setCustomAttribute("lastChangeTime", time());
}

lastChangeTime = $node.getCustomAttribute("lastChangeTime");
if (lastChangeTime == null) lastChangeTime = 0;

return time() - lastChangeTime;
Set Data type after transformation to Integer (this is relatively new feature, if you don't have it, upgrade to 5.x).

On the General page set Units to Uptime.


This should be it. Now how it works - in the transformation script we compare new value to the previous raw walue. If they differ we save timestamp into custom attribute on the node. And we subtract value of this custom attribute from current time - so result of the DCI is time in seconds since last change of the value. You can just set a treshold > 86400 and it should work.