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 a generated package download, staged archive extraction, or managed desktop-readiness wait, Ordyn waits for replay synchronization and retries that preparation step. Recovery is limited to three attempts within 30 minutes; package install, uninstall, script, and GUI replay instructions 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.

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

Keep requires_package_file = false for inventory-based uninstall steps. 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 on the server after the agent reports the raw exit code. This keeps package and job behavior consistent across endpoint scripts, inline scripts, package commands, and server-side scripts.

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.

Generated preparation steps

Package workflows can reference the uploaded package file through run package command steps with requires_package_file = true.

When that is needed, Ordyn automatically injects visible runtime preparation steps before the first package-file-dependent step:

1. sync package to cache
2. download package to endpoint

These are generated execution steps, not user-authored workflow steps. They are visible in job history so operators can see cache-sync or download failures directly, but they are not configurable in the package editor.

The endpoint download step uses the assigned cache node and defaults to a 14400 second timeout when no explicit workflow/job timeout is configured. During the transfer the agent sends signed download progress, and Ordyn refreshes the instruction expiry while progress is still arriving. This prevents slow but active package downloads from failing on the normal 300 second instruction TTL. The refreshed runtime is capped at 28800 seconds, and an explicit step timeout remains a hard cap.

If the endpoint restarts before a generated package download reports a result, Ordyn retries that preparation step after the agent reconnects and synchronizes replay protection. Automatic recovery is limited to three attempts within 30 minutes. A result already reported by the agent or a durable execution is preserved.

If all relevant workflow steps keep requires_package_file = false, no cache sync or endpoint download step is generated.

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. keep requires_package_file = false on those steps

Ordyn then treats the package as a normal package with no download step. The workflow runs directly against the command or script you authored.

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