Creating a Universal Script Execution Policy

A Universal Script Execution Policy allows you to run custom scripts across your devices to check compliance and remediate configuration drift. It’s ideal for enforcing security baselines, fixing misconfigurations, or applying small, controlled changes consistently across your environment.

• Go to Products → Patch Management → Policies → Create Policy.

• Select Universal Script Execution Policy.

• Policy Name: Enter the name for the policy (for example, Config-DisableSMB1).

• Description (Optional): Add a note about what the script enforces or verifies For example: “Disable SMB1 by setting registry value SMB1=0 ”

• Status: Choose Active (ready to run or schedule) or Inactive (saved but not active yet).

In the Device Targeting section:

• OS (Mandatory): Choose the operating system for this policy.
  - Windows: Only Windows devices will be targeted; scripts must be written in PowerShell.
  - Linux: Only Linux devices will be targeted; scripts must be written in Bash.

• Asset Groups: Select one or more asset groups (for example, Config-Test).

• Servers: Target specific servers.

• Endpoints: Target desktops or laptops.

• ASR Score: Optionally filter by Asset Security Risk score to prioritize higher-risk systems.

• Exclude Assets: Remove specific devices from the policy, even if they match other filters.

You can review the final scope of devices by clicking Preview Impacted Assets before saving.

If your remediation depends on a supporting file (for example, a module or script extension):

• Upload the file (≤ 1 GB).

• Ensure the filename does not contain spaces.

• The filename you upload must match the filename referenced in your script.

The Compliance Verification Script checks whether any action is required on the device.

• If remediation is needed, the script should exit with code 0. This signals that the Action Execution Script must be executed.

• If no remediation is needed, the script should exit with a non-zero code (commonly 1). This skips the Action Execution Script.

• Include clear output for auditing purposes (for example, “SMB1 enabled – remediation required” or “SMB1 already disabled – no action needed”).

The Action Execution Script runs only if the Compliance Verification Script exits with code 0, meaning remediation is required.

• The script should perform the corrective action (for example, disabling a service, changing a registry key, or updating a configuration).

• It must be idempotent — safe to run multiple times without causing errors or duplicate changes.

• On successful completion, the script should return exit code 0.

• If the remediation fails, return a non-zero exit code to flag the error.

Step 7: Set the Schedule & Retry Window

In the Schedule section, you define when and how often the policy will run:

• Select the Start Date and Time for the first run.

• Choose a Recurrence Pattern:

  • One-time (Does not repeat)

  • Daily

  • Weekly (on one or more days of the week)

  • Monthly (for example, first Friday of every month)
    

  • Annually (for example, run on 1st Aug every year)

  • Custom recurrence (for example, every 2 weeks on Wednesday)

• Set End Date and Time to stop the policy after a certain period.

You can use Preview Schedule to review the upcoming run times before creating the policy.
Optionally configure a Retry Window so offline devices still apply the change when they reconnect.

Step 8: Create and Save the Policy

• Click Create Policy to create and save the policy configuration

For safe adoption, apply the policy gradually:

• Test Group: A small IT or QA set, to validate script logic.




• Pilot Group: A limited group of devices (for example, 10%), to confirm consistent results.

• Production: Expand to all relevant systems once pilot outcomes are stable.

This staged approach helps minimize risk and ensures reliable compliance.