Infrastructure Jobs

Infrastructure jobs run a workflow once on an Ordyn Runner. They are intended for build work, infrastructure administration, and other tasks that should execute once rather than once per endpoint.

Infrastructure jobs have their own library under Operations > Infrastructure Jobs. This library has an independent folder tree and contains only infrastructure-scoped jobs.

Requirements

Before running an infrastructure job:

• create a Runner pool
• enroll at least one compatible Windows or Linux Runner in the pool
• keep the pool's Cache Node active and reachable
• select the Runner pool in the job overview

The Runner must provide the platform and capabilities required by every Runner-backed step in the job.

Create An Infrastructure Job

1. Open Operations > Infrastructure Jobs.
2. Select the folder where the job should be stored.
3. Select New infrastructure job.
4. Enter the name, optional friendly name, description, Runner pool, Runner platform, container workspace path, and target timeout.
5. Configure the task list.
6. Save the job.
7. Open the saved job's Variables tab to configure job-level overrides and launch prompts.

A new infrastructure job starts with a Run inline script step. Run Bash, POSIX shell, PowerShell, or Command Prompt content, or launch an executable with a literal argument list. You can also replace the step with another supported task.

The execution scope is fixed when the job is created. Endpoint jobs and infrastructure jobs remain in their respective libraries.

Execution Model

Each infrastructure job run has one infrastructure target and does not select endpoints.

The first Runner-backed step reserves one compatible Runner from the selected pool. That Runner executes every Runner-backed step for the complete run. Each Runner handles one reserved job target at a time.

If all compatible Runners are busy or offline, the run waits for capacity. Waiting time is part of the job's target timeout. A reserved run remains associated with the same Runner if its connection is interrupted and waits for that Runner to reconnect until the timeout expires.

Runner-backed steps share one managed host workspace for the run. Files created by one step remain available to later Runner-backed steps through:

ORDYN_WORKSPACE

Runner runtime fields can also use {{ job.workspace }}. Host tasks receive the host workspace path. Docker tasks mount the same workspace at the job's configured container workspace path, which defaults to /workspace; both ORDYN_WORKSPACE and {{ job.workspace }} contain the path appropriate to the current execution environment. Ordyn removes the managed workspace after the run reaches a terminal state.

Use {{ job.workspace }} in inline Runner script content, executable paths and arguments, string parameter values, job and container environment values, and stored files whose content is rendered during placement. Saved Runner script content is executed verbatim; use ORDYN_WORKSPACE in the script or pass the workspace through a string parameter.

Workspace destinations and collection patterns remain relative. Do not use {{ job.workspace }} in a Runner working directory, file-placement destination, Git checkout destination, or artifact path.

Available Tasks

Infrastructure jobs support:

• Run inline script
• Run runner script
• Place file in Runner workspace
• Sync file folder in Runner workspace
• Check out Git repository
• Collect runner artifacts
• Publish artifacts to software package
• Delete collected artifacts
• Build WinPE boot image
• Download offline Windows update catalog
• Download approved Windows updates
• Refresh Intel ODCA trust
• Sleep
• Log message
• Set job variable
• Set environment variable
• Send email
• End job
• If branch
• For each
• While loop

Endpoint actions, endpoint prompts, software deployment, endpoint collectors, and desktop-control tasks are not available in infrastructure jobs.

Run Inline Script

Inline Runner scripts support:

• Bash or POSIX sh on a compatible Linux Runner
• PowerShell on a compatible Windows Runner
• text or JSON output
• output bindings
• exit-code mappings
• normal task timeout and cancellation
• direct executable launch with literal arguments
• an optional workspace-relative working directory

Inline Runner scripts use blocking execution and the Runner service identity. They do not have a Windows desktop or Windows execution-context setting.

Executable launch starts the selected program directly without adding a shell. Use script launch when shell parsing, pipelines, redirection, or shell built-ins are required.

Use job variables for inherited values and values selected when the run starts. Inline script content, executable values, arguments, and working directories support runtime templates. Use {{ job.workspace }} where an absolute workspace path is required; keep the working directory workspace-relative. A Set environment variable task can expose a templated value to every subsequent Runner script in the shared run workspace.

Run Runner Script

Create reusable Runner scripts under Library > Scripts, then select them in a Run runner script step.

Saved Runner scripts support typed parameters, secret parameters, text or JSON output, output bindings, exit-code mappings, and an optional workspace-relative working directory. Their content is executed verbatim. Pass run values through the saved script's parameter bindings or the process environment, including ORDYN_WORKSPACE. Windows Runner scripts use PowerShell or Command Prompt, and Linux Runner scripts use Bash or POSIX sh.

See Scripts for script configuration and Available Tasks for task details.

Place A File In The Runner Workspace

Place file in Runner workspace stages one input for later Runner steps. Select a global File-library file, a software package's primary file or staged install archive, or an artifact from an earlier task in the same run. Endpoint files are not available because an infrastructure job has no endpoint source.

