Configuration Profiles

Configuration profiles are Ordyn's endpoint-focused way to keep a device in a desired state.

Use them when one-off jobs are not enough and you want Ordyn to keep checking whether an endpoint still matches the expected configuration.

What they are for

Profiles let you:

• define a desired state once
• assign that state to a tenant, folder, group, or single endpoint
• choose how Ordyn should react when an endpoint drifts
• review compliance from the endpoint's Configuration Profiles view

Profile types

Ordyn currently supports eight profile types.

Windows Update Policy

Use this when you want Ordyn to manage Windows Update settings on Windows endpoints.

The profile can configure:

• automatic update mode
• scheduled install day
• scheduled install time
• update source (Microsoft Update / Windows Update or WSUS)
• the WSUS URL
• whether automatic reboot is blocked while a user is signed in
• whether interactive users can scan for, download, or install updates through Windows Update
• which Windows Update notifications are shown to users

This type only applies to Windows endpoints.

Set Windows Update user access to Blocked to remove interactive access to Windows Update scan, download, and installation. This applies to all interactive users, including administrators. Ordyn jobs continue to install approved updates through the endpoint service.

Windows Update notifications controls notification visibility independently from installation and restart timing:

• Use default Windows Update notifications keeps the standard Windows experience
• Show restart warnings only hides other update notifications while retaining warnings that a restart is required
• Turn off all Windows Update notifications also hides restart warnings

Leave the setting on Not managed when Windows, Group Policy, or another management system should control notification visibility. This setting does not cause Ordyn to restart an endpoint.

Registry values

Remediation writes Windows Update policy values below these keys. Audit-only runs read the current state without changing it.

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

The profile creates these keys when required. A Windows Update setting configured as Not managed is not written or removed by that profile run.

Profile setting	Registry value	Type	Data
Automatic update mode	AU\NoAutoUpdate	REG_DWORD	1 for Disabled; 0 for every other managed mode
Automatic update mode	AU\AUOptions	REG_DWORD	1 disabled, 2 notify before download and install, 3 auto-download and notify before install, 4 auto-download and scheduled install, 5 local administrator choice, or 7 download only
Scheduled install day	AU\ScheduledInstallDay	REG_DWORD	0 every day, 1 Sunday, 2 Monday, 3 Tuesday, 4 Wednesday, 5 Thursday, 6 Friday, or 7 Saturday
Scheduled install time	AU\ScheduledInstallTime	REG_DWORD	Hour of day from 0 through 23
Update source	AU\UseWUServer	REG_DWORD	0 for Microsoft Update / Windows Update or 1 for WSUS
WSUS URL	WUServer	REG_SZ	Configured WSUS URL
WSUS URL	WUStatusServer	REG_SZ	Configured WSUS URL
Auto reboot with signed-in user	AU\NoAutoRebootWithLoggedOnUsers	REG_DWORD	1 blocked or 0 allowed
Windows Update user access	SetDisableUXWUAccess	REG_DWORD	1 blocked or 0 allowed
Windows Update notifications	SetUpdateNotificationLevel	REG_DWORD	0 default notifications, 1 restart warnings only, or 2 no notifications

AU\... identifies a value below the WindowsUpdate\AU key. Values without that prefix are below the WindowsUpdate key. Selecting Microsoft Update / Windows Update as the update source also removes WUServer and WUStatusServer. The profile does not write the non-policy Windows Update keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\WindowsUpdate.

Windows Delivery Optimization

Use this to control Microsoft content downloads and Windows peer-to-peer content sharing independently from update approval.

The profile supports these download modes:

• HTTP only (no peer sharing) downloads content without using peers
• Local network peers allows sharing with peers on the local network
• Private peer group limits peer sharing to endpoints configured with the same peer group ID

Optional settings control:

• maximum cache age in days
• maximum cache size as a percentage of disk space
• minimum file size eligible for caching
• whether peer sharing is allowed over VPN

The private peer group mode requires a peer group ID. Assign the same ID to endpoints that should share content within that group.

This type applies only to Windows endpoints. If Delivery Optimization is controlled by GPO, MDM, or another provider, remediation reports an error and makes no policy changes.

Delivery Optimization controls download behavior. Use Windows Updates to define rings and approve Microsoft updates.

Registry values

Remediation writes Delivery Optimization policy values below this key. Audit-only runs read the current state without changing it.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization

