Skip to content

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 ten 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
  • quality-update deferral from 0 through 30 days
  • 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.

Quality update deferral controls how long Windows waits after Microsoft releases a quality update before offering it to the endpoint. Leave the field blank for Not managed, enter 0 to disable the deferral, or enter a value from 1 through 30 days. A Not managed profile run leaves any existing endpoint value in place.

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 settingRegistry valueTypeData
Automatic update modeAU\NoAutoUpdateREG_DWORD1 for Disabled; 0 for every other managed mode
Automatic update modeAU\AUOptionsREG_DWORD1 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 dayAU\ScheduledInstallDayREG_DWORD0 every day, 1 Sunday, 2 Monday, 3 Tuesday, 4 Wednesday, 5 Thursday, 6 Friday, or 7 Saturday
Scheduled install timeAU\ScheduledInstallTimeREG_DWORDHour of day from 0 through 23
Update sourceAU\UseWUServerREG_DWORD0 for Microsoft Update / Windows Update or 1 for WSUS
WSUS URLWUServerREG_SZConfigured WSUS URL
WSUS URLWUStatusServerREG_SZConfigured WSUS URL
Quality update deferralDeferQualityUpdatesREG_DWORD0 disabled or 1 enabled
Quality update deferralDeferQualityUpdatesPeriodInDaysREG_DWORDDeferral period from 1 through 30; removed when disabled
Auto reboot with signed-in userAU\NoAutoRebootWithLoggedOnUsersREG_DWORD1 blocked or 0 allowed
Windows Update user accessSetDisableUXWUAccessREG_DWORD1 blocked or 0 allowed
Windows Update notificationsSetUpdateNotificationLevelREG_DWORD0 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 review repository content, 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 settingRegistry valueTypeData
Download modeDODownloadModeREG_DWORD0 HTTP only, 1 local network peers, or 2 private peer group
Peer group IDDOGroupIdREG_SZConfigured peer group ID; removed outside private peer group mode
Maximum cache ageDOMaxCacheAgeREG_DWORDConfigured days converted to seconds
Maximum cache sizeDOMaxCacheSizeREG_DWORDConfigured percentage
Minimum file sizeDOMinFileSizeToCacheREG_DWORDConfigured megabytes converted to bytes
VPN peeringDOAllowVPNPeerCachingREG_DWORD1 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.

Windows Energy Policy

Use this to audit or enforce Windows inactivity timeouts for:

  • turning off the display
  • entering sleep
  • entering hibernation

Each timeout group is optional, but at least one group must be managed. Choose a duration up to 365 days, or select Never to store a zero-second timeout.

Power plan behavior

Ordyn creates and activates a dedicated power plan. Timeout groups left unmanaged retain the values copied from the endpoint's active power plan. Windows Energy Policy does not enable hibernation. Removing or superseding an assignment does not reactivate the endpoint's previous power plan or delete the Ordyn-managed plan; apply another power plan explicitly when a device should stop using it.

During the first remediation, Ordyn copies the endpoint's active power plan, names the copy Ordyn Energy Policy, applies the managed timeouts, and activates it. Later remediations reuse that same Ordyn-managed plan instead of creating additional plans. Audit-only runs report whether the plan exists, has the expected name, is active, and has the requested timeout values without changing the endpoint.

A profile that manages the hibernate timeout reports an error without changing the power plan when the endpoint does not support hibernation. The same fail-before-change behavior applies when Windows or Group Policy prevents access to a requested energy setting.

When several Windows Energy Policy profiles match an endpoint, assignment specificity determines the single effective profile.

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.

Intel AMT

Use this to configure and maintain Intel Active Management Technology on supported Windows endpoints. The profile defines:

  • ACM or CCM control mode
  • managed DNS suffix and hostname template using {{ endpoint.hostname }}
  • shared DHCP, shared static IPv4, or dedicated static IPv4 addressing
  • firmware consent behavior
  • power package

The Intel AMT firmware WebUI remains available on managed endpoints.

Audit only inspects managed firmware and reports drift without provisioning or changing it. Remediate provisions ready unmanaged endpoints and applies the profile to managed endpoints.

Recovery-required and externally managed devices must first use their explicit AMT recovery or adoption workflows.

Only one Intel AMT profile is effective for an endpoint. Assignment specificity determines the profile: endpoint, group, nearest folder, then tenant. At the same scope, a remediate assignment takes precedence over an audit-only assignment.

Removing the effective assignment leaves firmware configured and marks the endpoint unassigned.

Use the endpoint's Intel AMT deprovisioning workflow when firmware configuration should be removed. See Intel AMT Endpoint Management for provisioning requirements and operational controls.

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 and sh 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, Windows SMB Hardening profile, Windows Energy Policy profile, and Intel AMT profile. When several profiles of one of these types 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. Intel AMT assignments use the AMT lifecycle schedule and do not have assignment automations.

Disable a profile for an endpoint

Use Disable from an endpoint's Configuration Profiles tab when the profile should remain assigned but must not run on that endpoint. The profile state changes to Disabled, and Ordyn stops its manual checks, remediations, recurring schedules, and device-event automations for that endpoint. Select Enable to resume the effective behavior and automations.

The same actions are available for selected endpoints in a profile's Endpoints tab. Disabled endpoints remain visible and can be selected with the Disabled state filter.

Windows Security Policy, Windows SMB Hardening, Windows Energy Policy, and Intel AMT allow one effective profile of their type on an endpoint. Disabling one of these types continues to apply if assignment precedence later selects a different profile of the same type. For profile types that can run several profiles independently, disabling affects only the selected profile.

Disabling an Intel AMT profile leaves the firmware configuration in place and stops managed AMT communication, sessions, certificate maintenance, and lifecycle work. Partial and full AMT deprovisioning disable the effective Intel AMT profile to prevent automatic reprovisioning. Enable the profile after deprovisioning or recovery is complete when the endpoint should be managed again.

Endpoint jobs can make the same change with the Disable configuration profile and Enable configuration profile tasks. These tasks run in Ordyn rather than on the agent, so they also work while the endpoint is offline. The selected profile must be effectively assigned and compatible with the endpoint when the task runs. A repeated request succeeds without replacing an existing disable reason or creating another state change.

For a profile type that allows one effective profile, the task changes the type-wide disable state. The selected profile can therefore be superseded by another assignment of the same type without changing the result. For profile types that allow several effective profiles, the task changes only the selected profile. Intel AMT state tasks use the same lifecycle safeguards as the endpoint action and do not deprovision firmware.

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

For profile types that support manual endpoint instructions, operators can:

  • Check now
  • Remediate now
  • open Details
  • disable or enable the effective profile for this endpoint
  • 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

Operators can run Check now or Remediate now across 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.