Using Scripts

Action1 allows you to use built-in and custom scripts in various scenarios:

• In a Run Script automation 
• In a custom data source 
• As an additional action for a software package

This section outlines the peculiarities and provides the recommendations you should consider when using the scripts in Action1.

Running Scripts

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 sections 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 (servershare) 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 (DOMAINComputerName$).

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.

Script Signing

Action1 enables IT teams to run PowerShell scripts to automate administrative tasks and collect endpoint data directly from reports.
To help organizations meet security and compliance requirements, Action1 now supports PowerShell Script Signing—an optional feature designed for environments that must ensure all PowerShell scripts are digitally signed in accordance with their security frameworks or compliance standards.

Supported scope

This feature is supported for custom PowerShell scripts and custom data sources.

Action1’s built-in scripts and data sources are processed as trusted sources and do not require signing with your certificate. 

Prerequisites

Before you start using this feature, ensure the following prerequisites are met for the target endpoints:

• Windows Management Framework 5.1 or later.
• A valid certificate. You can use:
  • • A self-signed certificate, or
    • A certificate obtained from the certification authority (CA)
• The certificate must be added to the Certificates store on each managed endpoint:
  • • For a self-signed certificate – add it to Trusted Publishers and Trusted Root
    • For a purchased certificate – add it to Trusted Publishers

To read more about certificate creation and PowerShell script signing, refer to Microsoft documentation.

How it Works

Before an Action1 agent executes custom PowerShell code (e.g., in custom scripts, data sources, additional actions in packages), it checks the code signature:

• If the signature is valid, the agent proceeds with code execution.
• If the signature is missing or invalid, the agent stops execution and logs an error message in the corresponding Automation History.

By default, this script signing feature is disabled. If your organization requires enforcing PowerShell script signing, please contact Action1 Customer Support (for paid customers) or submit a feedback form (for free users) to enable this feature.

Ensuring Script Formatting Integrity

When adding a new script manually (for example, by typing or pasting it in the wizard), consider that web browsers may alter certain formatting elements such as line breaks or spacing. For a signed script, this may lead to the script signature being rendered incorrectly.

To preserve signature integrity, use the Upload option when adding a script to the Script Library or configuring a Run Script automation, as well as when using it in a custom data source or additional action for a software package. Uploading the script as a file ensures formatting accuracy and signature validity.