Windows Execution Contexts

Windows execution context controls which Windows identity Ordyn uses when it runs endpoint-side scripts, package work, and GUI automation.

It applies to Windows endpoint scripts, Windows inline script job steps, package workflow commands, and package workflow inline scripts.

Windows Runner scripts use the Runner service identity and do not use an endpoint Windows execution context.

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.

Templated user

Runs with the normal logon token of credentials selected directly from the variable catalog.

Select a plain string variable for the username and a secret string variable for the password. In a job, Ordyn resolves both variables from the complete context of the task, including applicable endpoint, product, package, job, and submitted run values. This makes it possible to prompt for credentials when starting a job or select credentials that vary by package or endpoint. When the same resource is executed directly outside a job, the variables resolve for the target endpoint.

The target user does not have to be logged in. This mode does not request elevation. The task fails before execution if either variable is missing, has the wrong type or secrecy setting, or does not resolve to a usable value.

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.

Templated user elevated

Uses the same variable selection and task-context resolution as Templated user, but requires Windows to provide an elevated token for the resolved account.

Use it when credentials must come from task variables and the work requires an administrative token. The task fails before execution if the variables cannot be resolved or the account cannot supply an elevated token.

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 Templated user when the username and password should resolve from the task's variables, including job prompts or package-specific values.

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

Use Templated user elevated when variable-backed credentials must run with an administrative token.

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.

Session reuse within a job

Credential-backed Windows tasks in the same job target reuse a Windows logon session when they use the same Windows Account or the same templated username/password variable pair, resolve to the same Windows user, and use the same normal or elevated mode. This applies across endpoint scripts, package commands and scripts, and GUI automation replay.

For example, a drive mapped by an earlier script is available to a later matching package or GUI replay task in that job target. A task that uses another account or switches between normal and elevated execution starts a separate logon session.

Sessions are not shared between job runs or target endpoints. An agent restart or endpoint restart also starts a fresh session. Contexts that target an existing signed-in user continue to use that user's actual Windows session.

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.
• Templated user uses the resolved variable-backed account's normal logon token, while Templated user elevated requires that 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 support Windows Accounts, templated users, and 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. Matching credential-backed tasks can reuse mappings within one job target as described above, but mappings are not available across session boundaries. Prefer UNC paths in scripts and package commands when possible.