Packages

Package workflows are the editor-authored workflows that install, uninstall, and update software. Use this page as the overview for package workflows and follow the step catalog on Available Steps.

For the editor-visible step catalog, see Available Steps.

What package workflows do

Package workflows let admins define the ordered steps that install software, remove software, run scripts, collect artifacts, and handle interactive Windows automation.

Windows package commands and inline scripts use a Windows execution context. See Windows Execution Contexts for the available identities and when to use each one.

GUI replay workflow steps use Manage desktop preparation by default. Ordyn expands those steps into visible desktop readiness, inspection, logon, lock, replay, and cleanup tasks at runtime. Disable managed preparation only when the workflow explicitly contains the desktop-control steps itself. Replay GUI automation is not supported inside workflow For each or While loop bodies.

If the endpoint agent restarts during package-file staging, staged archive extraction, or a managed desktop-readiness wait, Ordyn retries that preparation step after the agent reconnects. Recovery is limited to three attempts within 30 minutes; package install, uninstall, script, and GUI replay steps are not automatically repeated by this recovery.

Software product detection policies

Ordyn uses software inventory to decide whether a managed software product is installed and whether a newer managed package is available.

The default matcher is conservative:

• it compares the inventory row against the product name, product aliases, package match name, package match aliases, and package name
• it uses publisher and architecture where available to reduce the candidate set
• it ignores technical suffixes such as architecture, locale, bitness, and obvious trailing versions
• it keeps product-distinguishing words such as desktop, runtime, host, sdk, client, and redistributable
• it can parse obvious version and architecture hints from inventory names after the name match already passed

This means a product can match inventory names like Contoso Desktop Runtime - 8.0.26 (x64) without treating sibling components such as Contoso Runtime or Contoso Host as the same product.

Product aliases

Use product aliases when the same product is known by another display name.

Aliases add more names for the default matcher to score. They do not bypass publisher, architecture, version, or name-score checks.

Good alias examples:

• vendor rebranded the application
• Windows inventory reports a longer marketing name
• the package source uses a shorter product name than Add/Remove Programs

Detection policy rules

Detection policy rules are eligibility gates for a product. They do not add extra names to the matcher.

Rules can check these inventory fields:

• name
• publisher
• version
• architecture

Supported operators are:

• exact
• contains
• regex

Evaluation order:

1. exclude rules run first
2. if any exclude rule matches, the product is rejected
3. if include rules exist, at least one include rule must match
4. if the product is still eligible, the default matcher still runs

Use include rules to narrow a product family when only some inventory rows should be eligible. Use exclude rules to block sibling components that share the same publisher and many name tokens.

For example, a desktop runtime product can include name contains Desktop Runtime and exclude name contains Host if that vendor reports multiple runtime-family components.

Inventory version parsing policy

Some Windows inventory rows report versions in a format that is not directly comparable to managed package versions. For example, the inventory version field can contain a vendor prefix such as ad 9.0.10, or the MSI version field can contain a build number while the human-readable product version is embedded in the inventory name.

Inventory version parsing rules let a product extract:

• the effective version
• the effective architecture

from an inventory field using a regex.

The parsed value is used for product matching and software update planning. It does not rewrite the raw inventory row. The endpoint inventory still shows the original value reported by Windows, while Ordyn can compare the parsed effective version to managed package versions.

Product-specific inventory version parsing rules take precedence over Ordyn's default name parsing. If no product-specific rule matches, Ordyn falls back to the generic parsed version and architecture hints from the inventory name.

Use inventory version parsing when the default parser cannot identify the right installed version or when a vendor-specific inventory format needs stricter handling.

Version comparison and channels

Ordyn compares managed package versions against an effective inventory version:

• first, a product-specific inventory version parsing rule can extract the version
• otherwise, Ordyn may parse an obvious version from the inventory name
• otherwise, Ordyn uses the raw inventory version value

Ordyn also uses the effective version to select product channels. Numeric channels such as 6, 6.x, 8, or 8.x are treated as major-version boundaries by default. If the effective installed version starts with major 6, Ordyn does not select an 8.x variant for matching or updates.

Software update policies can relax this by enabling Allow channel upgrades. With that option enabled, update planning may cross compatible product variants and install the latest eligible package across channels. Endpoint software inventory matching remains strict because it has no policy context.

For example, Microsoft .NET Desktop Runtime can report raw Windows inventory versions such as 48.128.16742 while the product version is embedded in the name:

Name: Microsoft Windows Desktop Runtime - 6.0.32 (x64)
Version: 48.128.16742

Ordyn parses 6.0.32 from the name and keeps that row on the 6.x channel. A policy scoped to an 8.x package will not update this row to .NET 8 unless channel upgrades are explicitly allowed. A row named Microsoft Windows Desktop Runtime - 8.0.26 (x64) can match the 8.x channel and compare against managed packages such as 8.0.27.