Profile setting	Registry value	Type	Data
Download mode	DODownloadMode	REG_DWORD	0 HTTP only, 1 local network peers, or 2 private peer group
Peer group ID	DOGroupId	REG_SZ	Configured peer group ID; removed outside private peer group mode
Maximum cache age	DOMaxCacheAge	REG_DWORD	Configured days converted to seconds
Maximum cache size	DOMaxCacheSize	REG_DWORD	Configured percentage
Minimum file size	DOMinFileSizeToCache	REG_DWORD	Configured megabytes converted to bytes
VPN peering	DOAllowVPNPeerCaching	REG_DWORD	1 allowed or 0 blocked

Optional values are removed when their settings are not managed. Ordyn also creates the empty ownership marker key HKEY_LOCAL_MACHINE\SOFTWARE\Ordyn\ConfigurationProfiles\WindowsDeliveryOptimization. The marker lets later runs distinguish policy managed by this profile from policy supplied by GPO, MDM, or another provider.

Windows Firewall Policy

Use this when you want Ordyn to manage the built-in Windows Firewall state on Windows endpoints.

The profile can configure the firewall state for each Windows network profile:

• domain
• private
• public

Each network profile can be set to:

• enabled
• disabled
• unmanaged

Unmanaged profiles are left out of the desired state. Ordyn only checks and remediates the zones that are explicitly managed by the profile.

At least one firewall zone must be managed. This avoids creating a profile that cannot check or remediate anything.

This type only applies to Windows endpoints. The agent reads the current state through Windows Firewall profile data and remediation updates the managed profiles to the requested enabled or disabled state.

Windows Firewall Rules

Use this when you want Ordyn to check or enforce the versioned local PersistentStore firewall rules configured for each Windows endpoint.

This profile has no rule fields and no policy selector. Each matching endpoint uses the active policy from its own Firewall tab. Configure assignments normally and select the required behavior:

• Audit only checks the endpoint rules without changing them
• Remediate checks the endpoint rules and applies the active endpoint policy when supported local rules have drifted

Saving or restoring rules in the endpoint Firewall tab creates an active revision without starting a profile run. Assigned profiles use that revision the next time they check or remediate the endpoint.

Ordinary rules are enforced completely. For Windows predefined or protected rules, Ordyn manages only whether the rule is enabled. Unsupported rules prevent remediation before any endpoint changes are made.

Initialize each endpoint's firewall policy with the Import Windows Firewall rules job task before assigning enforcement. An endpoint without a firewall policy reports a configuration error. More than one Windows Firewall Rules profile can apply to the same endpoint, and each matching profile runs independently.

This type applies to supported Windows endpoints only. See Windows Firewall Rules for supported rules and limitations.

Windows Security Policy

Use this to audit or enforce selected Windows authentication, credential, and remote-access safeguards.

The profile can manage:

• virtualization-based security (VBS) and its platform-security requirement
• Credential Guard
• Memory Integrity (HVCI)
• LSA protection
• User Account Control enablement, elevation prompts, secure desktop, signed elevation, UIAccess, installation detection, and virtualization
• cached interactive logon count
• LAN Manager and NTLM authentication level, inbound and outbound restrictions, auditing, server exceptions, NTLMv2 session security, and 128-bit encryption requirements
• Remote Desktop availability, Network Level Authentication, security layer, encryption level, secure RPC, password prompting and saving, drive redirection, and clipboard redirection

Every setting starts as Not managed. Ordyn checks and changes only the settings selected in the profile, and at least one setting must be managed.

Microsoft Defender remains inventory-only. Windows Security Policy profiles do not change Defender antivirus, real-time protection, cloud protection, sample submission, signatures, or tamper protection.

Some choices require a safety acknowledgement before the profile can be saved. These include UEFI-locked protection, authentication restrictions, disabling cached logons, disabling Remote Desktop, stricter application-signing behavior, and values that reduce a security safeguard. The acknowledgement records the operator's review and is not sent to the endpoint.

Credential Guard, Memory Integrity, and LSA protection can be enabled with or without a UEFI lock. A UEFI lock is intentionally resistant to remote removal. Ordyn refuses a profile change that would disable or unlock a control currently reported as UEFI-locked; remove the firmware variable locally before applying that change.

Changes to VBS, Credential Guard, Memory Integrity, LSA protection, and UAC enablement can require a restart. Ordyn does not restart the endpoint automatically. The remediation result shows Restart required and its reasons. For VBS, Credential Guard, Memory Integrity, and LSA protection, later checks continue to report the requirement while the previous runtime state remains active.

Cached logon policy does not apply to domain controllers. A profile that manages the cached logon count is marked incompatible with an endpoint reporting the Active Directory Domain Services role.

Group Policy, MDM, or another security-management product can override the same Windows settings. A later check reports drift when the effective endpoint configuration does not match the profile.

Windows SMB Hardening

Use this to audit or enforce SMB client and SMB server safeguards independently.

