Script Library
The Script Library provides ready-to-use PowerShell, Bash, and CMD scripts created and maintained by the Action1 engineering team. These scripts address common endpoint management tasks, for example, disabling USB ports, enabling or disabling Windows Firewall, and creating restore points. The library is regularly updated with new scripts.
In addition to the built-in scripts, you can create and store custom scripts specific to your needs. These scripts will be available to your Action1 Enterprise users with appropriate permissions.
Important! To work with the scripts, an Action1 role with sufficient permissions (Use Scripts or Manage Scripts) is required. See Permissions in Detail for more information.
Adding a New Script to the Library
Important! To add a new script, a user role with Manage Scripts permission is required.
- Navigate to Configuration | Script Library.
- Select + New Script to launch the wizard.
- On the General step, enter the script name and description.
- On the Script step:
-
- Specify the script language (PowerShell, CMD, or Bash).
- Enter your the script. To learn more about certain script types, refer to the “Examples” section below.
- If necessary, specify exit codes for your script. It is recommended that your script exits:
- with exit code 0 on success
- with non-zero exit code if it encounters any error. In this case, you can instruct Action1 to Initiate a reboot of the target endpoint.
- (for PowerShell and CMD scripts) In the Parameters section, click + Add parameter and specify the name, default value, and type for each parameter used in the script.
-
Tip: You can also provide new parameter values when configuring an automation to run this script.
NOTE: Configuration options for the Bash script parameters are not available within the wizard. You must specify parameter names and values in the script body. See the “Examples” section for details.
- On the Test step, verify the script operation. Select the target endpoint and click Run Script.
NOTE: If necessary, you can modify parameter values on this step.
- Wait for the script execution to complete. Verify the results and finish the wizard.
A new custom script will appear in the Script Library.
Editing or Deleting Scripts
- To modify a built-in script, you should Clone that script using the Actions menu next to it, and then edit the copy.
- To delete your custom script, select it in the Library and from the Actions menu, click Delete.
NOTE: Built-in scripts cannot be deleted, as they are maintained by Action1.
Running Scripts from the Library
To run the script on the target endpoints once or regularly on schedule, you should include it in the Action1 automation. Do any of the following:
- Navigate to the Script Library, select Actions next to the script you want to execute, and select Create Automation.
- Create a Run Script automation on the Automations page and configure it to use a script from the library.
For details on creating this type of automations, see Run Scripts on Remote Computers.
Action1 agent will execute the script using Local System (on the target Windows endpoint) or using root (on the target Mac endpoint).
Thus, it is recommended to avoid using custom scripts that require user input, profile-specific data, or network access with domain credentials. See the section below for details.
Constraints and Recommendations
When creating custom scripts, make sure your script does not request user input via GUI, does not try to access profile-specific data, or reach out to the network with domain credentials. These limitations apply due to the Local System / root account under which the scripts are executed on target endpoints.
Network access
Windows
When trying to reach out to the network, the Local System account does not authenticate as a domain user but uses the computer account that has no direct access to network resources. Therefore:
- Mapped drives (e.g.,
Z:) will be unavailable.
Mapped drives are linked to a user’s profile and logon session, while Local System is a built-in system account with its own context. - Access to UNC paths (
\server\share) may fail unless explicitly permitted.
If you need Local System to access the network share, then you should grant file and share permissions directly to the computer account (DOMAIN\ComputerName$).
NOTE: This has to be done for both permissions, since they work independently, restricting access.
Mac
The agent runs scripts on Mac endpoints using a root account that does not have access to user profiles. Thus, files stored in the user directories will be unavailable.
Interactivity
Consider that the SYSTEM context is non-interactive, that is, it cannot prompt for input, display messages, or use GUI-based tools. Thus, if the custom script needs GUI interaction, it will silently fail or hang.
Logging
Automation session logs are displayed in the Action1 console under Automations | History. To avoid excessive log messaging for scripts with verbose output, you can save the output to a dedicated file.
- Logging to the directories of specific Windows users (e.g.,
Documents) cannot be performed under Local System, as it cannot access user profile-based settings. Use system-wide file paths to store the log files, for example,C:\ProgramData,C:\Logs. - To troubleshoot possible issues at your Bash script execution on Mac endpoints, you can capture stdout/stderr diagnostic output and redirect it to a file.
Examples
The example scripts will send a ping to a certain host with a custom TTL value.
Example 1: PowerShell
- On the General step of the New Script wizard, enter:
-
- “Ping Host” as Name
- “Send a ping to the specified host.” as Description
-
- On the Script step, enter a sample PowerShell script:
# Make non-terminating errors throw:
$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $true try {
# Run ping command
ping -i $TTL ${Host Name}
# In case where native exit codes don't throw:
if ($LASTEXITCODE -ne 0) {
throw "ping failed with exit code $LASTEXITCODE"
}
}
catch {
exit 245
}
NOTE: If a parameter name contains a space, enclose it in brackets as ${param name}, e.g., ${Host Name}
- In the Parameters section, click +Add parameter and define TTL and Host Name parameters, providing their names, default values, and types:
- Set TTL type to Int and value to 64
- Set Host Name type to String and value to www.google.com
- If you want to initiate a reboot if the script fails, enter the exit code other than 0, e.g., 245.
- Finally, on the Test step, select the target endpoint where the script will be executed, and click Run Script.
Tip: For testing purposes, you can enter a nonexistent host name to receive the exit code 245 and see if the reboot is initiated.
After completing the test run, click Finish.
Example 2: CMD
To create a sample CMD script that will send a ping to a certain host with a custom TTL value:
- On the General step of the New Script wizard, enter:
-
- “Ping Host” as Name
- “Send a ping to the specified host.” as Description
-
- On the Script step, proceed with a sample CMD script:
@echo off - In the Parameters section, click +Add parameter and define TTL and Host Name parameters, providing their names, default values, and types:
- Set TTL type to Int and value to 64
- Set Host Name type to String and value to www.google.com
The script will refer to these parameters using
%param name%syntax. The parameter values will be passed to the script at run time as environment variables. - Finally, on the Test step, select the target endpoint where the script will be executed, and click Run Script. After completing the test run, click Finish.
Example 3: Bash
NOTE: Parameter configuration using the wizard is not supported for Bash scripts, so you should provide the required values within the script body.
To add a Bash script that will send a ping to www.google.com with a TTL=64:
- On the General step of the New Script wizard, enter:
-
- “Ping Host” as Name
- “Send a ping to the specified host.” as Description
-
- On the Script step, enter:
ping -i 64 www.google.com
NOTE: Reboot option is not supported for Bash scripts.
- Finally, on the Test step, select the target endpoint where the script will be executed, and click Run Script. After completing the test run, click Finish.