Example for an inventory row where name = AnyDesk and version = ad 9.0.10:

Field: version
Pattern: ^ad\s+(?P<version>\d+(?:\.\d+)+)$
Version group: version
Architecture group:

This keeps the displayed inventory version as ad 9.0.10, but update planning uses 9.0.10 as the effective version.

The preview sidebar in the policy editor is a regex test helper. Type or paste a sample inventory row into Name, Publisher, Version, and Architecture; the preview shows what the current parsing rules would extract from that sample.

Discovery version parsing policy

Package discovery has a separate version parsing policy. Discovery parsing rules normalize versions found during scans before Ordyn compares the result to known package versions or imports a downloaded artifact.

Discovery rules can use these fields:

• discovered_version: the version reported by package discovery
• artifact_name: the resolved or downloaded installer filename
• artifact_url: the resolved installer URL

Use discovery version parsing for vendor-specific download formats, such as compact installer names where the actual product version is encoded in the filename.

Example for an Adobe Reader-style artifact name:

Field: artifact name
Pattern: ^AcroRdrDCx64(\d{2})(\d{3})(\d{5})_MUI\.exe$
Version template: $1.$2.$3

For AcroRdrDCx642600121529_MUI.exe, this produces 26.001.21529.

Use Version template when the version is encoded across unnamed capture groups or needs a rewrite. Templates are rendered from capture groups only; unmatched source text is not preserved. Supported forms include $1, $2, $version, and ${version}.

Use product discovery version parsing rules to normalize discovered versions before Ordyn compares scan results or imports downloaded artifacts.

Built-in updater policy

Built-in updater policies detect whether installed software manages its own updates.

Configure this on the software product's policy tab. Ordyn sends the configured rules to Windows endpoints during software inventory. The agent evaluates the rules and stores the result with the software inventory snapshot.

When a detected inventory row reports built-in updating as enabled:

• the endpoint software inventory shows a self-updating badge for that row
• software update policies with Exclude self-updating software enabled skip that installed product during update planning

No rules means the built-in updater policy is disabled for the product.

Registry rules

Use registry rules when the vendor exposes a stable machine-wide setting.

Registry rules check:

• HKLM
• the configured registry path
• the configured value name
• the selected registry view: default, 32-bit, 64-bit, or both

HKCU is intentionally not supported for this policy. Inventory runs under the Ordyn agent service context, so HKCU would point at the service account hive, not the signed-in user's hive.

The agent reads the value and compares it against the configured enabled and disabled values. Comparisons are case-insensitive after trimming whitespace.

Example:

Hive: HKLM
Path: Software\Policies\Vendor\Product
Value name: DisableAppUpdate
Registry view: both
Enabled values: 0
Disabled values: 1

In this example, DisableAppUpdate = 0 means the product's own updater is enabled, while DisableAppUpdate = 1 means it is disabled.

PowerShell rules

Use PowerShell rules when registry values are not enough or the vendor stores the setting in a config file.

The script must print one JSON object to stdout:

{"enabled": true, "evidence": "AutoUpdate=1"}

Supported fields:

• enabled: true, false, or null
• status: optional explicit status such as enabled, disabled, or unknown
• evidence: optional human-readable evidence shown with the inventory result

The script runs non-interactively on the endpoint during software inventory and is capped by the configured timeout.

MSI baselines and MSP patch chains

Use an MSI/MSP Windows product variant when a vendor publishes a full MSI and then releases MSP patches for that MSI.

Create the packages in release order:

1. create the full MSI as package type MSI baseline
2. create each MSP as package type MSP patch
3. select the immediately preceding package for every MSP

Each MSI or MSP package needs its own version. MSP packages use exact version mode and the Install only upgrade strategy. A new full MSI starts a new baseline and does not point to the earlier patch chain.

Patch chains are strictly linear. A package can have only one next patch, and an MSP cannot skip an intermediate package. Ordyn prevents deletion of a package that a newer MSP requires.

When an endpoint needs the latest package, Ordyn plans the required chain in order:

• a fresh install receives the MSI baseline followed by every MSP in the chain
• an endpoint already matching a package in the chain receives only the missing MSP suffix
• an endpoint that does not match an ancestor in the selected chain receives the full baseline and patch chain

Every missing package in the chain must be installable and eligible. Required links must be approved unless the policy allows pending packages, and an explicitly excluded link blocks every newer patch that depends on it. The update preview shows the package install chain for each planned update.

MSI small updates that keep the same product version are not supported. Assign a distinct package version to every imported or manually created MSP.

Inventory-based uninstall commands

Ordyn does not automatically execute uninstall commands reported by endpoint inventory.

