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

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, and Ordyn agent log actions.

Unsupported step types include software/package deployment, OS installation, system updates, 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.

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.

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.

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 variable override

Creates, updates, nulls, or deletes one persistent variable override on a selected scope. 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.

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.

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
• Previous task artifact
  • places a file collected by an earlier task in the same job target

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.

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 endpoint to reconnect before continuing.

Windows

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 endpoint to reconnect, checks Windows Update readiness, and follows the selected one-reboot or rerun-until-clean strategy.

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.

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. Leave a filter empty to include every approved value in that group.

For example, a frequent Microsoft Defender job can select the Microsoft Defender Antivirus product. Leave classifications empty to include Defender definition, engine, platform, security, and regular updates, or 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.

Software updates and Windows Update driver offers are supported. Firmware delivered through the Windows Update driver channel follows the Drivers classification. Windows installs only updates that it reports as applicable to the endpoint.

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 ring assignments, policy setup, approvals, and scheduling.

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, Microsoft Update, or WSUS, then select at least one classification. Drivers collects automatic and optional Windows Update driver offers, including firmware delivered through the driver channel. Optional product filters restrict software offers further.

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.

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": {},
    "continue_on_error": false,
    "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
                    },
                    "continue_on_error": false,
                    "expires_in_seconds": 900
                  }
                ],
                "continue_on_error": false,
                "expires_in_seconds": null
              }
            ],
            "continue_on_error": false,
            "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 }}"
            },
            "continue_on_error": false,
            "expires_in_seconds": 1800
          }
        ],
        "continue_on_error": false,
        "expires_in_seconds": null
      }
    ],
    "continue_on_error": false,
    "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 and MAC addresses
• best-effort guest endpoint identification

The agent uses the Hyper-V WMI/CIM provider on Windows. It does not use PowerShell for inventory collection.

Ordyn tries to identify the guest endpoint for a VM by using stable guest identity data first and network fallbacks second:

• SMBIOS/DMI UUID when available
• MAC address fallback when SMBIOS/DMI is not available

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 deletes every snapshot on the selected VM whose name exactly matches the rendered snapshot name. Deleting snapshots is delegated to Hyper-V and lets Hyper-V merge checkpoint data. Ordyn does not delete snapshot files directly.

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. 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.

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.

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. 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

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

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 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.

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.

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 secrets 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 server script

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

Server-side scripts run inside the Ordyn server environment. Secret parameters and secret templates are resolved for the script, but endpoint-agent redaction does not apply because no endpoint agent is involved. Treat server-side scripts as trusted code and do not print secrets unless you intentionally want them in task output.

Run collector

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

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 Windows endpoint using the selected PXE bootstrap image, wimboot image, and agent release. To configure it, select the WIMBoot image and agent release, then optionally set the output name, version, and driver profiles.

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

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 switch ports, link state, admin state, speed, aliases, descriptions, VLAN data, learned MAC addresses, and endpoint-to-switch-port links.

Learned MAC addresses on uplink ports are not linked to endpoints. 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.

Each endpoint-to-switch-port match is also 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.

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.