NetXMS Support Forum

Hi,

Use PowerShell to retrieve the status of scheduled tasks:
https://blogs.technet.microsoft.com/heyscriptingguy/2015/01/12/use-powershell-to-show-results-of-scheduled-tasks/

You can then monitor specific (or all) tasks using ExternalParameters/ExternalLists/ExternalParametersProvider depending on your exact requirements.

Cheers

Hi,

You need to allow the server to connect to the agent, by adding a line like this:
MasterServers = <IP NetXMS Server is connecting from>
Then restart the agent and check again.

Cheers

Hi Eriks,

We have an Everyone group, but it doesn't contain any actual users (at least it's not listing any).
Note that we are using LDAP. Not sure if Everyone only applies to Local accounts (though the few that exist aren't showing as members either).

Cheers

Hi,

A very simple example I just tested using ExternalTable and PowerShell.

Add this to your Agent configuration:
ExternalTable=TableTest:instanceColumns=Index;description=Table with data;separator=|:powershell -c "\"Index|Column 01|Column 02`nIndex 01|Data 01|Data 11`nIndex 02|Data 02|Data 12\""

What this does is:

• create an External Table called "TableTest".
• the Instance Column is called "Index" (the column "Index" exists in the data)
• the Description is just that, the description you see when you select this table as DCI
• the separator is set to |, so the data you provide needs to have its columns separated by |. You could make this something else.
• provide the actual command that generates the data. In this came a simple PowerShell command to print some text

Nothing is stopping you from calling an PowerShell script to return the data.
You can also pass parameters. Just used ExternalTable(*) instead of ExternalTable and then reference the parameters as usual using $1, $2, etc.
Keep in mind if you need to use actual $ in your command (e.g. $_), you need to escape the $ by writing $$ (e.g. $$_).

See attached image for a screenshot of how this table looks like once it has been pulled into NetXMS.

Cheers

Hi,

Just comparing my startup logs with yours, it appears your server might be listening on the wrong port?

Here's an excerpt of my logs (just the Listening for lines):
[12-Oct-2017 13:37:25.750] [INFO ] Listening for SNMP traps on UDP socket 0.0.0.0:162
[12-Oct-2017 13:37:25.750] [INFO ] Listening for SNMP traps on UDP socket [::]:162
[12-Oct-2017 13:37:25.758] [INFO ] Listening for syslog messages on UDP socket 0.0.0.0:514
[12-Oct-2017 13:37:25.759] [INFO ] Listening for syslog messages on UDP socket [::]:514
[12-Oct-2017 13:37:25.764] [INFO ] Listening for client connections on TCP socket 0.0.0.0:4701
[12-Oct-2017 13:37:25.776] [INFO ] Listening for client connections on TCP socket [::]:4701
[12-Oct-2017 13:37:25.776] [INFO ] Listening for mobile device connections on TCP socket [::]:4747
[12-Oct-2017 13:37:25.776] [INFO ] Listening for mobile device connections on TCP socket 0.0.0.0:4747
[12-Oct-2017 13:37:25.776] [INFO ] Listening for agent connections on TCP socket 0.0.0.0:4703
[12-Oct-2017 13:37:25.776] [INFO ] Listening for agent connections on TCP socket [::]:4703

Your logs show that your server is listening for client connections on 4700, not 4701.
4700 is the port the NetXMS Agent listens on, not the server.

Cheers

Hi,

I recall seeing that support for External Tables was added in a release candidate for 2.1:
https://www.netxms.org/documentation/adminguide/agent-management.html?highlight=externaltable
You could use this to call a PowerShell script, which returns the values in the required format.
Someone else who may have already used this functionality may be able to assist further (I haven't used it).


Otherwise, I am assuming you are referring to this post: https://www.netxms.org/forum/configuration/executing-powershell-with-tabel-result/
ExternalParametersProvider will not give you an actual table DCI.
But you can use it to return a number of name=value pairs, where "name" will be the parameter of your DCI and "value" the value for it.
Together with an ExternalList (e.g. by taking the output of (get-Vm).Name) you could then use Instance Discovery to create DCIs for each VM and any data point you may be looking for.

That actually does not rely on using ExternalParametersProvider (you could just have a number of individual ExternalParameters that take the VM Name as parameter), but it would make sense to do so. Better to call a single PowerShell every so often by the agent to pull all data you want, than to start a new PowerShell process for each individual DCI for each individual VM.

The ExternalParametersProvider documentation is right above the ExternalTable one given in the link above. Just scroll up a few lines.


Cheers

Hi Thomas,

$ marks a parameter passed by NetXMS, hence $_ will not work for you.
For a literal $, write $$, so your line would look as follows:

ExternalParameter=Ext.grep_count(*):powershell.exe -command "Select-String -Path \"$1\" -Pattern \"$2\" | Measure-Object | Foreach-Object { echo $$_.Count }"

Cheers

Hi,

It seems all attempts to upgrade agent packages via Package Manager now result in "Installing" and en eventual timeout.
When I run a configuration poll afterwards, the agents were upgraded successfully - but with the number of agents we are running, deployment is slowed down quite a bit as I have to upgrade in small batches rather than just queuing everything.

All our agents are using Agent Tunnels, so I am not sure if that is somehow related?

Cheers

Update: A single agent which was not using Agent Tunnels actually completed the upgrade properly.

Hi,

It would be a nice feature to be able to filter values on a line graph.
So instead of just setting the minimum and maximum Y values for the graph, which will still show the up/down spikes of values higher or lower than that, be able to actually set the maximum and minimum values to be returned and used for the graph. It can make a graph a lot more readable to be able to filter some data out.
For usability the system shouldn't really ask you for those values when you select DCIs and say "Line Graph", but once the graph is shown, it could be an option to go into the properties of the graph and set the minimum/maximum values per data object on the graph.

Cheers

Hi,

Do " get stripped out of parameters when calling an Action via Object Tools? I am trying to run a netsh command which requires me to place the interface name in quotes, but the command is not working and the command is logged without quotes in the agent log (debug level 7). The command also seems to be cut short, (presumably related to the quotes).

I have an action that triggers the following:
cmd /c $1
and I am passing
netsh interface ipv4 show subinterface interface="Ethernet 2"
The log then tells me it is executing this:
cmd /c netsh interface ipv4 show subinterface interface=Ethernet

And the result is that the command of course doesn't work as expected.

Thanks

Just to keep with the tradition of asking: When are the Debian/Ubuntu packages released? 

At our end we use zoning for that with one of two setups:
- All devices are in the same zone and you use the proxy to query the external router from the inside (i.e. you change the router's IP in NetXMS to the LAN IP).
- You keep the external router in the default zone with a public IP address and the proxy and other internal devices in a separate zone (with the proxy using the same public IP as the router).

IPs have to be unique within a zone.

(Not sure if there is a way to make this work using the "This is address of remote management node" checkbox which I believe removes the IP from that "uniqueness" check, but it didn't seem to work for us. Could have been a caching thing though.)

If the "Everyone" group is the only one getting that flag set during the upgrade, then maybe that's the issue. We are certainly using more specific groups at our end, hence the need for us to set this manually.
Considering that pre-2.1 every group effectively had this permission (as no categories existed and everyone could see everything), maybe all user groups should have it enabled by default upon an upgrade, not just "Everyone"?

But this is kind of hijacking the thread now.

Eriks:
That didn't seem to happen during the upgrade at our end. Considering the number of post-2.1 upgrade forum posts which are fixed by checking the "View all alarm categories" permissions, I have to assume something may not always work as expected during that DB upgrade?

Tomislav:
If a switch is showing anything in the Ports tab depends on if NetXMS has a driver for the device in question. For us that tab works with HP and Cisco gear, but not with Brocade, Netgear and TP-Link "Smart" switches.
For the Interface tab, select the properties of the node, select Polling and test the Enable and Disable options under "Use ifXTable for interface polling", run a Configuration Poll after each and see if the Interfaces tab populates. If it doesn't, the switch in question may have some vendor specific way of providing interface information (which would require a specific driver for that hardware).
I am actually not sure about the Outstanding Reminder. I tend to not leave my alerts in "Outstanding" state, but Acknowledge them.
For testing purposes I just enabled the "Show pop-up reminder for outstanding alarms", set a sound and triggered some events which I didn't acknowledge. Eventually I got a pop up with a list of outstanding alarms together with the sound. I didn't time it, but seemed to happen/repeat every five minutes?

Regarding the node status, you may not be seeing all alerts after the migration to 2.1.
Ensure your user has "View all alarm categories" permissions. This is new to 2.1 and is not granted automatically to existing users (including admins).

You can change the status calculation per interface. Select the interface, open properties and Status Calculation.
When an interface is not in the "expected" state, it will generally trigger a "Critical" status. If you select "Severity based" under "Propagate status as" and switch Critical -> Critical to Critical -> Warning, it will only trigger a warning status on the node (for that interface only).
Alternatively, if there are interfaces you don't care about because they are not "always on", just set the expected state to "Ignore".