SMB client settings include:

• SMB1 client protocol state
• required signing and encryption
• insecure guest logon behavior and auditing
• NTLM blocking and server exceptions
• minimum and maximum SMB 2/3 dialects
• auditing for servers that do not support signing or encryption

SMB server settings include:

• SMB1 and SMB2-or-later protocol state
• required signing
• server data encryption and rejection of unencrypted access
• SMB1 and insecure guest logon auditing
• invalid-authentication response delay
• minimum and maximum SMB 2/3 dialects
• auditing for clients that do not support signing or encryption

Every setting starts as Not managed, and at least one setting must be managed. Select System default for a dialect boundary to leave that boundary unrestricted while still managing the field. When both explicit boundaries are selected, the minimum cannot exceed the maximum.

The invalid-authentication delay accepts 0 through 10000 milliseconds in increments of 100. A value of 0 disables the SMB authentication rate limiter and requires a reduced-security acknowledgement.

Windows prevents insecure guest logons from being combined with required client signing or encryption. Ordyn validates that combination before saving the profile. Settings that can interrupt protocol, signing, encryption, dialect, or authentication compatibility also require their applicable safety acknowledgements.

Dialect limits, client encryption enforcement, SMB client NTLM blocking, modern SMB auditing, and the server invalid-authentication delay require Windows 11 24H2 or Windows Server 2025. Ordyn marks endpoints on older builds as incompatible when a profile selects one of these settings. The endpoint must also expose the corresponding Windows SMB setting; otherwise the profile reports a configuration error without applying unsupported cmdlet parameters.

Changing the SMB1 client protocol configuration requires a restart. Ordyn reports the restart requirement but does not restart the endpoint automatically.

Firmware / BIOS Policy

Use this to audit or enforce selected firmware settings on supported Dell Windows endpoints. Every firmware profile has an explicit Dell vendor scope.

The profile can manage:

• Secure Boot
• Wake on LAN
• CPU virtualization
• VT-d / IOMMU
• TPM
• capsule firmware updates
• BIOS downgrade permission
• AC power recovery behavior

Each setting also has a Not managed option. A setting in this state is not checked or changed. At least one firmware setting must be managed.

Ordyn uses Dell's agentless WMI BIOS interface that is built into supported system firmware; no Dell Command application or management agent is required. Dell documents this interface as included on commercial client systems released after calendar year 2018, which means approximately 2019 and newer.

The release year is a guideline rather than a compatibility guarantee. The endpoint must support WMI-ACPI BIOS and expose the root\dcim\sysman\biosattributes namespace. Password-protected remediation also uses root\dcim\sysman\wmisecurity. Dell devices without the required interface report a configuration error, as do requested settings or values that the device does not support. A read-only firmware setting cannot be remediated.

Audit-only runs read the managed settings without using the firmware password. During remediation, Ordyn checks whether a Dell Admin BIOS password is set:

• when no Admin password is set, Ordyn applies supported changes without authentication
• when an Admin password is set, Ordyn uses the endpoint's effective hardware.firmware.password secret
• when the secret is missing or incorrect, remediation reports an error

The firmware password authorizes setting changes. Firmware profiles do not set, rotate, or clear BIOS passwords.

Firmware changes do not restart the endpoint automatically. Restart the device when required for the selected changes to take effect. Secure Boot, TPM, and firmware-update settings can affect startup and recovery, so test remediation on representative devices first.

Custom Script

Use this when the built-in policy types do not cover the state you want to enforce.

A custom script profile is made up of:

• a check script
• a remediation script
• a typed field schema
• a desired state

The field schema can use:

• string
• number
• boolean
• JSON

The check and remediation scripts must both target endpoints, must not declare parameters, and must target the same platform.

In practice:

• bash scripts are for Linux endpoints
• powershell scripts are for Windows endpoints
• cmd scripts are for Windows endpoints

Assignments

Profiles are assigned from scope pages, not from inside the profile definition itself.

You can assign them to:

• tenant
• endpoint folder
• endpoint group
• endpoint

If the same endpoint receives more than one matching assignment, Ordyn keeps the matching origins and resolves one effective assignment for the endpoint view. The effective assignment controls both behavior and automations.

An endpoint can have at most one effective Windows Security Policy profile and one effective Windows SMB Hardening profile. When several profiles of either type match, assignment specificity determines the effective profile. Other profile types continue to resolve independently.

The profile settings are shared by every automation on an assignment. Create another profile when different schedules need different desired settings.

Configure an assignment

To configure an assignment:

