Ordyn

Appearance

Windows Execution Contexts ​

Windows execution context controls which Windows identity Ordyn uses when it runs endpoint-side script and package work.

It applies to Windows endpoint scripts, Windows inline script job steps, package workflow commands, and package workflow inline scripts. It does not change server-side script execution.

Available Contexts ​

Local system ​

Runs as the Windows service identity:

  • NT AUTHORITY\SYSTEM

This is the most privileged local context on the endpoint. Use it for machine-level changes that do not need a human user's profile, mapped drives, or user-scoped registry hive.

When LocalSystem accesses a network resource from a domain-joined endpoint, the remote server usually sees the endpoint computer account:

  • DOMAIN\HOSTNAME$

That means SMB access only works when the share and NTFS permissions allow the computer account.

Local Ordyn installation user ​

Runs as Ordyn's managed local installation user, usually:

  • .\OrdynInst

This is the default for newly created Windows package workflows. It avoids running installers as the agent service identity while still giving Ordyn a controlled local account for software installation.

Use it for package installers and scripts that should not run as LocalSystem but also do not require a real interactive user's session.

Specific user ​

Runs with the normal logon token of a configured Windows account from the Windows accounts catalog.

Ordyn resolves the selected account's username and password secrets at runtime, then starts the process with those credentials. The target user does not have to be logged in.

Use it when a package or script must run as a known domain or local service account, especially when that account needs access to network resources.

This mode depends on valid stored credentials. If the referenced account or its secrets are missing, the task fails before execution.

This mode does not request elevation, even when the account is a member of the local Administrators group. On systems where User Account Control is disabled, Windows may provide an unrestricted token, so Ordyn cannot guarantee that the resulting token is filtered.

Specific user elevated ​

Runs elevated with a configured Windows account from the Windows accounts catalog.

Ordyn resolves the same stored username and password credentials as Specific user, but requires Windows to provide an elevated token. The target user does not have to be logged in.

Use it when work must run as a known account and explicitly requires that account's administrative token. The task fails before execution when the account cannot supply an elevated token or its stored account or secrets are unavailable.

Current active user session ​

Runs in the currently active signed-in Windows user session.

Ordyn does not use stored credentials for this mode. The agent asks Windows for the active console session token and runs the process in that session.

Use it when the work must happen in the user session that is currently active on the endpoint, for example user-profile changes or commands that need the active desktop user's environment.

The session is selected when execution starts. An event-triggered job or configuration-profile check is not bound to the session that produced the event. Delays or a user switch can therefore cause the work to run as a different console user, and a Remote Desktop event does not select its RDP session. Use Specific logged-in user when work must target a particular account rather than the active console user.

If no active signed-in user session exists, the task fails cleanly.

This mode does not request elevation. On systems where User Account Control is disabled, Windows may provide an unrestricted token, so Ordyn cannot guarantee that the resulting token is filtered.

Current active user session elevated ​

Runs with the elevated token associated with the currently active signed-in Windows user session.

Ordyn does not use stored credentials. The active user must have an elevated token available. If no active session exists or Windows cannot provide an elevated token for that user, the task fails cleanly.

Use it for work that must be visible in the active user's session and explicitly requires that user's administrative token.

Specific logged-in user ​

Runs in an existing logged-in Windows session matched by an identifier you provide.

Supported identifiers include:

  • DOMAIN\username
  • username@domain.example
  • .\username
  • HOSTNAME\username
  • username

Ordyn does not use stored credentials for this mode. The user must already have a Windows session on the endpoint. Active, connected, and disconnected sessions can be matched.

Use it on multi-user systems, such as terminal servers, when the task must run in one particular logged-in user's context instead of whichever session is currently active.

Bare usernames can be ambiguous when multiple domains or local users have the same username. In that case Ordyn fails the task and reports the ambiguity instead of guessing.

If the matching session cannot provide a user token, the task fails cleanly.

Choosing a Context ​

Use Local system for endpoint-wide machine operations where the service identity is acceptable.

Use Local Ordyn installation user for normal Windows package installation when no domain or human user identity is required.

Use Specific user when the task needs a known account and the user may not be logged in.

Use Specific user elevated when the task needs a known account's administrative token and the user may not be logged in.

Use Current active user session when the task should follow the currently active desktop user.

Use Current active user session elevated when the task should follow the currently active desktop user and requires that user's administrative token.

Use Specific logged-in user when the task must target one existing logged-in session on a multi-user endpoint.

Running an endpoint script on the active desktop ​

Windows PowerShell and CMD endpoint scripts, including saved and inline scripts, can target the existing active desktop in both Blocking and Non-blocking execution modes. This requires an active, signed-in, unlocked console session. Ordyn fails the step if the console session is unavailable or locked.

The selected execution context still controls the identity:

  • Current active user session uses the active user's normal token, while Current active user session elevated requires the active user's elevated token.
  • Local Ordyn installation user uses the managed installation account with its elevated token.
  • Specific user uses the configured account's normal logon token, while Specific user elevated requires the configured account's elevated token.
  • Specific logged-in user is accepted only when that user owns the active console session.
  • LocalSystem cannot target the existing active desktop.

A GUI executable started by the script can create visible windows on the active desktop. The script interpreter remains hidden. Console applications started by the 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. A custom Windows launcher can request this with the CREATE_NEW_CONSOLE process creation option.

In Blocking mode, Ordyn waits for the interpreter, captures its output and exit code, and enforces timeout and cancellation. Blocking controls whether Ordyn waits for completion; it does not make the interpreter or a child console window visible. If the script launches a GUI process asynchronously, make the script wait for it, for example with PowerShell's Start-Process -Wait, when the job must wait too. In Non-blocking mode, Ordyn confirms only that the interpreter started and does not track later output, failures, or process completion.

Limitations ​

User-session contexts require an existing Windows session token. They cannot start a process for a user who has no session unless credentials are supplied through one of the specific-user modes.

Desktop logon and GUI automation managed-login flows only support contexts that can supply credentials or Ordyn's managed installation user. The current-active-user-session modes and Specific logged-in user are for running work in existing sessions, not for creating new desktop logons.

Network drive mappings are session-scoped on Windows. A drive mapped in one user context is not automatically available in another context. Prefer UNC paths in scripts and package commands when possible.