When using a software package, select the package and then its content. A staged install archive is placed as the complete ZIP. The package selection follows the logical primary-file location or archive slot, so recurring jobs use the content currently published there. The job fails if the package or selected content is unavailable when the task runs.

Enter a workspace-relative POSIX destination such as input/setup.exe or input/configuration.xml. Parent directories are created automatically. Enable Overwrite existing file when the workflow intentionally replaces a path; otherwise, an identical existing file is reused and different content fails the step.

Enable Render selected file as template for a valid UTF-8 text file of up to 10 MiB, such as a configuration file. The rendered content supports the infrastructure job's runtime references, including {{ job.workspace }}. Template errors, oversized files, or non-UTF-8 content fail the step.

Each placement step accepts one file of up to 100 GiB. The complete shared workspace is limited to 100 GiB.

Sync A File Folder In The Runner Workspace

Sync file folder in Runner workspace places the contents of one global File-library folder into a workspace-relative target directory. The selected folder itself is not added to the target path. For example, syncing the contents of Offline installer to input/vendor places Offline installer/setup.exe at input/vendor/setup.exe.

Enable recursive sync to include nested folders. Enable pruning to delete files and folders in the target directory that are absent from the selected source. Empty source folders are supported; with pruning enabled, they leave the target directory empty.

The target accepts runtime templates and must resolve to a workspace-relative POSIX path. {{ job.workspace }} is not valid in this field because the destination is already relative to that workspace. File contents are copied verbatim and are not rendered as templates. Use Place file in Runner workspace for configuration files whose contents require template rendering.

A folder sync accepts up to 100 files and 100 GiB of declared input. All source files must pass malware verification before placement starts. Ordyn validates every input before changing the target and performs pruning only after all requested files have been placed successfully.

Collect Runner Artifacts

Add Collect runner artifacts after the steps that produce build output. Each declaration has:

• a logical artifact name shown in the run
• a workspace-relative file, directory, or glob pattern
• a required setting that fails the step when no matching output exists

Literal files are uploaded directly. Directories and glob matches are packaged as ZIP archives before upload. Optional declarations may produce no artifact. Artifact paths cannot be absolute, traverse outside the managed workspace, or follow a symbolic link outside it.

While collection runs, the expanded step shows each phase: checking the Runner workspace, scanning the selected artifact files, creating the ZIP, checking the resulting workspace, verifying the artifact checksum, uploading it to Cache, and downloading it into Ordyn. Workspace and artifact scans use an indeterminate progress indicator until their total size is known.

Cancelling the job stops the active scan, ZIP creation, verification, or upload. Files produced by earlier Runner steps remain in the shared workspace until the job finishes, while incomplete collected artifacts are discarded.

A collector supports up to 100 declarations. Each collected artifact is limited to 100 GiB.

Choose an artifact expiry for the collection step. Available periods are no artifact expiry, one hour, one day, seven days, and 30 days. No artifact expiry retains the files until the infrastructure run is pruned. See Artifacts for browsing, bulk management, and expiry behavior.

Publish Artifacts To A Software Package

Publish artifacts to software package applies named artifacts from an earlier top-level Collect runner artifacts step to a selected software package. The publication step is a control step: the reserved Runner produces the artifacts, while Ordyn updates the package after checking the requester’s current permissions and the collected files.

Map each selected artifact to one destination:

• Primary installer replaces the package's main installer.
• Staged ZIP archive adds or replaces an archive that can be extracted by the package install workflow.

The editor manages staged-archive identities automatically. To use published offline content during installation, add Extract staged install archive to the package workflow and select the published ZIP.

Publication supports up to 100 mappings. A staged ZIP can contain up to 1,000,000 entries and up to 100 GiB of expanded content. Publishing identical bytes succeeds without changing package content or approval. Publishing changed bytes replaces the mapped assets and reapplies the software product's package-approval policy. Packages generated from Ordyn releases cannot be selected.

The source artifacts must be unexpired when this step runs.

Delete Collected Artifacts

Add Delete collected artifacts immediately after the final use of files from a collection or publication step. Select an earlier Collect runner artifacts step. The cleanup removes all artifacts produced by that step for the current run target and succeeds if they are already absent.

Build A WinPE Boot Image

Build WinPE boot image requires a Windows Runner with the Windows ADK deployment tools and the matching Windows PE add-on. Configure the WIMBoot image, Ordyn Agent release, output name and version, and optional driver profiles.

A successful run creates the managed boot image and shows its generated files as downloadable run artifacts.

See Runners for Runner requirements.

Download Offline Windows Update Catalog

Download offline Windows update catalog downloads Microsoft's current offline scan catalog and imports it into Ordyn. The task can run on a Windows or Linux Runner and supports offline inventory and the Ordyn repository installation source.

Schedule this task about once every seven days. Endpoint inventory and approved-update installation reject catalogs older than 45 days.

Download Approved Windows Updates

Download approved Windows updates prepares the Ordyn repository installation source. It downloads content referenced by current offline endpoint inventory for approved revisions. Missing content is downloaded from Microsoft on the Runner, imported into Ordyn, and submitted for malware verification.

