NetXMS Support Forum

You should not use start there - it starts given command asynchronously, not waiting for it's completion. Agent will never get the output of the command. How you CMD file looks like? Also, you can try using form

ExternalParameter = cmd.exe /c C:\NetXMS\Test\Launch.cmd

Best regards,
Victor

I can think of the following ways:

1. Schedule external script using system scheduler and write result to a file; then you can get into DCI content of that file, which can hold execution result of and external script, and fact of such file presence and/or last modification time.

2. If you have long-running script which should be executed with fixed intervals, you can use external parameters provider. It works by running given script periodically and caching the results. Then, when server requests value of provided parameters, result from cache is returned immediately.

There are also a lot of possible variations - like starting external script from server using actions, and so on.

Best regards,
Victor

P.S. I start thinking that having some kind of scheduled jobs in the server could be useful in situations like that.

NetXMS server does 3 retries after timeout error, resetting agent connection before each retry, because most common cause for timeout on getting parameter is communication problems. Long-running external parameters are bad anyway, because server uses one connection for reading data from agent, and parameters are read in order. So, if one parameter request takes too long, collection intervals for others will shift.

Best regards,
Victor

Ok, so it looks like agent returns something. I suppose that you don't have wc command, and so it just returns first line of dir output. Next question is why you don't see DCI value in management console. Can you post a screenshot of DCI configuration?

Best regards,
Victor

Try to run the following command on management server:

nxget <agent_ip> Test

What result you get?

Best regards,
Victor

Yes, I plan that next release will be 1.2.0. Current 1.1.x branch is stable enough to consider it new production version and drop 1.0.x branch.

Best regards,
Victor

Hi!

Not all. I think that NXSL script should not access external files or programs. If you need that in actions, you can run external script as an actiopn. But access to other objects are possible now. There are few functions which allows you to search for nodes and other type of objects.

Best regards,
Victor

Hi!

No, it isn't. Actually I don't touch this file for years. Many of featrures listed in that file already implemented, but some really important still not Currently I maintain my ToDo in internal Jira. Current list of open issues scheduled for 1.2.0 release looks like this:

Bug

    [NX-75] - Button "Test" is not working on DCI transformation property page
    [NX-80] - Reports not working on Windows
    [NX-89] - Cannot delete non-existent object from event processing policy

Improvement

    [NX-3] - Ability to set native agent port on node creation
    [NX-4] - Add support for INFORM messages in trap receiver
    [NX-7] - Apply policy to node by clicking on node and selecting policies from list
    [NX-18] - Improve dashboard configuration tools
    [NX-57] - Add certificate authentication to Java console
    [NX-85] - Implement drop column functionality for SQLite
    [NX-87] - Add web interface to WIndows installer

New Feature

    [NX-2] - Autodiscovery: user should be able to set default settings for discovered nodes (e.g. no agent, no snmp)
    [NX-5] - automatically create ChildStatus DCI when Network Service object created for Node
    [NX-10] - Use Spanning Tree data for network discovery
    [NX-33] - Implement configuration export in Java console
    [NX-35] - Implement concept of "normal" interface state
    [NX-38] - Add additional page for containers where threshold violations for underlying nodes are shown
    [NX-43] - Allow per-DCI SNMP version settings
    [NX-50] - Add possibility to add parameters and/or specify entry point in scripts called via %[] macro
    [NX-51] - Ability to copy/paste scripts in script library
    [NX-63] - Timed alarm acknowledgement
    [NX-71] - Add new policy type for distributing log parsers
    [NX-88] - Implement data export from log viewer
    [NX-90] - Implement alarm comments

Best regards,
Victor

I'm actually slowly moving towards ultimate goal - be able to do all this from NXSL scripts. Starting from 1.1.10 you already can run NXSL script as an action. Now I just need to add all necessary Create... functions.

Best regards,
Victor

Do this node have correct IP address on interface object too?

Hi!

From this log I can see that command executes for too long, and command execution timeout expires first. Default timeout is 2 seconds. You should increase both ExecTimeout parameter on agent and AgentCommandTimeout configuration variable on server.

Best regards,
Victor

Hi!

Because delta calculation is done by server after data obtained from node as part of DCI processing. When you do queryParameter call, it just reads raw value from end node - it is not related to any DCI. You either have to do delta calculation by yourself or use another API call to get last values of particular DCI.

Best regards,
Victor

Can you please provide as much information about this object as possible: IP address, operating system, device type, list of interfaces. etc.?

Best regards,
Victor

Hi!

The main problem with driver development is access to appropriate equipment for testing. Unfortunately I cannot have access to Cisco Nexus devices. If somebody can help with access to test equipment it will greatly improve and speed up driver development process. There are also plan to create framework for drivers written in NXSL - it probably will allow users to create drivers by themselves.

Best regards,
Victor

Hi!

Unfortunately there are no normal way to locate object by ID. You should manually check all objects with that name. Added that to feature requests.

Best regards,
Victor