Script FAQs
The following script types are supported where a handler is installed:
Windows: AMP, DOS Batch, JavaScript, Perl, PHP, PowerShell, Python, Ruby, VBS and CMD
Linux and macOS: Shell scripts and interpreted languages (Perl, PHP, Python, Ruby)
The check will be reported as passed when the return code from the script is 0. All other return codes will cause the check to be reported as failed.
We have reserved the exit codes 1 to 999 for use for the system scripts. As such we would suggest returning an exit code greater than 1000 in your scripts to ensure the text output is displayed correctly in the N-sight RMM UI.
Any information sent to standard out is uploaded and displayed on the N-sight RMM UI up to a maximum of 255 characters.
We support the upload of scripts up to a maximum of 65535 characters in size.
We support script outputs up to a maximum of 1000 characters.
You can use the Command Line to pass run time parameters to the script. The parameters that should be passed to the script depend on the script itself. For example, if running chksdsk, the disk to query may be passed as a command line parameter.
Scripts can only be managed by users who have Superuser, Administrator, a login with the required Custom Scripts permissions enabled, or the Agent Key (where access is enabled) level access to the N-sight RMM UI.
You can configure script checks to run as a 24x7 Check and/or a Daily Safety Check (once per day) and are added using the All Devices view.
The available 24x7 Check frequencies depend on the installed version of the Agent, generally this is every five or fifteen minutes on servers and every thirty or sixty minutes on workstations. But Windows Agent 10 introduced the additional thirty, sixty or one hundred and twenty minutes for servers and five, fifteen or one hundred and twenty minutes for workstations. Mac Agent 2.0 introduced an additional one hundred and twenty minutes frequency for workstations with five and fifteen minute monitoring included from Mac Agent 2.1.0.
scriptrunner.exe is part of the Agent and used to run the Automation Manager .amp scripts on the device.
Add the script as an Automated Task (Windows and Mac) and for the Frequency Method, select On Check Failure. When the Check fails, it will trigger the script. On Check Failure Automated Tasks can also be added when configuring a Check (where supported). For more information, see Run an Automated Task when a check fails.
This may be an issue with the script itself, caused by insufficient permissions as the credentials the Advanced Monitoring Agent service is set to run under are the same credentials that will be used to run the to the script or it may be an issue with the Script Host on the machine itself.
Depending on the scripting language used, you may need to install an interpreter on the device to allow it to run the script. The Agent itself does not include an interpreter.
#!/bin/bash
"Hello world"
exit 0
The maximum script timeout period is 3600 seconds. Although, we advise caution when adding a timeout of this length on servers because if the time taken to run all 24x7 checks exceeds the data overdue alert setting (default 1.5 times 24x7 monitoring frequency, so 7.5 minutes if using 5 minute monitoring) then a data overdue alert may be generated as all of the Checks have not complete in this period. If it is necessary to do this, then either increase the data overdue alert setting to 2.5 times (or more) 24x7 monitoring frequency or decrease 24x7 monitoring frequency to 15 minutes.
The Automated Tasks results are uploaded by the Agent the next time it communicates back to the N-sight RMM UI after the script runs, so there may be a delay between the Task completing on the device and the result appearing in the N-sight RMM UI.
This error may be caused if the script output contains special characters. For example, including "cls" in the script can add a special character to the output when run through cscript.
To prevent the removal of the leading 0 in arguments, the Windows Agent wraps any command that begins with 0 in \ so the full argument is preserved when executed or processed.
We provide the mechanism to run your own scripts on your servers and workstations; however, we are not responsible for custom scripts made or used in conjunction with this product. We are not liable for loss incurred from system, hardware or data loss. It is the customer/developer's responsibility to verify the integrity, actions and impact of any custom scripts.
What do you want to do?
- View the supported script types
- Check the requirements for returning Script results to the UI
- Determine whether the end user can interact with the script
- Parse Command Line Arguments to the script
-
Upload the Script to the N-sight RMM UI
- Deploy the Script on one of more devices
- Learn about the Windows Automation Manager
- View script Troubleshooting suggestions