Ordyn

Appearance

OS Images ​

OS images are the editor-authored images and workflows that Ordyn uses for operating-system deployment and in-place upgrades.

Use this page as the overview for OS image workflows and follow Available Steps for the step catalog.

What OS image workflows do ​

OS image workflows let admins define what happens in WinPE during Windows installation and what happens on an already installed Windows system during an upgrade. Linux boot images can also be used for PXE handoff into a Linux installer with an install answer file.

A Linux boot image requires an installer kernel, an installer initrd, and a distribution-signed UEFI shim. For Debian amd64, upload linux, initrd.gz, and bootnetx64.efi from the same netboot installer tree. See Net for the complete setup.

Ordyn keeps the two workflow types separate:

  • install workflows run in the installer environment
  • upgrade workflows run on the existing Windows installation

Use OS images when you want repeatable operating-system deployment behavior instead of one-off manual imaging steps.

Common OS image work includes:

  • installing Windows from WinPE
  • booting a Linux installer through PXE with an install answer file
  • applying driver bundles
  • partitioning and preparing disks
  • joining the target system to the intended configuration flow
  • running post-install scripts
  • starting an in-place Windows upgrade

Authoring ​

Each OS image has a name, version, platform, source content, and workflow configuration where that image kind supports workflows.

The workflow editor lets you add steps, reorder them, configure step parameters, and use conditions where the deployment should branch. OS image workflows use the same expression and variable model as jobs and package workflows, so admins can use endpoint context and variables in supported fields.

Use clear step names when building longer workflows. The names appear in job and endpoint history, which makes troubleshooting much easier after a deployment run.

Install workflows ​

Install workflows run while the endpoint is in the installer environment.

Typical install workflows prepare storage, apply the selected Windows image, copy required assets, inject or stage drivers, and configure first-boot behavior.

Use install workflows for:

  • bare-metal provisioning
  • reinstallation
  • lab or kiosk refresh workflows
  • repeatable device staging

Upgrade workflows ​

Upgrade workflows run from the installed Windows operating system.

Use upgrade workflows for in-place Windows upgrades where the endpoint should keep its existing installation and data while moving to a newer Windows image.

Upgrade image downloads ​

For in-place upgrades, Ordyn generates a visible download step before running the upgrade command when the endpoint needs the OS image locally. That step downloads the image from the assigned cache node and verifies it with the signed cache manifest.

The agent publishes the image only after its exact size and SHA-256 checksum match. HTTPS, timeout, disk-headroom, and atomic-publication limits are listed under Agent Runtime Limits.

Generated OS image downloads default to a 14400 second timeout when no explicit timeout is configured. While the agent reports signed download progress, Ordyn refreshes the instruction expiry so slow but active ISO downloads can continue. The refreshed runtime is capped at 28800 seconds from the original issue time. If the workflow/job step has an explicit timeout, Ordyn treats that timeout as the hard cap.

OS image deployment commonly uses these related areas:

  • Cache Nodes, for OS image and boot asset delivery
  • Net, for PXE, Wake-on-LAN, and local-network boot handoff
  • driver profiles, for model-specific driver bundles
  • install answer files, for setup behavior
  • Variables, for environment-specific values

Troubleshooting ​

When a deployment fails, check:

  • the endpoint history for the OS image run
  • the job history for the generated deployment job
  • the cache node assignment and cache node reachability
  • the Net service used by the target network when PXE or Wake-on-LAN is involved
  • the step that failed and the command or script output recorded for that step

For deeper troubleshooting, create an Endpoint support bundle for the affected endpoint and time range.

Where to go next ​