For uninstall workflows, the latest software inventory row is available as runtime data. A run package command step can explicitly reference that data through template values:

• {{ inventory.uninstall_string }}
• {{ inventory.quiet_uninstall_string }}
• {{ inventory.msi_product_code }}
• {{ inventory.registry_key_name }}
• {{ inventory.install_location }}

The same values are also exposed as environment variables:

• ORDYN_SOFTWARE_INVENTORY_UNINSTALL_STRING
• ORDYN_SOFTWARE_INVENTORY_QUIET_UNINSTALL_STRING
• ORDYN_SOFTWARE_INVENTORY_MSI_PRODUCT_CODE
• ORDYN_SOFTWARE_INVENTORY_REGISTRY_KEY_NAME

Use this when a package should remove software using the endpoint's Add/Remove Programs metadata instead of an Ordyn-hosted installer file.

Example MSI uninstall command:

msiexec.exe /x "{{ inventory.msi_product_code }}" /qn /norestart

Example quiet uninstall command:

{{ inventory.quiet_uninstall_string }}

Leave Download package file disabled for inventory-based uninstall commands. If a command needs the package file, Ordyn must have a matching managed package with that file available.

For software update packages using the Uninstall then install upgrade strategy, Ordyn chooses the uninstall workflow this way:

1. if the installed version matches a managed package, Ordyn uses that matched package's uninstall workflow
2. otherwise, Ordyn falls back to the latest package's uninstall workflow
3. the fallback is only allowed when the uninstall workflow does not require the package file

This means an installed version does not need to exist as its own managed package if the latest package contains a generic, fileless uninstall workflow that references inventory metadata. If the installed version is not represented in Ordyn and the latest package's uninstall workflow requires the package file, update planning skips the uninstall/install action because it cannot safely remove the installed version.

If the inventory row does not contain the referenced uninstall value, the template resolves to an empty string. Add explicit checks or branch logic in the workflow when missing uninstall metadata should produce a controlled failure or fallback path.

Software update policies

Software update policies define which managed products and packages are eligible when an update job plans software updates for an endpoint.

Open Software > Products, then use the software update policies view to create, edit, preview, or delete policies.

Policy scope

A policy can apply to all packages or to a package folder. Use folder scope when different package collections need different update behavior.

Eligibility controls

Policies can limit update planning by:

• included products
• excluded products
• included publishers
• included packages
• excluded packages

If no products or publishers are selected, all matching managed products remain eligible. If included packages are selected, update planning is limited to those packages after the product and publisher rules are applied. Excluded products and packages always remove those entries from the result.

Update behavior

Use these options to control how aggressive the policy is:

• Allow channel upgrades: lets the update planner cross product channels when a compatible package is available.
• Allow pending approval packages: lets packages that are still pending approval participate in the plan.
• Exclude self-updating software: skips inventory rows where Ordyn detected that the product manages its own updates.
• Continue remaining packages after failure: keeps processing other package updates if one selected package fails.

Leave channel upgrades disabled when major-version boundaries should stay fixed. Enable pending approval packages only when your package review process allows those packages to run on targeted endpoints.

Previewing a policy

The policy detail page includes an endpoint preview. Select an approved endpoint and refresh the preview to see the software update plan that the policy would produce for that endpoint.

Use the preview before assigning a policy to jobs or automations. It helps confirm that product matching, channel selection, package approval, and exclusion rules produce the expected update set.

Deleting policies

Deleting a software update policy removes it from selection. Jobs that still reference the deleted policy need another policy before they can run successfully.

Step run conditions

Every package workflow step can be configured with a run condition:

• on_success
• on_failure
• always

Use always for cleanup or diagnostics that should still run after a failed install or uninstall. The other two conditions let you keep the step gated to the success or failure path that matters.

Exit-code mappings

run package command, saved script, and inline script steps can define exit_code_mappings.

Each mapping selects how Ordyn should interpret a process exit code:

• success
• success_reboot_required
• failure

Ordyn evaluates these mappings after the executor reports the raw exit code. This keeps package and job behavior consistent across endpoint scripts, Runner scripts, inline scripts, and package commands.

Typical Windows reboot-required mappings are:

• 3010
• 1641

Exit code 0 is added as success by default when no mappings are configured.

For Linux endpoints, Ordyn also performs a best-effort reboot check after successful package workflow execution:

• on Debian-family systems it first checks the standard reboot marker file such as /var/run/reboot-required
• if needrestart is available, it is used for additional reboot-needed detection
• if needrestart is missing, the agent logs a warning and continues without failing the workflow
• when no reliable reboot signal is available, reboot-required remains unknown

This reboot signal is propagated back into job task results, so later if tasks can branch on it.

Publishing Package Content From An Infrastructure Job