Run this task after approvals change or schedule it regularly when automatic approval rules are enabled. The task reuses content that has already been imported.

See Windows Updates for the complete catalog, inventory, approval, content preparation, and endpoint installation workflow.

Refresh Intel ODCA Trust

Refresh Intel ODCA trust downloads the Intel ODCA root, intermediate certificate, and revocation list on the reserved Runner. The task can run on a Windows or Linux Runner and does not accept a custom URL or credentials.

The Runner must be able to reach tsci.intel.com over HTTPS. Ordyn validates the source locations, pinned Intel root, certificate chain, signatures, validity period, and revocation data before making the complete snapshot current. If the download or validation fails, the task fails and the previous current snapshot remains unchanged.

Run the job manually for an immediate refresh or add a recurring time automation. The Intel ODCA table under Administration > Services > Intel AMT links imported snapshots back to their job and Runner. See Intel AMT Infrastructure for the trust model and offline-import alternative.

Start A Run Manually

Open the infrastructure job and select Run job. Enter any prompted variable values and confirm the selected Runner pool to create one run. Leave a field untouched to use its effective inherited or job-level value.

The job validity windows apply to manual and automatic starts. A run that has already started continues when its start window closes.

Automations

Open an infrastructure job and select the Automations tab. This page contains the time and event automations for that job.

Time Automations

A time automation starts the infrastructure job:

• on a recurring cron schedule, or
• once at a selected date and time

Configure a name, schedule, timezone, and Enable state. Infrastructure schedules run once per due time and do not select endpoints or wait for an endpoint connection.

Job Completion Automations

A Job completed automation starts another infrastructure job after the current job reaches a selected terminal status.

Configure:

• the infrastructure job to run
• one or more matching outcomes: succeeded, failed, timed out, or aborted
• an optional maximum random delay from 0 to 3600 seconds

The current job is the source of the event. The selected job is the follow-up job. A job cannot use itself as its completion target.

Webhook Automations

A Webhook received automation starts the current infrastructure job when an infrastructure-scoped webhook accepts a request.

1. Open Administration > Services > Webhooks.
2. Create a webhook with scope Infrastructure.
3. Open the infrastructure job's Automations tab.
4. Add an event automation and select Webhook received.
5. Select the webhook and configure an optional maximum random delay from 0 to 3600 seconds.

The job receives the request context under trigger.webhook and configured webhook mappings under webhook.*. The incoming request does not choose the job, Runner pool, Runner, or endpoint.

See Webhooks for authentication, request mappings, and diagnostics.

Windows Update Approval Automations

A Windows update approved automation starts the current infrastructure job when one or more updates enter the approved state in any enabled Windows update ring. This includes manual approvals, automatic approvals, and existing approvals becoming active when a disabled ring is enabled.

Configure a debounce from 0 to 3600 seconds. The default is 60 seconds. Each additional approval resets the delay and is combined into the same run. The run uses the latest approval state when it starts, so clearing or rejecting an approval during the delay does not cancel the run.

If the job already has an active run from this automation, Ordyn keeps one combined follow-up run instead of starting an overlapping copy. The run context includes the approval count, affected ring IDs, approval sources, reasons, and the first and last event times.

This automation is useful for an infrastructure job containing Download approved Windows updates.

Monitor Runs

Open the job's Runs tab to review executions of that job. The list shows status, start time, duration, trigger, Runner context, and artifact count.

Open a run to review:

• current status, start time, and duration
• selected Runner and trigger
• each step's status, output, and error details
• run context
• downloadable artifacts produced by supported tasks

Run details update while the page is open.

Use Reporting > Job Runs to search and filter execution history across all endpoint and infrastructure jobs. See Job Runs Reporting.

Terminal infrastructure runs and their artifacts are retained for 90 days by default. The jobs.infrastructure_run_retention_days administration setting controls this period. Set it to 0 to keep terminal infrastructure runs without automatic age-based removal.

Abort A Run

Use Abort run from an active infrastructure run or from Reporting > Job Runs.

Aborting requests cancellation for the active Runner command and prevents remaining steps from starting. The run remains visible with its final status and recorded task output.

Job Settings

Infrastructure jobs show settings that apply to a single Runner-backed run:

• name and description
• Runner pool
• Runner platform
• container workspace path
• target timeout
• validity windows
• task error behavior

Endpoint assignments, endpoint requirements, shutdown policy, endpoint concurrency, durable result spooling, self-service settings, desktop execution, and user-interaction settings apply to endpoint jobs and are not shown for infrastructure jobs.

Permissions

Access depends on the assigned job and Runner permissions:

• Jobs Read views infrastructure jobs and run history.
• Jobs Create and Jobs Update create and edit infrastructure jobs.
• Jobs Run together with Runners Execute starts runs and manages infrastructure automations.
• Jobs Abort aborts active runs.
• Runners Read views pools and Runners.
• Webhooks Read is required when selecting a webhook for an automation.