1. Open the Configuration Profiles section for a tenant, folder, group, or endpoint.
2. Select Assign profile and choose the profile.
3. Choose Audit only or Remediate under Behavior.
4. Select an automation type from Add automation, configure it in the dialog, and select Add automation.
5. Use Edit or Remove in the automation list to adjust the assignment. Recurring schedules include cron expression, timezone, missed-run handling, and maximum jitter settings.
6. Save the assignment.

Editing a direct assignment opens the same behavior and automation fields. Inherited assignments must be edited at the scope where they were created.

Behavior

Each assignment has one behavior:

• Audit only checks compliance and records drift without changing the endpoint
• Remediate checks compliance first and applies the profile only when drift is found

Behavior does not determine when the profile runs. Configure automations separately, or leave the automation list empty for a manual-only assignment.

New assignments default to Audit only with a When assignment becomes effective automation.

Assignment automations

An assignment can have several independent automations:

• When assignment becomes effective runs once whenever the assignment starts controlling the profile on an endpoint
• Recurring schedule runs from a cron expression in the selected timezone
• System boot runs after the device and Ordyn agent have booted and a new operating-system boot is reported
• User logon runs after an interactive Windows user logs on
• User logoff runs after an interactive Windows user logs off

You can add several recurring schedules. An assignment can contain at most one of each other automation type. Select a type from the Add automation list to open its settings. Saved automations appear in a compact list where they can be edited, removed, enabled, or disabled. Recurring schedules support cron expressions only; use manual execution when you need an unscheduled one-time run.

Adding a recurring schedule defaults to every six hours in the browser's timezone. Missed runs default to running on the next connection, and the default maximum dispatch jitter is five minutes. Boot, logon, and logoff automations also default to five minutes of jitter. When assignment becomes effective runs without jitter.

If several automations for the same profile become due together, Ordyn combines them into one endpoint instruction and records the contributing trigger sources. If the same profile already has a check or remediation pending or running on the endpoint, Ordyn coalesces the new trigger instead of starting a duplicate run.

Effective-assignment runs

When assignment becomes effective runs when an assignment first becomes the winning assignment for an endpoint. It also runs when that assignment becomes effective again after another matching assignment had taken precedence. Editing an assignment can re-arm this automation when its effective behavior changes.

Recurring schedules

Recurring schedules are evaluated per endpoint. Connected endpoints run when the cron expression is due. When Run on next connect if the scheduled run was missed is enabled, Ordyn keeps one deferred run for an offline endpoint and starts it after the endpoint reconnects. Repeated missed times do not create a backlog of runs.

Jitter adds a random delay up to the configured maximum. It spreads work across endpoints without changing the recurring schedule itself.

Device events

Windows logon and logoff automations cover local console and Remote Desktop sessions. Screen lock, unlock, Remote Desktop disconnect, reconnect, and unclassified session events do not count as logon or logoff.

The first boot identity Ordyn receives establishes a baseline. A later identity change runs the enabled boot check after the agent has started and reported system status. Reconnecting the endpoint or restarting only the agent does not count as a boot, and offline boots are not queued for later replay.

For custom profile scripts using Current active user session or Current active user session elevated, Ordyn selects the active console user when the script starts. A logon-triggered check is not bound to the Windows session that produced the event. On a normal single-user workstation this is usually the same console user, but jitter, queueing, reconnection, or fast user switching can select a different user. A Remote Desktop logon does not make its RDP session the active console session. Use these contexts only when selecting the currently active console user at execution time is acceptable.

A boot or user-session run does not move the profile's recurring schedules.

Endpoint view

The endpoint Configuration Profiles tab is the main operational view.

It shows:

• profile name
• current state
• effective behavior
• where the assignment came from
• last checked time
• whether a recent run came from an effective-assignment automation, recurring schedule, system boot, Windows user logon, or Windows user logoff

From that view, operators can:

• Check now
• Remediate now
• open Details
• edit a direct assignment
• unassign a direct assignment

The detail view for an endpoint/profile pair shows the desired state, current state, diff, warnings, restart requirement and reasons, and the last error if one exists.

When audit.record_user_session_events is enabled in Administration Settings, the endpoint History tab records each accepted user logon or logoff after its matching job and profile automations have been evaluated. The entry includes the session type and aggregate counts for dispatched, coalesced, skipped, and failed automations. Recording is disabled by default and does not affect profile checks.

The endpoint History tab always records each detected system boot.

Profile view

The profile detail page is the place to review the profile itself.

It has:

• an Overview tab for the definition
• an Endpoints tab for the matched endpoints

From there, operators can run Check now or Remediate now across the endpoints that currently match the profile.

Compliance states

The latest endpoint/profile result is stored as one of:

• compliant
• drifted
• error

If the profile has not been checked yet, the endpoint view shows it as not checked.