Available Tasks

Cancelling running tasks

Aborting a job target stops tasks that have not started immediately. When an endpoint task is already running, the target shows Cancelling until the endpoint confirms that the task has stopped.

While a target is cancelling:

• Ordyn keeps the cancellation request when the endpoint disconnects and retries it after the endpoint reconnects
• later primary work for the endpoint remains waiting so it cannot overlap the task being stopped
• tasks that support interruption are asked to stop promptly
• tasks that cannot be interrupted safely remain in Cancelling until they finish

The target changes to Aborted only after the running task is no longer active. A task stopped because its configured timeout elapsed follows the same process and finishes as Timed out.

Instructions

Intel AMT tasks

Intel AMT tasks operate supported, provisioned endpoints through their assigned AMT client. The endpoint agent may be offline.

Available tasks are:

• Inspect Intel AMT refreshes firmware state, capabilities, network, certificates, ACL summary, redirection, power, and drift data.
• Read Intel AMT power state returns the normalized and firmware power states.
• Run Intel AMT power action performs power on, graceful shutdown, AMT soft-off/S5, master-bus reset, or off-soft power cycle after checking advertised capabilities.
• Set Intel AMT one-time boot selects local disk, PXE, optical or redirected media, BIOS setup, or clears the override. It never changes persistent boot order.
• Mount Intel AMT media prepares and verifies an authorized read-only ISO or raw IMG and attaches it immediately for the duration of the media lease. It does not select a boot target or restart the endpoint.
• Wait on Intel AMT media waits for agent reconnect, an AMT power state, a fixed duration, or manual completion.
• Unmount Intel AMT media releases redirected media and its media lease.

Inspect Intel AMT can use the bounded trust-on-first-use identity check described in Detect an External Management Identity. A successful authenticated inspection can therefore identify a device that another environment now manages and expose the separate Adopt action. It does not adopt or otherwise change the firmware itself.

Graceful shutdown waits up to two minutes for the off state and never falls back to forced power-off. Reset and power-cycle tasks fail as ambiguous when their result cannot be proven. Cancelling a media workflow requests immediate unmount; the lease expiry remains the final cleanup. A consent-required mount enters Waiting for consent until an operator submits the firmware-displayed value or the consent deadline expires.

These tasks require normal Jobs permission and AMT Operator or AMT Administrator access on every target. Media tasks also require permission to use the selected file or OS image. A media workflow can run while one KVM or SOL session is active, but a second media workflow cannot. Power off, graceful shutdown, and power cycle end active redirection before applying the power request. KVM and SOL are interactive endpoint actions and are not available as job tasks.

Import Windows Firewall rules

Captures the Windows Firewall rules in the endpoint's local PersistentStore and stores them as a new active policy revision in Ordyn.

The task creates the endpoint firewall policy when one does not exist and is the supported way to initialize that policy. Every later successful run creates another revision. Capturing rules does not apply or otherwise change firewall rules on the endpoint.

Rules retain their Windows provider identity, so duplicate display names are supported. Predefined or protected rules are imported as enable/disable-only entries. The task succeeds with a warning when it finds rules that NetSecurity cannot safely round-trip; those entries remain visible and block enforcement until they are removed or simplified locally.

If the active policy changes while the task is collecting rules, the task fails without creating a revision. Run the task again to capture a current revision.

The result provides:

• result.endpoint_id
• result.policy_id
• result.revision_id
• result.revision_number
• result.rule_count
• result.unsupported_rule_count
• result.unsupported_rules
• result.content_hash
• result.managed_content_hash

This task requires a supported Windows agent. Group Policy, MDM, connection-security rules, and other externally managed firewall policy are outside the supported workflow.

Prompt for choice

Prompt for choice lets a job pause for a Windows user response and stores the selected value in job.vars.

In the editor, set the title, message, variable name, button list, default button value, and timeout.

Ordyn can optionally prompt signed-in Windows users before selected tasks continue.

What to expect:

• prompts can be shown in all active Windows sessions or in one selected Windows session
• if no matching interactive user session exists, Ordyn continues immediately with the normal non-interactive behavior
• supported outcomes are continue, postpone, and timeout
• when a user postpones a task, the same job target enters a waiting state and resumes later instead of creating a second job run

The step settings you will usually see are:

• Notify logged-in user
• Require user confirmation
• Countdown seconds
• Postpone durations

Run on another endpoint

Multi-endpoint jobs can let individual endpoint-local steps run on a fixed execution endpoint instead of the job target endpoint. This is useful for handoff workflows, for example generating a file on a domain controller, collecting it as a job artifact, and uploading it to the original client endpoint in a later step.

Important behavior:

• the job must have Allow individual steps to run on another endpoint enabled
• the selected execution endpoint must be in the same tenant as the target endpoint
• the user running the job needs normal job and instruction permissions for both the target endpoint and the fixed execution endpoint
• endpoint template values such as {{ endpoint.hostname }} still refer to the original job target endpoint, not the fixed execution endpoint
• self-service jobs can use this feature when the job definition already contains the fixed execution endpoint

Supported step types are endpoint-local reads, writes, inspections, inventory collections, script runs, artifact collection, service/process actions, Docker and Microsoft Hyper-V actions, endpoint power actions, Ordyn Agent log and database diagnostic exports, and Windows Update log exports.

Unsupported step types include software/package deployment, OS installation, update installation, preboot/PXE orchestration, agent update/reinstall, desktop/user-interaction tasks, server-side tasks, SNMP tasks, and control-flow tasks. These steps always run against the normal target endpoint or the server-side context they were designed for.

Disable or enable a configuration profile

Disable configuration profile stops an effectively assigned profile from running on the current job target. An optional reason is stored with a new disable record. Enable configuration profile removes the matching disable record so the profile's effective behavior and automations can resume.

Both tasks run on the Ordyn server and do not require the endpoint agent to be connected. They always use the current job target; a fixed or templated execution endpoint is not supported. The selected profile must still be effectively assigned and compatible with the endpoint when the task reaches it. The tasks can be used at the top level, in branches, and in loops, and they follow the configured task error behavior when validation fails.

A repeated disable or enable is a successful no-op. The structured result exposes the outcome, configuration profile ID, profile type, disable scope, requested disabled state, and whether the stored state changed. Profile types with one effective winner use a type-wide disable scope. Other types use a profile-specific scope.

Intel AMT profiles are supported. Disabling one revokes unused session grants and stops managed AMT communication without deprovisioning firmware. Enabling one applies the normal AMT readiness guard. Successful no-op requests still run the applicable AMT synchronization and safety work.

Collect artifacts

Collects files as task artifacts from either the connected endpoint agent or an active preboot session, depending on job routing. To configure it, set the artifact paths to collect.

Malware scanning is required by default. A collection step can instead mark its output as coming from a trusted job source. Those artifacts are recorded as Skipped, trusted source and can be placed or folder-synced by later job steps without waiting for a scan. This exception applies only to artifacts produced by that collection step. Use it only when both the producing endpoint and workload are trusted.

Choose No artifact expiry, 1 hour, 1 day, 7 days, or 30 days. The expiry period begins when Ordyn stores the artifact. No artifact expiry retains it until its parent job run is pruned. Sensitive artifact kinds can impose a shorter fixed maximum lifetime.

Endpoint job scripts can write logs and diagnostic files to {{ job.artifact_directory }}. Use {{ job.log_file }} for a default per-task log file, or collect multiple files later with a glob such as {{ job.artifact_directory }}\*.log.

Use {{ job.workspace }} for files that later endpoint tasks need. Endpoint scripts start in this shared workspace and also receive its path through ORDYN_WORKSPACE.

