Overview
A Deployment Policy in Zecurit defines how, when, and in what context a script runs on target endpoints. While the Script Repository stores your scripts, the Deployment Policy is what actually controls script execution, including scheduling, retry logic, logging, and network conditions.
Every script you want to deploy needs an associated Deployment Policy. Once created and published, the policy can be distributed to individual devices or device groups.
Navigate to Manage → Deployment → Deployment Policy → Add to create a new policy.
Step-by-Step: Creating a Script Deployment Policy
Step 1 : Policy Details
Policy Name (required) Enter a clear, descriptive name. Recommended format: [Platform]-[Script Purpose]-[Frequency]
Example: WIN-DiskCleanup-Weekly, MAC-SecurityAudit-Monthly
Category Select Script (not Software). This tells Zecurit you’re deploying a script from the repository rather than a software package.
Add Description (optional) Click “Add Description” to document the policy’s purpose, affected systems, change ticket reference, or approval details.
Step 2 : Script Selection
Select Script Choose a script from the dropdown list, which pulls from your Script Repository. Only scripts that match your environment will appear.
If the script you need doesn’t exist yet, click Add Script to open the script creation panel inline without leaving the policy creation flow.
Tip: Each Deployment Policy references one script. To run multiple scripts in sequence, either combine them into a single script or create separate policies and distribute them in order.
Step 3 : Execution Context
Run As : Choose how the script runs on the endpoint:
| Option | Description | Best For |
|---|---|---|
| System | Runs with full system/SYSTEM account privileges | Maintenance, patching, registry changes |
| Logged-in User | Runs as the user currently logged in | User-specific settings, mapped drives |
| Run as User | Runs as a specified user account | Service account scenarios, delegated tasks |
Security note: System context provides maximum privileges but cannot access user-specific resources (mapped network drives, user registry hives). Use “Logged-in User” when user context is required.
Step 4 : Logging
Capture Script Output
- Yes (default) — Captures stdout and stderr from the script for review in the device’s Deployments tab.
- No — No output is captured. Use this if the script output contains sensitive data you don’t want stored.
Max Output Size Set the maximum size of captured output. Default is 10 MB. Adjust downward for lightweight scripts generating short output, or upward for diagnostic scripts with verbose logs.
Step 5 : Deployment Handling Rules
Network Conditions
- Any Network (default) : The script deploys whenever the device is online, regardless of network type.
- LAN Only : Restricts script deployment to devices connected via local network. Useful for large payload scripts where bandwidth is a concern.
Retry on Failed Targets Toggle ON to automatically retry script execution on endpoints where it failed.
When enabled, configure:
- Retry Count — Number of retry attempts (e.g.,
1,2,3). Default is1. - Retry Interval — Time between retry attempts in minutes (e.g.,
15,30,60). Default is15 minutes. - Retry After Reboot — Toggle ON to retry execution after the device reboots. Particularly useful for scripts that require a reboot to complete (e.g., Windows Update application).
Step 6 : Schedule
Choose when the script should execute:
Deploy Immediately The script runs as soon as the device contacts the Zecurit server. The device does not need to be online at the moment of policy publication — it will execute on next check-in.
Schedule Deployment Sets a specific start date and time for execution. If the device is offline at the scheduled time, execution begins when the device next contacts the server.
- Start Date — Set the date and time using the date picker.
- Time Zone — Select the appropriate time zone (e.g.,
GMT +05:30 Asia/Kolkata).
Execute at Every Startup When checked, the script runs every time the device boots up. Useful for scripts that enforce configurations, check health on login, or collect startup metrics.
Tip: For scripts that should run once (e.g., one-time migrations), use Schedule Deployment with a specific date. For recurring maintenance (e.g., weekly cleanup), consider Execute at Every Startup or use recurring scheduling.
Step 7 : Notification
Notify administrators about deployment status Toggle ON to send email notifications to administrators when the deployment completes or fails. Off by default.
Step 8 : Save or Publish
| Action | Effect |
|---|---|
| Save as Draft | Saves the policy without activating it. Useful for work-in-progress policies pending review. |
| Publish | Activates the policy and makes it available for distribution to devices and groups. |
Note: Only Published policies can be associated with devices or groups. Draft policies are not distributed.
Use Case: Scheduled Weekly Disk Cleanup Policy
Scenario: Run a disk cleanup script every Monday at 2:00 AM across all Windows workstations.
- Go to Deployment Policy → Add.
- Policy Name:
WIN-DiskCleanup-MondayAM - Category: Script
- Select Script:
WIN-Cleanup-TempFiles-Weekly(from Script Repository) - Run As: System
- Capture Script Output: Yes | Max Output: 10 MB
- Network Conditions: Any Network
- Retry on Failed Targets: ON | Count: 1 | Interval: 30 min | Retry After Reboot: OFF
- Schedule: Schedule Deployment → Set to next Monday 02:00 AM → Time Zone: your local zone
- Click Publish.
Now associate this policy with your Windows device group (see Associate Policy to Devices/Groups →).
Use Case: Security Audit Policy (Run at Every Startup)
Scenario: Enforce a baseline security check every time a device boots.
- Policy Name:
WIN-SecurityBaseline-OnBoot - Category: Script
- Select Script: Your security audit script
- Run As: System
- Capture Script Output: Yes | Max Output: 5 MB
- Network Conditions: Any Network
- Retry: ON | Count: 2 | Interval: 15 min
- Schedule: Check Execute at Every Startup
- Click Publish.
Editing and Versioning Policies
After publishing a policy, you can edit it at any time. Each edit creates a new Version of the policy. When you re-distribute an updated policy to devices, the new version is pushed automatically. You can track which version is installed on each device in the device’s Deployments tab.