An infrastructure job can prepare vendor offline-installation content on a Runner and publish the resulting artifacts into an existing software package. This is useful when a vendor downloader must run before an endpoint can install the software.

Build the infrastructure job with these steps:

1. Sync file folder in Runner workspace for a maintained folder of vendor inputs, or individual Place file in Runner workspace steps for the downloader and configuration files. A downloader already stored as the package's primary file can be selected directly from that software package.
2. A Runner script that downloads the offline content into a workspace-relative directory.
3. Collect runner artifacts with stable names for the primary installer and offline-content directory. Ordyn packages a collected directory as a ZIP.
4. Publish artifacts to software package, selecting the earlier collector and mapping its named artifacts.

Map the executable or installer to Primary installer. Map offline payloads to Staged ZIP archive. The package install workflow must include Extract staged install archive before a command that needs files from the ZIP. Publishing the ZIP attaches it to the package; extraction happens on the endpoint during the package workflow.

Endpoint package workflows share {{ job.workspace }} with the surrounding endpoint job. Archive extraction preserves the ZIP's paths below that workspace, file-placement steps can add configuration files there, and package commands start there. {{ package.directory }} resolves to the same workspace. {{ package.path }} points to the verified primary installer after the workflow stages that file.

Enable Download package file on a package command that uses {{ package.path }}.

For example, when the published ZIP contains content\Office\... and the workflow places config.xml in the workspace, a Windows package command can run:

"{{ package.path }}" /configure config.xml

The Office configuration's SourcePath can reference {{ job.workspace }}\content. The content directory in this example comes from the collected Runner directory and is not added by archive extraction.

The Runner handles files in its managed workspace and returns normal job artifacts. The publication step applies those artifacts to the selected package.

Publishing identical bytes leaves package content and approval unchanged. Publishing changed bytes replaces the mapped package assets and applies the software product's configured package-approval policy.

See Infrastructure Jobs for the complete Runner workflow and limits.

Package-file staging

Use Stage package file when a later workflow step needs a package file in the shared endpoint workspace. Select one of these package contents:

• Primary file stages the uploaded installer and makes its verified absolute path available as {{ package.path }} to later steps.
• Staged install archive stages the selected ZIP as a file. Use a later Extract staged install archive step when the workflow needs the ZIP's contents.

An inline script that references {{ package.path }} must follow a Stage package file step for the primary file on every branch that can reach the script. Staging inside a loop does not make the path available after the loop.

Run package command and Replay GUI automation also provide a Download package file option. When enabled, Ordyn stages the primary file immediately before that step. Install commands enable the option by default; uninstall commands and GUI replay leave it disabled by default.

Extract staged install archive prepares its selected archive as part of the extraction step, so a separate staging step is not required for that archive.

Each staging operation verifies the selected file's exact size and checksum before making it available in the workspace. When several steps request the same revision at the same time, Ordyn stages one verified copy. A failed or incomplete transfer is discarded.

Staging defaults to a 14400 second timeout when no explicit workflow or job timeout is configured. An active transfer can continue for up to 28800 seconds. An explicit step timeout remains a hard limit.

If the endpoint restarts before staging reports a result, Ordyn retries that step after the agent reconnects. Automatic recovery is limited to three attempts within 30 minutes. Completed steps are preserved.

Fileless packages and UNC-path installs

Packages do not need an uploaded Ordyn-hosted file when their workflows only use commands or scripts.

This is useful for Windows environments where software is installed directly from a network share, for example:

• \\\\fileserver\\business-apps\\Contoso\\setup.exe /quiet /norestart
• Start-Process "\\\\fileserver\\business-apps\\Contoso\\setup.exe" -ArgumentList '/quiet /norestart' -Wait

To build this kind of package:

1. leave the package file empty
2. use Run package command or Run inline script
3. leave Download package file disabled on commands and do not reference {{ package.path }} in inline scripts

The workflow then runs directly against the command or script you authored without staging a package file.

Windows authentication model

For this feature, Ordyn does not store SMB credentials and does not impersonate the interactive user.

On Windows, newly created package workflows default to the Ordyn installation user (OrdynInst). This is the safer default for package execution because it avoids running installer commands as the agent service identity unless that is explicitly selected.

For the full execution-context model, including LocalSystem, stored credential accounts, active user sessions, and specific logged-in user sessions, see Windows Execution Contexts.

LocalSystem remains available as an explicit Windows execution context. When a domain-joined endpoint accesses an SMB share as LocalSystem, the remote server typically sees the endpoint's computer account:

• DOMAIN\\HOSTNAME$

That means this setup works when:

• the endpoint is domain-joined
• the SMB share and NTFS permissions grant access to the endpoint computer account

This setup does not help when the share is only available to human users or other identities that the agent service does not hold.

Where to go next

• Available Steps