Artifact paths also support platform environment variables. On Windows, use CMD-style variables such as %TEMP%\DCU_ApplyUpdates.log and %ProgramData%\Vendor\*.log. On Linux, use shell-style variables such as $TMPDIR/ordyn.log or ${TMPDIR}/ordyn/*.log. Variables are expanded by the agent before glob matching.

Environment-variable expansion uses the artifact collection runtime environment. On Windows this is the agent service environment, not necessarily the Windows execution context used by an earlier script step. For example, if a script runs as the Ordyn installation user, %TEMP% in a later collect-artifacts step may still resolve to the service/SYSTEM temp directory. Prefer {{ job.artifact_directory }} for logs or files that need to be collected reliably across execution contexts.

Control flow

If branch

Evaluates a condition and executes either the then or else branch. To configure it, build the condition in the visual editor or raw expression editor, then add the then and else branches.

String conditions support equals, does not equal, contains, does not contain, is empty, and is not empty. Conditions can also check whether a persistent variable has a direct endpoint override or any effective override for the endpoint currently running the job. See Variables for the expression syntax and override modes.

Sleep

Pauses this endpoint job for the configured number of seconds, then continues with the next step. To configure it, set the pause duration in seconds.

Set job variable

Stores a runtime value under job.vars for later steps and branches. To configure it, set the variable name and the expression that should populate job.vars.

Set environment variable

Sets or removes an environment variable for subsequent inline and saved script steps on the same job target.

Choose Set, enter a portable environment variable name, and provide a templated value. Choose Unset to remove a value set by an earlier task. Names beginning with ORDYN_ are reserved for Ordyn-provided script context.

The value is scoped to the current target. It does not change the machine-wide environment or persist after the target finishes. See Job Variables for persistent, inherited, and prompted values available through vars.*.

Set variable override

Creates, updates, nulls, or deletes one persistent variable override on a selected scope. The supported destinations are a tenant, endpoint folder, group, or endpoint. To configure it, choose the scope, operation, target mode when needed, and the value expression when you are setting a value.

Unassign this job from endpoint

Removes only the direct endpoint assignment for this job on the current endpoint.

Disable this job on endpoint

Blocks future runs of this job on the current endpoint from all assignment sources.

End job

Ends the current endpoint target immediately. To configure it, choose whether the target should finish as aborted or succeeded, and optionally add a message.

Loops

For each

Iterates over an expression result and runs the body once per item. To configure it, set the items expression, item variable, optional index variable, and maximum iteration count, then add the body steps. Replay GUI automation tasks are not supported inside loop bodies. Keep GUI replay at top level or inside branches outside the loop.

While loop

Re-evaluates a condition and repeats the body until it becomes false or the maximum iterations is reached. To configure it, set the condition, optional maximum iteration count, and the body steps. Replay GUI automation tasks are not supported inside loop bodies. Keep GUI replay at top level or inside branches outside the loop. The condition editor supports the same string operators and variable override checks as If branch.

Job composition

Run endpoint job

Starts one child run of a selected endpoint job and waits for that run to finish. Use this task to reuse an endpoint workflow inside a larger endpoint or infrastructure job.

Choose one target source:

• Current endpoint uses the parent endpoint and is available in endpoint jobs.
• Endpoint groups combines the current members of one or more groups and removes duplicates.
• Expression accepts an endpoint UUID, an endpoint object, or an array containing either form.

The endpoint set is resolved and fixed when the task starts. Configure the child concurrency to limit how many targets can execute at once, or leave it empty to use the child job's default. The child job resolves its own endpoint and job-level variables. Prompt-enabled fields are not interactive here, so every required child variable must already have an effective persistent value.

Choose whether an empty target set fails the task or succeeds without starting a child run. The task's normal error behavior controls whether the parent continues after a failed, timed-out, or aborted child run.

The run history links the parent task to its child run and the child run back to its parent. Aborting the parent cascades cancellation to an active child run.

Wait for endpoint set state

Waits until every endpoint in a resolved and fixed target set reaches the selected relay-connected or relay-disconnected state. It supports the same current endpoint, endpoint group, expression, and empty-set choices as Run endpoint job.

Use this task before a dependent stage when connectivity is a prerequisite. For Hyper-V workflows, {{ endpoint.hyperv_guest_endpoint_ids }} resolves to the identified guest endpoints from the host's latest Hyper-V inventory.

Job references cannot form a cycle, and nested child-job execution is limited to eight levels.

Messaging

Log message

Renders a message from the current task context and stores it with the task in the job history. Use it to record operator context, selected values, or diagnostic checkpoints without running a script on the endpoint.

The message supports the same template paths as other job fields, including values such as {{ endpoint.hostname }}, {{ job.vars.release }}, earlier step results, and {{ loop.vars.item }} inside a loop. A multi-endpoint job renders and stores a separate message for each target. A loop renders a separate message for each iteration.

Important behavior:

• an unknown template path is rendered as null and does not fail the task
• a message that renders only whitespace is stored as [empty]
• output larger than 64 KiB is shortened safely and ends with [truncated]
• exact values of configured secret variables and secret runtime values are stored as [REDACTED]
• rendered messages are available in the administrative job history; the endpoint self-service portal shows the step status but not the rendered text

Send email

Sends a templated email through the configured SMTP server. To configure it, set the recipient lists, subject, body, and whether the primary user should be included.

Agent management

Update Ordyn Agent

Updates the Ordyn Agent to a selected release or the latest compatible release at runtime. To configure it, select a specific agent release or leave it on the latest compatible release.

Reinstall Ordyn Agent

Reinstalls the Ordyn Agent from a selected release or the latest compatible release at runtime. To configure it, select a specific agent release or leave it on the latest compatible release.

Export Ordyn Agent logs

Exports the retained Ordyn Agent event log to a job artifact. To configure it, choose whether to export operational or audit logs.

Export Ordyn Agent database diagnostics

Collects diagnostic information from the Ordyn Agent database.

To configure it, choose a database export:

• Sanitized summary creates a JSON job artifact and includes the summary in the task result. It reports database health, storage use, and aggregate record counts while omitting runtime payloads and identifiers. This is the default and remains available with the job's normal artifacts.
• Raw SQLite snapshot creates a consistent SQLite job artifact containing the Agent's diagnostic database state. The snapshot can contain endpoint identifiers, job and instruction state, file paths, and other sensitive operational information. Raw snapshots expire after seven days.

Both modes require a cache node assigned to the endpoint's tenant or folder so the Agent can upload the artifact.

Download artifacts from the task in Reporting > Job Runs. Treat raw snapshots and any downloaded copies as sensitive data.

Configuration

Read key/value file value

Reads a key from a dotenv or INI file and exposes the result for later conditions. To configure it, set the file path, file format, and key to read.

Read behavior:

• reading a missing file fails the task
• reading a missing key succeeds with result.found = false
• if the same key appears multiple times, Ordyn uses the last matching value and reports the total Matched key count

Write key/value file value

Sets, updates, clears, or deletes a key in a dotenv or INI file. To configure it, set the file path, file format, key, write operation, and value when you choose Set or Update existing.

Write behavior:

• set
  • creates the key when it is missing
  • replaces the key when it exists
• update
  • replaces the key only when both the file and key already exist
  • succeeds without writing when the file, INI section, or key is missing
• null
  • keeps the key but writes an empty value such as KEY=
• delete
  • removes the matching key entries entirely
• only update avoids creating a missing file, section, or key

When duplicate keys exist, write operations canonicalize the target key:

• read still uses the last match
• write removes duplicate matching entries and reports that in Deduplicated key count

One example flow:

1. read APP_ENV from /etc/app.env
2. store the read Value in job.vars.app_env
3. branch when Found is Yes
4. if the key is missing, write APP_ENV=production

Another example:

1. write to /etc/app.ini
2. format ini
3. section app
4. key enabled
5. operation set
6. value true

Filesystem

Inspect file

Checks whether a file exists and returns its metadata. To configure it, set the file path.

Read file

Reads the content of a text file from the endpoint filesystem. To configure it, set the file path. You can also choose the encoding and limit how many bytes to read.

Write file

Creates or overwrites a file with inline content on the endpoint filesystem. To configure it, set the file path, content, encoding, overwrite behavior, and whether Ordyn should create the parent folder. Use Place file on endpoint when the source is a stored Ordyn file, endpoint file, or previous task artifact.

Place file on endpoint

Places a stored file onto the endpoint filesystem. To configure it, set the target path, file source, optional file name, overwrite behavior, and parent-folder handling.

Supported file sources:

• Ordyn file
  • places a global Ordyn-managed file onto the endpoint
• Endpoint file
  • places a file retrieved from a selected endpoint
• Software package
  • places the package's primary file or one of its staged install archives
• Previous task artifact
  • places a file collected by an earlier task in the same job target

For a software package source, select the package and then select its primary file or a staged install archive. A staged archive is placed as a complete ZIP; use a later extraction step when its contents are needed. Ordyn resolves the current file in the selected package location when the task runs, so content published later to the same primary location or archive slot is used automatically.

Enable Render selected file as template only for valid UTF-8 text files of up to 10 MiB. Files placed without this option are copied verbatim.

When the selected source is not ready yet, the task stays in preparing state instead of failing immediately. This includes files that are still waiting for malware scanning and files that still need to be synchronized to the endpoint's cache node.

The task continues once:

• the malware scan result is clean
• the selected cache node has the file
• the agent receives the signed download URL

The task fails if the malware scan reports an infected or failed result, or if the normal job/task timeout expires before the file becomes usable.

The endpoint verifies the exact size and signed SHA-256 checksum before the file is placed.

When multi-endpoint job mode is enabled, Run on endpoint controls where the file is placed. Previous task artifact still refers to an earlier artifact from the same job target, so this can be used for flows where one step collects a generated file from another endpoint and a later placement step writes it onto the original target endpoint.

Delete file

Deletes a file from the endpoint filesystem. To configure it, set the file path.

Retrieve file

Copies one or more files from the endpoint into Ordyn files. To configure it, set one or more source paths and an optional archive name.

Each retrieved file is limited to 15 GiB by default.

Inspect directory

Checks whether a directory exists and returns its metadata. To configure it, set the directory path.

List directory

Lists the contents of a directory on the endpoint filesystem. To configure it, set the directory path and, if needed, recursive listing, maximum depth, and entry limits.

Create directory

Creates a directory on the endpoint filesystem. To configure it, set the directory path and whether recursive handling is allowed.

Delete directory

Deletes a directory from the endpoint filesystem, optionally recursively. To configure it, set the directory path and whether recursive handling is allowed.

Retrieve directory

Archives a directory on the endpoint and stores it in Ordyn as a zip file. To configure it, set the directory path and an optional archive name.

Directory retrieval is limited by entry count, path depth, source size, and completed ZIP size. Symbolic links are not included.

Registry

Inspect registry key

Checks whether a Windows registry key exists and reports its metadata. To configure it, set the registry hive and path.

List registry key

Lists subkeys and values under a Windows registry key. To configure it, set the registry hive and path.

Create registry key

Creates a Windows registry key if it does not already exist. To configure it, set the registry hive and path.

Delete registry key

Deletes a Windows registry key, optionally recursively. To configure it, set the registry hive and path, and choose whether recursive deletion is allowed.

Inspect registry value

Checks whether a Windows registry value exists and reports its metadata. To configure it, set the registry hive, key path, and value name.

Read registry value

Reads a Windows registry value from the endpoint. To configure it, set the registry hive, key path, and value name.

Write registry value

Creates or updates a Windows registry value on the endpoint. To configure it, set the registry hive, key path, value name, value type, and value data.

Delete registry value

Deletes a Windows registry value from the endpoint. To configure it, set the registry hive, key path, and value name.

Retrieve registry key

Exports a Windows registry key into Ordyn as a .reg file. To configure it, set the registry hive, key path, and an optional file name for the export.

System

Reboot endpoint

Requests a reboot on the target endpoint.

When another task enables automatic reboot handling, the visible runtime reboot sequence uses that task's configured error behavior. A failed reboot wait is reported on the originating task, and the remaining automatic steps in that sequence are skipped. See Step error behavior for the three available outcomes.

Shutdown endpoint

Requests a shutdown on the target endpoint.

Linux

Install APT updates

Installs applicable package updates on Debian-style Linux endpoints.

Configure:

• the upgrade mode: Upgrade runs apt-get upgrade --with-new-pkgs, while Full upgrade runs apt-get dist-upgrade
• recovery behavior: None, Repair on error, or Always repair first
• release-information change handling
• whether to run apt-get autoremove -y after a successful upgrade

APT runs noninteractively and preserves existing configuration files when packages prompt about replacements. Recovery uses dpkg --configure -a followed by apt-get -f install -y. The endpoint variable linux.apt.releaseinfo_change_policy can override the configured release-information policy at runtime.

Endpoints marked as an Ordyn server host, edge host, or hypervisor host use durable result handling automatically.

Automatic reboot orchestration is disabled by default. When enabled, Ordyn can restart the endpoint only after APT reports that a reboot is required. The generated job steps wait for the relay disconnect, relay reconnect, and a changed boot identity before continuing. Reporting the changed boot identity completes that wait immediately.

Windows

Export Windows Update log

Generates the full readable WindowsUpdate.log from the Windows Update traces currently available on the endpoint and returns it as a job artifact.

The export does not force Windows to flush in-memory traces first. As a result, the newest Windows Update activity may not appear in the generated file yet.

Install Windows updates

Installs applicable updates offered by Windows Update without requiring a ring approval.

Choose an update source:

• Default source uses the source configured by the endpoint's effective Windows Update policy
• Microsoft Update scans Microsoft Update for this task
• WSUS uses the endpoint's configured WSUS service and fails when WSUS is not configured

Select at least one classification. Drivers includes automatic and optional Windows Update driver offers, including firmware delivered through the driver channel. Other classifications select software updates. An optional product filter further restricts the offers.

Windows makes the final applicability decision for the endpoint. An update that matches the job filters but is not offered as applicable on that endpoint is not installed.

The agent starts installation through the Windows Update API and waits for a terminal result. Configure the task timeout for the expected scan, download, and installation duration. If the timeout expires first, Ordyn times out the step and requests cancellation. Windows servicing work that Windows has already accepted may continue independently.

Jobs with durable result spooling enabled can retain a completed update result locally and retry delivery during the configured recovery window. The job target timeout remains the outer deadline.

Automatic reboot orchestration is disabled by default. When enabled, Ordyn restarts only after Windows reports that a reboot is required, waits for the relay disconnect, relay reconnect, and a changed boot identity, checks Windows Update readiness, and follows the selected one-reboot or rerun-until-clean strategy. Relay reconnection alone does not prove that a new boot occurred.

Install approved Windows updates

Installs the exact Microsoft Update revisions approved for each endpoint's effective Windows update ring. The job task does not select a ring.

Choose an update source:

• Windows Update contacts Microsoft Update and downloads the exact approved revisions directly. This is the default and does not use WSUS or the update source configured by endpoint policy.
• Ordyn repository installs imported content through the endpoint's assigned Cache Node. This source requires current Offline catalog inventory, a catalog no more than 45 days old, and files imported by the Download approved Windows updates infrastructure task.

Use the optional classification and product filters to limit the approved revisions installed by this job. Values within a filter are combined as alternatives, while populated classification and product filters must both match.

With Windows Update, leave classifications empty to include every approved classification. For example, a frequent Microsoft Defender job can select the Microsoft Defender Antivirus product and optionally select Definition Updates when the job should install only Defender definition updates.

The effective ring must be enabled. The task fails without installing updates when the endpoint has no effective ring or an equal-precedence ring conflict exists. A single job can target endpoints from multiple rings because Ordyn resolves the effective ring separately for every endpoint. Eligible and rejected revisions are excluded.

The Windows Update source can install applicable revisions discovered through online or offline inventory. The Ordyn repository source supports Security Updates, Service Packs, and Update Rollups. Definition updates, drivers, firmware, feature packs, tools, general updates, and upgrades require Windows Update.

For repository installations, Ordyn synchronizes the required verified files to the endpoint's assigned Cache Node. In the default automatic mode, cumulative updates with one unambiguous matching MSU package are installed with Windows servicing. Other update shapes use the offline catalog and Windows Update cache. A single task can use both methods for different approved revisions.

The system variable windows.update.ordyn_repository_install_strategy controls this behavior for each endpoint:

• leave it unset or set it to automatic to select the supported method for each approved revision
• set it to copy_to_cache to require the offline-catalog and Windows Update cache method for every revision

Ordyn does not retry a failed direct MSU installation through the Windows Update cache automatically. The task reports the failed revision and its servicing error.

The task details show the configured filters and list the matching approved update names sent to the endpoint. After completion, they list installed updates and any updates that failed to download or install. A failed entry includes the Windows error code when available.

When Windows offers none of the approved revisions as applicable, the task succeeds without installing anything and shows the requested, discovered, and matched counts. This commonly means the revision was superseded, already satisfied, or not applicable to that endpoint at execution time.

Ring membership does not verify Windows Update policy. Configure and assign a Windows Update Policy separately when automatic or interactive installation outside the ring workflow must be disabled.

Automatic reboot orchestration is disabled by default. When enabled, it uses the same Windows readiness and rerun behavior as Install Windows updates. Leave it disabled when restarts must be handled only by users or Windows.

See Windows Updates for repository content, ring assignments, policy setup, approvals, and scheduling.

Download offline Windows update catalog

Downloads Microsoft's offline scan catalog on a Runner and imports it into Ordyn.

Select a Runner pool in the job overview and schedule the task about once every seven days when offline inventory or the Ordyn repository installation source is used. Offline inventory and repository installation reject catalogs older than 45 days.

Download approved Windows updates

Downloads missing content for revisions that are approved in enabled Windows update rings and reported by current offline endpoint inventory.

The Runner downloads content from Microsoft and stages it through its pool Cache Node. Ordyn imports each file and submits it for malware verification. Files that are already imported are skipped.

Refresh Intel ODCA trust

Downloads the Intel ODCA root, intermediate certificate, and revocation list on a Windows or Linux Runner. The task is available only in infrastructure jobs.

The Runner requires outbound HTTPS access to tsci.intel.com. Ordyn validates the fixed source locations, pinned Intel root, certificate chain, signatures, validity period, and revocation list before activating the complete snapshot. A failed task leaves the previous current snapshot unchanged.

See Intel AMT Infrastructure for scheduling, snapshot status, and offline import.

Inventory

Collect software inventory

Refreshes the installed software inventory.

Collect hardware inventory

Refreshes the hardware inventory.

Collect firmware settings inventory

Reads supported firmware settings without changing them. Select the firmware vendor when configuring the task. Dell firmware on Windows endpoints is currently supported.

The inventory includes supported values for Secure Boot, Wake-on-LAN mode, virtualization, IOMMU, TPM, capsule firmware updates, BIOS downgrade permission, and AC power recovery. Settings that the device does not expose are omitted and reported as warnings rather than failing the complete inventory.

The endpoint overview shows the number of detected settings in the Firmware row below Directory & Users. Select the count to view the exact reported values.

Collect service inventory

Refreshes the service inventory.

Collect service inventory can also expose whether any discovered service needs a restart, which is useful when Linux endpoints report restart-needed services through needrestart.

One example flow:

1. run Collect service inventory
2. add an if task
3. select the inventory step as the source task
4. select Any service restart required
5. check whether it Is Yes
6. place the follow-up restart or remediation task in the then branch

Collect process inventory

Refreshes the running process inventory and stores a current process snapshot for later inspection.

Typical fields include:

• PID
• parent PID
• process name
• status
• user
• executable path
• command line
• memory and CPU information when available

Collect system status

Collects a fresh system-status snapshot from the endpoint and makes it available to later job steps.

On Windows Server, the agent also records installed core server roles from Get-WindowsFeature. Ordyn stores canonical role keys such as hyperv, ad_ds, dns, dhcp, iis, ad_cs, wsus, and file_services; dynamic endpoint groups can match them with the Windows server role system field.

Use it when later tasks need current device state instead of the last cached system-status snapshot shown in the UI.

Typical uses:

• check whether a Windows laptop is on AC power before a disruptive task
• branch when a reboot is already required
• inspect the currently logged-in user or memory values in a later condition
• branch on a specific filesystem's free or used space by entering its mount point or drive letter
• gate a Windows in-place upgrade on power state

One example flow:

1. run Collect system status
2. add an if task
3. select the status step as the source task
4. select Power source
5. check whether it Is ac
6. place the Windows upgrade task in the then branch

For filesystem conditions, select a filesystem metric such as Filesystem used percent and enter a mount point or drive letter such as C:, C:\, /, or /var. The system-status result exposes every filesystem by a normalized mount key, for example result.filesystems_by_mount.c.used_percent.

One example flow:

1. run Collect system status
2. add an if task
3. select the status step as the source task
4. select Power source
5. check whether it Is ac
6. place the Windows upgrade task in the then branch

Collect APT update inventory

Refreshes the installed and available APT package update inventory on Debian-style Linux endpoints. This task has no configurable update source or Windows filters.

Collect Windows update inventory

Refreshes installed and missing Windows Update inventory.

Choose Default source, Offline catalog, Microsoft Update, or WSUS, then select at least one classification. Optional product filters restrict software offers further.

Online sources return the updates Windows offers under the endpoint's effective Windows Update policy. Quality-update deferral can temporarily exclude newly released updates. The task reports the policy with its inventory result.

Offline catalog uses the latest verified catalog imported the Download offline Windows update catalog infrastructure task. Ordyn synchronizes the catalog through the endpoint's assigned Cache Node. The task fails when no current catalog is available. Catalogs older than 45 days are not used. Offline inventory supports Security Updates, Service Packs, and Update Rollups.

The offline catalog contains only the update categories published by Microsoft for offline scanning. It does not provide the complete Microsoft Update catalog, definition updates, drivers, firmware, feature packs, tools, general updates, or upgrades. Select Default source, Microsoft Update, or WSUS to inventory those classifications.

When WSUS is selected, you can require the task to fail if the endpoint is not configured for WSUS. Ring approvals can use only revisions and applicability details that endpoints have reported through this inventory task.

Collect Docker inventory

Refreshes Docker inventory from the endpoint.

The inventory includes:

• runtime and daemon metadata
• containers
• images
• volumes
• networks
• detected Docker Compose projects

Docker inventory and Docker management are currently Linux-only in the agent. The agent connects to Docker through the configured Docker connection. By default this is the Unix socket /var/run/docker.sock; the agent configuration can also point at a TLS Docker endpoint.

See Docker Inventory for the endpoint Docker tab.

Start Docker container

Starts a Docker container on the endpoint. To configure it, select a container from the inventoried container combobox. The job stores and dispatches the Docker container identifier shown by inventory.

Stop Docker container

Stops a Docker container on the endpoint. To configure it, select a container from the inventoried container combobox.

Restart Docker container

Restarts a Docker container on the endpoint. To configure it, select a container from the inventoried container combobox.

Tail Docker container logs

Reads the latest Docker container log lines and stores them in the task result. To configure it, select a container and optionally change the line count. The default is 200 lines.

Docker Compose up

Runs docker compose -f <compose file> ... up -d --remove-orphans on the endpoint. To configure it, provide one or more compose file paths that already exist on the host. Enable Force recreate containers to add --force-recreate.

Docker Compose down

Runs docker compose -f <compose file> ... down --remove-orphans on the endpoint. To configure it, provide one or more compose file paths that already exist on the host.

Docker Compose stop

Runs docker compose -f <compose file> ... stop on the endpoint. To configure it, provide one or more compose file paths that already exist on the host.

Docker Compose restart

Runs docker compose -f <compose file> ... restart on the endpoint. To configure it, provide one or more compose file paths that already exist on the host.

Docker Compose update

Runs a pull-and-recreate flow for a compose project on the endpoint:

1. docker compose -f <compose file> ... pull
2. docker compose -f <compose file> ... up -d --remove-orphans

To configure it, provide one or more compose file paths that already exist on the host. Compose file paths support job templating. Enable Force recreate containers to add --force-recreate to the up command.

Update Ordyn API

Updates the Ordyn API containers and updates the database. This Linux task is available in endpoint jobs and always runs on the job target endpoint. It cannot use Run on another endpoint.

The editor provides these settings:

• Compose file paths, defaulting to /opt/ordyn-compose/api/compose.yml
• Working directory, defaulting to /opt/ordyn-compose/api
• Force recreate containers, disabled by default

If a cancellation or failure occurs after the update starts, the API or database may be partially updated; inspect the failed stage, correct the problem, and run the task again.

The endpoint retains the completed result for delivery for up to one hour when the API update temporarily interrupts its connection to Ordyn. The result exposes:

• result.outcome: updated, failed, or cancelled
• result.failed_stage: compose_update, stabilization_wait, database_migrate_seed, or null
• result.partial_update and result.cancelled
• result.stages.compose_update
• result.stages.stabilization_wait
• result.stages.database_migrate_seed

Each stage contains status, exit_code, stdout, stderr, and duration_seconds. A stage status is succeeded, failed, cancelled, or skipped. Exit code and duration can be null when they do not apply, and command output can be empty. If cancellation interrupts the update before the endpoint records its stage result, the individual stage fields and failed_stage are null, while cancelled and partial_update identify the outcome conservatively.

These normalized result fields are available in the guided If branch editor for later steps in the same job.

The built-in Job Designer and Platform Admin roles include permission to use this job step.

See Endpoint infrastructure roles.

Docker Compose exec

Runs a non-interactive command inside a service from a Docker Compose project:

docker compose -f <compose file> ... exec -T <service name> sh -lc <command>

To configure it, provide:

• one or more compose file paths that already exist on the host
• the compose service name
• the shell command to run inside the service container

The compose file paths, service name, and command support job templating. The command output is stored on the job step as stdout and stderr.

Compose management intentionally does not upload or edit compose files. Store and maintain the compose file on the endpoint itself, then use the job step to operate it.

To refresh every Compose project in the latest stored Docker inventory, loop over endpoint.docker.compose_projects. The example requests a new inventory report first, skips configured working directories, updates known dotenv tag keys, and then refreshes each project. Use a JSON array variable such as vars.refresh_compose_projects_ignore_list when some project working directories should be skipped.

[
  {
    "id": "collect-docker-inventory",
    "name": "Collect Docker inventory",
    "kind": "instruction",
    "capability": "docker.container.inventory",
    "payload": {},
    "error_behavior": "stop_and_fail",
    "expires_in_seconds": 900
  },
  {
    "id": "refresh-compose-projects",
    "name": "Refresh Docker Compose projects",
    "kind": "for_each",
    "payload": {
      "items_expression": "endpoint.docker.compose_projects",
      "item_name": "compose_project",
      "index_name": "compose_project_index",
      "max_iterations": 100
    },
    "body_tasks": [
      {
        "id": "skip-ignored-compose-projects",
        "name": "Skip ignored Compose projects",
        "kind": "if",
        "payload": {
          "condition": "!contains(vars.refresh_compose_projects_ignore_list, loop.vars.compose_project.working_dir)"
        },
        "then_tasks": [
          {
            "id": "write-compose-image-versions",
            "name": "Write Compose image versions",
            "kind": "for_each",
            "payload": {
              "items_source": "expression",
              "items_expression": "loop.vars.compose_project.image_updates",
              "item_name": "image_update",
              "index_name": "image_update_index",
              "max_iterations": 100
            },
            "body_tasks": [
              {
                "id": "write-updateable-compose-tag",
                "name": "Write updateable Compose tag",
                "kind": "if",
                "payload": {
                  "condition": "loop.vars.image_update.compose_tag.is_updateable == true"
                },
                "then_tasks": [
                  {
                    "id": "update-compose-tag-variable",
                    "name": "Update Compose tag variable",
                    "kind": "instruction",
                    "capability": "config.write_key_value",
                    "payload": {
                      "path": "{{ loop.vars.compose_project.working_dir }}/.env",
                      "format": "dotenv",
                      "key": "{{ loop.vars.image_update.compose_tag.variable_name }}",
                      "operation": "update",
                      "value": "{{ loop.vars.image_update.newest_available_tag }}",
                      "allow_duplicate_keys": false
                    },
                    "error_behavior": "stop_and_fail",
                    "expires_in_seconds": 900
                  }
                ],
                "error_behavior": "stop_and_fail",
                "expires_in_seconds": null
              }
            ],
            "error_behavior": "stop_and_fail",
            "expires_in_seconds": null
          },
          {
            "id": "update-compose-project",
            "name": "Update compose project",
            "kind": "instruction",
            "capability": "docker.compose.update",
            "payload": {
              "compose_file_paths": [
                "{{ loop.vars.compose_project.config_files }}"
              ],
              "working_directory": "{{ loop.vars.compose_project.working_dir }}"
            },
            "error_behavior": "stop_and_fail",
            "expires_in_seconds": 1800
          }
        ],
        "error_behavior": "stop_and_fail",
        "expires_in_seconds": null
      }
    ],
    "error_behavior": "stop_and_fail",
    "expires_in_seconds": null
  }
]

The ignore-list variable contains exact Compose project working directory paths:

[
  "/opt/local-build",
  "/opt/test-stack"
]

When the ignore list is empty, every detected Compose project is refreshed.

The example explicitly chooses the project .env file and updates only tags that map safely to one environment variable. Change the path when a project uses another dotenv file. Literal and complex Compose tag expressions remain unchanged because compose_tag.is_updateable is false.

Each project’s image_updates list contains the latest successful cached registry results for images used by that project. An empty list leaves the configured tags unchanged. Inventory reports are processed asynchronously, so the loop can still read the preceding stored project snapshot immediately after collection. The job also does not wait for registry checks to finish; newly discovered, pending, failed, unused, and unchanged images are absent from the list.

Collect Microsoft Hyper-V VM inventory

Refreshes Microsoft Hyper-V virtual machines from a Windows Hyper-V host.

The inventory includes:

• VM ID and display name
• state
• uptime
• processor count
• assigned memory
• generation
• configuration path
• network adapters, MAC addresses, virtual switch details, reported IP addresses, and VLAN settings
• virtual hard disks and their host paths and VHD metadata
• virtual DVD drives and inserted media
• snapshots and their dependencies
• best-effort guest endpoint identification

Optional detail groups are best effort. If the host cannot report one group, the remaining VM inventory is still stored and the collection reports a warning.

Ordyn identifies a guest endpoint only by its SMBIOS/DMI UUID. Each guest endpoint must have a current hardware inventory that reports a valid system UUID. Run Collect hardware inventory on each guest endpoint at least once before relying on identification.

Hardware inventory and Hyper-V inventory can be collected in either order. If guest hardware inventory is collected after the host's VM inventory, Ordyn evaluates the stored VM again automatically.

If exactly one endpoint matches, the VM is linked to that endpoint. If multiple endpoints match the same evidence, the VM is marked ambiguous and Ordyn does not link it automatically.

See Microsoft Hyper-V VMs for the endpoint tab.

Services

Inspect service

Checks whether the selected service exists and reports its current state. To configure it, select the service name.

Start service

Starts the selected service. To configure it, select the service name.

Stop service

Stops the selected service. To configure it, select the service name.

Restart service

Restarts the selected service. To configure it, select the service name.

Processes

Inventory Windows sessions

Lists logged-in Windows sessions on the endpoint. Use it before user prompts, notifications, or session-scoped process termination when the job needs to decide which Windows session to target.

The result contains summary fields that can be used in later If branch steps:

• result.session_count
• result.active_session_count
• result.active_rdp_session_count
• result.active_console_session_count
• result.disconnected_session_count
• result.has_active_session
• result.has_multiple_active_sessions
• result.single_active_session_id

The task also returns a sessions list in the job result for review. Each entry includes the Windows session ID, state, principal, and whether the session is the console session or a remote desktop session.

Inspect process

Checks whether a matching process is running by name or PID and reports the matches. To configure it, choose whether to look up the process by name or PID, then set the match mode if you use the name search.

Terminate process

Terminates one or more matching processes on the endpoint. Set the process name, match mode, force behavior, and whether child processes should be included.

You can choose the termination scope:

• Device: terminate matching processes across the endpoint.
• Windows account: terminate matching processes in all logged-in sessions for the selected Windows account.
• Specific Windows session ID: terminate matching processes only in the selected Windows session.

For self-service jobs, set the scope to Specific Windows session ID and use {{ trigger.self_service.source_session_id }} to target the session that launched the portal request.

process.terminate exposes a normalized runtime result:

• result.outcome
  • terminated
  • not_running
  • failed
• result.matched_process_count
• result.terminated_process_count

That makes the common "terminate if running, otherwise continue" pattern much less brittle than matching free-form stderr text.

If the task is configured to prompt first, Ordyn asks the logged-in user to close the blocking application before it falls back to termination. That is the version used when an update flow needs a gentler first attempt.

One example flow:

1. terminate process AcmeApp.exe
2. add a Set job variable task that stores the task's Outcome as job.vars.process_state
3. add an if task that checks whether job.vars.process_state equals not_running or terminated
4. run uninstall only in the selected then branch

User messages

Choice prompt

Shows a prompt on the endpoint and waits for the user to select one of the configured choices. The selected value can be stored in a job variable for later branches and tasks.

Choose the display target:

• All active sessions: show the prompt to every active signed-in Windows session.
• Specific Windows session ID: show the prompt only in the selected Windows session.

On Windows endpoints with multiple active sessions, choose a specific Windows session ID for choice prompts so Ordyn knows which user should answer. In self-service jobs, use {{ trigger.self_service.source_session_id }} to target the session that launched the portal request.

Notification

Shows a non-blocking message on the endpoint. Notifications can auto-close after the configured duration.

Choose the display target:

• All active sessions: show the notification to every active signed-in Windows session.
• Specific Windows session ID: show the notification only in the selected Windows session.

In self-service jobs, use {{ trigger.self_service.source_session_id }} to show the notification in the session that launched the portal request.

Microsoft Hyper-V

Start Microsoft Hyper-V VM

Starts an inventoried Microsoft Hyper-V virtual machine on the target endpoint. To configure it, select a VM from the inventoried Hyper-V VM combobox.

Shut down Microsoft Hyper-V VM

Requests a graceful guest shutdown for an inventoried Microsoft Hyper-V virtual machine. To configure it, select a VM from the inventoried Hyper-V VM combobox.

This action asks the guest to shut down. It depends on the guest and Hyper-V integration services behaving correctly.

Reboot Microsoft Hyper-V VM

Requests a reboot for an inventoried Microsoft Hyper-V virtual machine. To configure it, select a VM from the inventoried Hyper-V VM combobox.

Stop Microsoft Hyper-V VM

Stops an inventoried Microsoft Hyper-V virtual machine without guest shutdown. To configure it, select a VM from the inventoried Hyper-V VM combobox.

Use this as the force-off style action. Prefer Shut down Microsoft Hyper-V VM when the guest should be allowed to shut down cleanly.

Create Microsoft Hyper-V VM snapshot

Creates a full Hyper-V snapshot/checkpoint for an inventoried virtual machine. To configure it, select a VM from the inventoried Hyper-V VM combobox and provide a snapshot name. The snapshot name supports templating.

Delete Microsoft Hyper-V VM snapshot

Deletes a Hyper-V snapshot/checkpoint from an inventoried virtual machine. To configure it, select a VM and provide a snapshot name. The snapshot name supports templating.

Hyper-V snapshot names are not guaranteed to be unique. This task requires exactly one snapshot on the selected VM to match the rendered snapshot name. It fails when no snapshot or multiple snapshots match. Hyper-V keeps dependent snapshots and merges the selected snapshot's checkpoint data.

Apply Microsoft Hyper-V VM snapshot

Applies a Hyper-V snapshot/checkpoint to an inventoried virtual machine. To configure it, select a VM and provide a snapshot name. The snapshot name supports templating.

This reverts the VM to the selected snapshot and can discard current VM state. For a healthy running VM, Ordyn turns the VM off without a guest shutdown, applies the snapshot, and starts the VM again. If applying fails after power-off, or if restarting fails after the snapshot is applied, the task fails and the VM remains off for inspection.

A VM that is off, saved, or suspended can be restored directly and is not started automatically by Ordyn. A paused VM must be started or stopped before running this task. The task rejects unhealthy, transitional, and unknown VM states.

Because Hyper-V snapshot names are not guaranteed to be unique, this task requires exactly one snapshot on the selected VM to match the rendered snapshot name. It fails when no snapshot or multiple snapshots match.

Hyper-V power and snapshot actions are Windows-only. The target endpoint must be an approved, connected Windows Hyper-V host with a current Hyper-V VM inventory.

Desktop

Replay GUI automation

Replays an uploaded Windows GUI automation definition in an interactive desktop session. To configure it, upload the recorder JSON, set the launch executable path and arguments, choose the Windows execution context, and decide whether Ordyn should manage desktop preparation.

Credential-backed replay can use a reusable Windows Account or a templated user. A templated user selects a plain username variable and a secret password variable; both resolve from the replay task's complete job context.

Manage desktop preparation is enabled by default. In that mode, Ordyn expands the replay into visible runtime steps:

• Wait for Windows desktop readiness
• Inspect desktop session
• Desktop logon when a managed login is required
• Lock desktop input when input locking is automatic
• Replay GUI automation
• Desktop logoff and Unlock desktop input cleanup when needed

Disable managed preparation only when you intentionally add the desktop-control steps yourself. The replay task then expects a usable unlocked Windows desktop to already exist. Do not use this task when job desktop execution is set to not required. Replay GUI automation is not supported inside For each or While loop bodies.

When replay uses the same credential selection, resolved Windows user, and elevation mode as an earlier task in the job target, it shares that task's Windows logon session. This allows user-session state such as mapped drives to remain available. See Windows Execution Contexts.

Wait for Windows desktop readiness

Waits until Windows has finished setup/OOBE handoff, Windows Update is not actively servicing updates, no shutdown or restart is in progress, and either a usable desktop or a normal logon screen remains stable. Use it before manual desktop automation after OS installation or any other flow where Windows may still be showing post-setup screens.

A pending-reboot report is informational. It does not mean that a restart is imminent, does not make this task restart the endpoint, and does not prevent readiness once update servicing is idle. Task results include the observed Windows Update state, pending-reboot indicators, Windows Update activity, and shutdown/restart signals for troubleshooting.

Inspect desktop session

Inspects the active Windows console session and reports whether Ordyn can reuse it or must perform a managed desktop logon.

Desktop logon

Logs on the selected Windows execution context when a managed desktop session is required. This is normally generated by managed GUI replay, but it can be authored manually for custom desktop flows. Select a Windows Account for reusable catalog credentials, or select Templated user and provide a plain username variable and secret password variable. Templated credentials resolve from the desktop-logon task's complete job context. When Ordyn creates a managed login, it preserves the Windows sign-in identity selected before the task. When you author it manually, add a matching Desktop logoff cleanup step unless the job intentionally leaves the user session active.

Lock desktop input

Locks local keyboard and mouse input for the active Windows desktop session. Use this before automation that runs under a privileged desktop account. When you author it manually, add a matching Unlock desktop input cleanup step that runs even when replay fails.

Unlock desktop input

Releases the current Ordyn desktop input lock. Use it as cleanup when you author desktop-control steps manually.

Desktop logoff

Logs off the managed Windows desktop session and releases the associated desktop control. Use it as cleanup when a manual desktop flow created a managed login.

Scripting

Run Inline Script On An Endpoint

Executes inline script content on the endpoint. To configure it, set the interpreter, script content, Windows execution context, and execution mode.

Specific-user execution can use a reusable Windows Account or a templated user. Templated credentials use a plain username variable and a secret password variable resolved for this task, including applicable job prompts and submitted run values.

Inline script content supports runtime templates, including prompted and inherited vars.* values.

Choose one of these execution modes:

• Blocking waits for the script to exit and reports its exit code, stdout, and stderr. Output parsing, output bindings, reboot-success exit codes, cancellation, and infrastructure maintenance are available in this mode.
• Non-blocking reports success as soon as the Windows PowerShell or CMD interpreter starts. The job immediately proceeds to its next step. The process continues independently of the job, and its later exit code, output, failures, and child processes are not tracked. Cancelling the job does not stop it.

Windows PowerShell and CMD scripts can independently choose where Windows starts the interpreter in either execution mode:

• Background / non-interactive desktop uses the selected Windows execution context without attaching it to the active desktop.
• Existing active desktop binds the process to the active, signed-in, unlocked console session. The interpreter window stays hidden, while GUI applications started by the script can appear on that desktop. Console applications started by the hidden interpreter do not automatically receive a visible console window. Launch them through a mechanism that creates a new console when their window must be visible. LocalSystem is not available for this desktop mode. A specific logged-in user must own the active console session.

In Blocking mode, Ordyn continues to capture output and enforce timeout and cancellation while the script runs on the existing active desktop. Blocking controls whether Ordyn waits for completion; it does not make the interpreter or a child console window visible. If the script starts a GUI process asynchronously, make the script wait for that process when the job must not continue yet, for example with PowerShell's Start-Process -Wait.

Use Non-blocking when the executable must outlive the script job step. For example, a job can start a priming executable, use a Sleep step, terminate that executable with Terminate process, and then run the next installer step.

The configured task timeout remains the deadline for receiving the start acknowledgement for Non-blocking execution. It does not limit the detached process lifetime.

Bash and POSIX shell inline scripts always use Blocking execution and do not offer Windows desktop selection.

If the script uses secret variables, the resolved values are available to the script at runtime. The endpoint agent redacts exact known secret values from stdout, stderr, operational command-output logs, and audit command invocation logs before reporting the result.

For Windows execution context behavior, see Windows Execution Contexts.

Matching credential-backed Windows script, package, and GUI replay tasks in one job target share a Windows logon session. See Session reuse within a job.

Endpoint inline scripts can be marked as infrastructure maintenance scripts when they are intended to restart or otherwise interrupt Ordyn infrastructure components on the target endpoint. This is only valid for endpoints marked in Edit endpoint as an Ordyn server host, Ordyn edge host, or Ordyn hypervisor host.

Infrastructure maintenance requires Blocking execution.

When this option is enabled, Ordyn sends the script with durable result spooling and waits for the configured recovery timeout. On Linux agents this uses systemd-run to keep the result handoff alive across Ordyn agent service restarts. Windows agents run the script normally, but can store its completed result locally and retry delivery during the recovery window. A Windows script does not survive an Ordyn agent service restart merely because durable result spooling is enabled.

Run endpoint script

Executes a script on the endpoint. To configure it, select a saved script and provide any parameters or output bindings the script expects.

Pass run values through the saved script's configured parameter bindings or through environment variables set by an earlier task. Saved script content is executed verbatim.

The saved script controls whether the step is Blocking or Non-blocking and, for Windows PowerShell and CMD, whether it uses the background non-interactive desktop or the existing active desktop. A non-blocking step succeeds when the interpreter starts and then lets the job continue without waiting for process completion.

Output bindings and infrastructure maintenance are available only while the selected script uses Blocking execution. The job keeps configured values when a script uses Non-blocking execution, but hides and ignores them until that script uses Blocking execution again.

Saved script parameters with type secret are resolved from selected secret variable definitions at runtime. The endpoint agent redacts exact secret parameter values from stdout, stderr, operational command-output logs, and audit command invocation logs. The plaintext is still passed to the script using the script's normal parameter delivery mode, so avoid echoing it or passing it to tools that expose process arguments.

Saved Windows endpoint scripts use the execution context configured on the script. See Windows Execution Contexts.

Blocking saved endpoint scripts can also be marked as infrastructure maintenance scripts. Use this when the script may temporarily interrupt Ordyn infrastructure components, for example by redeploying the Ordyn server stack, restarting an edge host, or rebooting a hypervisor that hosts Ordyn infrastructure.

The target endpoint must be marked in Edit endpoint as at least one infrastructure role:

• Ordyn server host
• Ordyn edge host
• Ordyn hypervisor host

For hypervisor hosts, you can also select the hosted Ordyn infrastructure endpoints in Edit endpoint. The hosted endpoint list is used as topology and recovery context; the hypervisor role itself is enough for infrastructure maintenance safeguards to apply.

When infrastructure maintenance is enabled, Ordyn includes durable result spooling in the script instruction. On Linux agents this requires systemd-run; if systemd-run is unavailable, the handoff fails instead of using a less durable child process. Windows agents run the script normally and can store its completed result locally for delivery retries. A Windows script that restarts the Ordyn agent service is not kept alive by durable result spooling.

Run Inline Script On A Runner

Executes inline Bash, POSIX shell, or PowerShell content on the Runner reserved for an infrastructure job.

Select the interpreter, enter the script content, and configure text or JSON output, output bindings, exit-code mappings, and timeout as needed. Runner inline scripts always use blocking execution. Host execution uses the Runner service identity; Docker execution uses the image user or the configured Container user.

Inline script content supports runtime templates, including prompted and inherited vars.* values. In supported infrastructure Runner fields, {{ job.workspace }} provides the absolute host or container workspace path.

The script can use ORDYN_WORKSPACE to share files with later Runner-backed steps in the same run.

For Docker user selection, workspace permissions, and ownership restoration, see Run Linux Runner Scripts In Docker.

Run Runner Script

Executes a saved PowerShell, Bash, or POSIX shell script on an eligible Ordyn Runner. To configure it, select a saved script and provide any parameters or output bindings the script expects.

Pass run values through the saved script's configured parameter bindings or through environment variables set by an earlier task. Saved script content is executed verbatim. Use ORDYN_WORKSPACE for the shared Runner workspace, or pass {{ job.workspace }} through a string parameter.

For an endpoint-scoped job, the task uses the endpoint's effective Runner pool assignment. For an infrastructure-scoped job, select the Runner pool in the job overview. All Runner-backed steps for a target run on the same reserved Runner.

The selected script determines whether the task needs a Windows PowerShell Runner or a Linux Runner with the selected Bash or POSIX shell capability.

Runner scripts executed on the host use the Runner service identity. Docker execution uses the image user or the configured Container user. Secret parameters travel inside the signed command over the Runner's authenticated Edge connection, and known values are redacted from captured output. Treat Runner scripts as trusted code and do not print secrets.

See Runners, Run Linux Runner Scripts In Docker, and Scripts for pool selection, shared workspaces, container users, parameters, output, and runtime variables.

Place file in Runner workspace

Places one global File-library file, software-package file, or earlier task artifact at a workspace-relative path for later steps in an infrastructure job. The editor uses the same source and template controls as Place file on endpoint.

For a software package source, select the package and then its primary file or a staged install archive. Staged archives remain ZIP files in the workspace. The task resolves the package's current primary file or current archive-slot content each time the job runs. Package approval does not affect file placement, but the selected content must pass malware scanning.

Enable stored-file template rendering only for valid UTF-8 configuration content of up to 10 MiB. Enable overwrite only when the job should replace different content at the selected path.

Sync file folder in Runner workspace

Copies the contents of one global File-library folder into a workspace-relative directory for later steps in an infrastructure job. The task can include nested folders and can prune target files that are absent from the source. Source file contents are copied verbatim.

A sync accepts up to 100 files and 100 GiB of declared input. See Infrastructure Jobs for placement and pruning behavior.

Collect Runner artifacts

Collects named files, directories, or glob matches from the shared infrastructure-job workspace. Paths are workspace-relative. Directories and glob results are returned as ZIP artifacts.

Malware scanning is required by default. A collection step can instead trust its Runner source, which records the resulting files as Skipped, trusted source and permits later job file-placement and folder-sync steps to distribute them.

Choose No artifact expiry, 1 hour, 1 day, 7 days, or 30 days. The expiry period begins when Ordyn stores the artifact. No artifact expiry retains it until its parent infrastructure run is pruned.

Publish artifacts to software package

Maps named artifacts from an earlier top-level Collect runner artifacts step to the selected package's primary installer or staged ZIP archives. Changed content replaces the mapped package assets and applies the product's package-approval policy. Identical content is a successful no-op.

The selected artifacts must still be available and unexpired when publication runs.

See Infrastructure Jobs for the offline package workflow, limits, and extraction behavior.

Delete collected artifacts

Deletes every artifact produced by a selected earlier Collect artifacts or Collect runner artifacts step for the current job target. The task succeeds when those artifacts are already absent, so it can safely run again.

Use this step after a later task has consumed a transferred bundle. See Artifacts for retention and deletion behavior.

Run collector

Runs a collector definition and stores its values in collector history. To configure it, select the collector definition to run.

A Runner-targeted collector uses the endpoint's effective Runner pool assignment and runs on an eligible Windows or Linux Runner while keeping the endpoint as the collector target.

OS deployment

PXE boot endpoint

Publishes PXE boot configuration for the selected boot image to the assigned net node.

For Windows boot images, the step waits for the temporary WinPE preboot client to connect. The next step is Install OS image.

For Linux boot images, this is the operating-system installation step. Select the Linux operating system and install answer file. Ordyn boots the Linux installer, serves the install answer file through the assigned net node, and installs the newest approved Ordyn Agent release that exactly matches the operating system distribution, release, and architecture. Before later job steps run, Ordyn automatically waits for endpoint enrollment and agent instruction readiness. Do not add Install OS image to a Linux deployment.

To configure it, choose whether to use the latest boot image for Windows or Linux, or select a specific boot image.

Install OS image

Runs a Windows OS image install workflow against the active WinPE session from this job or from an earlier PXE boot job on the same endpoint. This step supports Windows operating systems only. Set the OS image, product key mode, install answer file if needed, and any driver profiles.

After the install workflow finishes, Ordyn automatically adds visible runtime steps that wait for endpoint enrollment, agent instruction readiness, and Windows desktop readiness. Later job steps start only after this handoff completes. If Windows reboots while the generated desktop-readiness wait is running, Ordyn waits for the agent to reconnect and synchronize replay protection, then retries the readiness wait. This recovery shares a limit of three attempts within 30 minutes with other safe preparation-step recovery.

Timeout behavior:

• the job target timeout is the outer deadline for the whole endpoint deployment
• explicit timeouts on OS image install workflow steps are honored for those generated WinPE instructions
• generated WinPE workflow steps without an explicit timeout use the remaining job target timeout budget instead of the normal instruction TTL
• if the job target times out before the WinPE agent reports completion, later success reports do not revive the target or run later steps

For full OS install flows, size the job timeout for the complete deployment path: PXE boot, boot image download, WinPE startup, install source preparation, Windows Setup, reboot, enrollment, and any post-enrollment tasks.

The generated Prepare install source on net node entry reports download, extraction, and session-copy progress. After completion, its job history shows whether preparation was a cache hit, a cache miss, or ran with caching disabled. Cache settings and statistics are available on the assigned net node.

Build WinPE boot image

Builds a managed WinPE boot image asset set on a capable Windows Runner.

This task requires an infrastructure-scoped job with a Runner pool selected in the job overview. Select the WIMBoot image and Ordyn Agent release, then set the output name and version and optionally select driver profiles. The job's pool must contain an available Windows Runner that reports the Windows ADK and WinPE build capability.

Windows in-place upgrade

Starts an in-place Windows upgrade from the selected OS image. Set the OS image to use for the upgrade.

The Windows in-place upgrade step executes the selected OS image's upgrade workflow on the existing Windows installation.

Ordyn expects the selected OS image to be:

• platform windows
• backed by an ISO
• configured with a non-empty upgrade workflow
• contain at least one Run OS image command step that launches the mounted Windows setup path

Only the Upgrade workflow runs today. Install workflow is stored for future OS installation use.

Run OS image command supports cmd or powershell, plus placeholders such as:

• {setup_path}
• {mounted_drive}
• {iso_path}
• {package_path}
• {package_dir}
• {package_filename}

Ordyn does not block the upgrade automatically based on battery or AC state. If you want that guard, use Collect system status before the upgrade and branch on:

• Power source
• Charging state
• Battery charge percent

Endpoint

Refresh dynamic group memberships

Re-evaluates every dynamic group available to the current endpoint and applies any membership changes before the next job step starts.

Use this after a step changes a persistent variable or another value that a dynamic group query uses when the same workflow needs the new membership immediately. For example, one job can set a variable, refresh group memberships, and thereby assign a second job whose Run when assigned automation starts it.

The refresh covers all dynamic groups for the endpoint's tenant. In environments with many dynamic groups, it can add noticeable work to every target, so include it only in jobs that need an immediate refresh. Routine background evaluation continues without this step.

Wait for endpoint enrollment

Waits for an endpoint agent to enroll and reconnect. OS installation tasks include this wait automatically. Add it manually when another custom workflow creates or replaces an endpoint agent identity.

Ping endpoint

Requests a one-shot ping probe through the assigned net node using the endpoint’s latest IPv4 address.

Wake endpoint

Sends a Wake-on-LAN packet for the endpoint through the assigned net node. To configure it, set the optional broadcast address and port if your network needs custom Wake-on-LAN settings.

Wait for endpoint state

Waits until the endpoint reaches the selected relay, preboot, ping reachability, or agent instruction-readiness state. Choose Agent instruction ready when later steps must wait until replay protection is synchronized for the current agent connection. The task remains waiting if operator replay recovery is required and continues after that recovery is acknowledged.

Check endpoint connection

Checks whether the endpoint is currently connected. The task succeeds even when the endpoint is disconnected and exposes the result for later conditions:

• result.connected
• result.outcome
• result.endpoint_id
• result.checked_at

Use this before an if task when a job should branch based on current endpoint connectivity.

Telematik

Collect card terminal system status

Collects lightweight card terminal system status through the assigned Telematik service client.

This task only applies to Telematik card terminal endpoints. The endpoint must have a hostname, an active credential profile, and an assigned Telematik service client.

The task stores normalized terminal facts and the raw vendor payload on the card terminal configuration. Typical facts include vendor, model, firmware, serial, selected network interface, IPv4 network configuration, MAC addresses, NTP status, SICCT data, and SMC-KT metadata when reported by the terminal.

Ordyn also runs this collection automatically after terminal configuration changes and then regularly in the background. Reachability state is tracked separately by lightweight API reachability probes.

If the assigned Telematik service client is disconnected or the terminal cannot be reached through the vendor API, the task fails with the Telematik service-client response error.

Network inventory

Collect switch system status

Collects lightweight switch system status through the assigned SNMP service client.

This task only applies to switch endpoints. The switch endpoint must have a hostname, an active credential profile, and an assigned SNMP service client.

The task stores switch facts such as name, location, vendor, model, firmware, serial, and sysDescr.

Ordyn also runs this collection automatically after a switch is created and then regularly in the background. A recent successful collection is what makes a switch endpoint appear active in endpoint views.

If the assigned SNMP service client is disconnected or the switch cannot be reached through SNMP, the task fails with the SNMP service-client response error.

Collect printer system status

Collects lightweight printer system status through the assigned SNMP service client.

This task only applies to printer endpoints. The printer endpoint must have a hostname, an active credential profile, and an assigned SNMP service client.

The task stores read-only printer facts such as printer name, printer status, page count, location, vendor, model, firmware, serial, and sysDescr when the printer reports them through generic SNMP and Printer-MIB values.

Ordyn also runs this collection automatically after a printer is created or updated and then regularly in the background. A recent successful collection is what makes a printer endpoint appear active in endpoint views.

If the assigned SNMP service client is disconnected or the printer cannot be reached through SNMP, the task fails with the SNMP service-client response error.

Inventory switch ports

Requests switch port inventory through the assigned SNMP service client.

This task only applies to switch endpoints. The switch endpoint must have a hostname, an active credential profile, and an assigned SNMP service client.

The task stores physical Ethernet and link aggregation interfaces, link state, admin state, speed, aliases, descriptions, VLAN data, learned MAC addresses, and endpoint-to-switch-port links. Link aggregation interfaces are visible for inventory and traffic monitoring but are read-only for alias and admin-state changes.

Learned MAC addresses are matched to endpoint interfaces on every port, including uplinks. Ordyn treats a port as an uplink when the SNMP result marks it as an uplink or when the port learns at least the configured SNMP Switch Uplink MAC Threshold number of MAC addresses. An uplink can therefore show multiple downstream endpoint matches.

When an endpoint interface is matched on multiple ports, Ordyn selects one primary attachment. A non-uplink match is preferred, with an uplink used as the fallback. Primary attachments are written to switch port history so previous cabling locations remain visible after an endpoint moves or a link disappears.

Set switch port admin state

Enables or disables an inventoried switch port through the assigned SNMP service client.

This task only applies to switch endpoints. The switch endpoint must have a hostname, an assigned SNMP service client, an active credential profile, and the credential profile must be enabled for write operations.

To configure it, provide:

• the switch port ifIndex
• the desired admin state, either up or down

The selected port must already exist from a previous Inventory switch ports result. If the switch rejects the write, for example with NoAccess, the task records the SNMP error in the job result.

Port alias updates are available from the switch Ports view when the assigned credential profile is write-enabled. They are not a separate job task.

Software management

Install software

Installs a managed software package. To configure it, select the package to act on.

Packages waiting on approval are rejected here unless the workflow explicitly allows pending approval packages.

Uninstall software

Uninstalls a managed software package. To configure it, select the package to act on.

Packages waiting on approval are rejected here unless the workflow explicitly allows pending approval packages.

The package's uninstall workflow is always authoritative. Endpoint inventory uninstall strings are passed into the workflow, but Ordyn does not execute them automatically. Reference {{ inventory.quiet_uninstall_string }}, {{ inventory.uninstall_string }}, or {{ inventory.msi_product_code }} from a package command when the uninstaller should come from endpoint inventory.

Install latest product

Installs the newest compatible managed package for a product without hard-coding a package version. Ordyn picks the package at runtime by matching the product, platform, architecture, and newest available version that still fits the endpoint. To configure it, select the product to act on, and choose a variant if the product has one.

Check product presence

Checks whether the selected product is detected in the latest software inventory snapshot. Set the product to act on, and choose a variant if the product has one.

Check software product presence evaluates the selected managed product against the endpoint's latest software inventory snapshot.

It succeeds with a normalized result even when the product is not detected:

• result.is_installed
• result.match_count
• result.detected_version

If the endpoint does not have a software inventory snapshot yet, the task fails because the check cannot be resolved reliably.

One example flow:

1. run Check product presence
2. select the managed product to inspect
3. add an if task
4. select the check step as the source task
5. select Installed
6. branch to install in else when the product is missing, or uninstall/remediate in then when it is present

Uninstall product

Removes a product without forcing the job to name a specific package. Ordyn looks at the installed product and chooses the best matching managed uninstaller, preferring a version-specific package when one exists and falling back to a generic managed uninstaller otherwise. To configure it, select the product to act on, and choose a variant if the product has one.

The selected managed package still provides the uninstall workflow. Inventory uninstall metadata is available to that workflow as template data, but it is not used unless the workflow references it.

Update software packages

Plans and optionally executes managed software updates from endpoint inventory. Select the software update policy that should control allowed products, packages, publishers, channel upgrades, pending approval behavior, and self-updating software exclusions.

For MSI/MSP package chains, the task installs every missing package in order. It installs the full MSI baseline and patch chain when the endpoint does not match a chain ancestor, or only the missing MSP suffix when an ancestor is already installed. A pending, non-installable, or explicitly excluded required link blocks newer patches that depend on it.

Packages waiting on approval are rejected here unless the workflow explicitly allows pending approval packages.

For packages configured with Uninstall then install, update planning first tries to uninstall using the matched managed package for the installed version. If the installed version is not represented by a managed package, Ordyn can fall back to the latest package's uninstall workflow only when that uninstall workflow does not require a package file. That fallback is intended for generic inventory-based uninstall commands such as {{ inventory.quiet_uninstall_string }} or msiexec.exe /x "{{ inventory.msi_product_code }}" /qn /norestart.

software_update_packages inserts a prompt step ahead of the generated package actions when interactive prompting is enabled.

That prompt can:

• inform the user that updates are about to start
• allow the user to continue immediately
• allow the user to postpone by one of the configured durations

If the generated package workflow contains terminate_process steps, a Prompt user first setting gives the logged-in user one chance to close the blocking application before Ordyn falls back to termination.