Policies

Quick guide #

A Policy defines how configurations are applied and maintained on nodes. It controls the DSC operational behavior, including configuration mode, execution cadence (frequencies), reboot handling, and optional proxy settings.

Create a new Policy #

1. Go to Configuration Management → Policies.
2. Click + New Policy.
3. Enter a Name.
4. Configure the required policy settings:
   • Action after Reboot
   • Configuration Mode
   • Configuration Mode Frequency (min)
   • Refresh Frequency (min)
   • Status Retention Time (d)
5. (Optional) Configure Proxy URL, Proxy Username, and Proxy Password, and/or add Tags.
6. Click Confirm to create the policy.

Edit a Policy #

1. In the Policies table, click the Action menu (⋮) next to the policy.
2. Select Edit.
3. Update the required fields as needed.
4. Click Confirm to save changes.

Delete a Policy #

1. In the Policies table, click the Action menu (⋮) next to the policy.
2. Select Delete.
3. Confirm the deletion.

Additional useful information #

Policy changes: #

Changes made to an XOAP Policy do not automatically update the policy settings on nodes.

Proxy settings: #

Proxy settings: Configure proxy fields only if nodes require a proxy to reach XOAP; otherwise leave them empty.

Technical documentation #

A Policy defines how DSC is executed and maintained on a node. It controls the node’s configuration execution behavior (configuration mode), how often the node evaluates and enforces configuration (Configuration Mode Frequency), how often it refreshes its configuration context (Refresh Frequency), and what should happen after a reboot. Policies can also store proxy settings to ensure nodes can reach XOAP services in restricted network environments.

Policy fields #

Name #

A unique, human-readable name for the policy (for example, XOAP Desktops (no reboot)). Use a naming convention that reflects the target workload and reboot expectations.

Select the Action after Reboot #

Defines what the node should do with configuration processing after a restart. In most environments this is set to ContinueConfiguration, meaning configuration execution continues and the node resumes applying/evaluating the assigned configuration after reboot.

Allow Module Overwrite #

Controls whether module content used for configuration execution can be overwritten when a newer module version is introduced. This is typically used only when you intentionally want nodes to accept updated module versions without manual intervention.

Configuration Mode #

Defines the DSC behavior on the node:

• ApplyOnly: Applies the configuration once; does not continuously monitor for drift.
• ApplyAndMonitor: Applies the configuration and reports drift, but does not auto-remediate.
• ApplyAndAutoCorrect: Applies the configuration and automatically attempts to remediate drift to return the node to the desired state.

In XOAP, ApplyAndAutoCorrect is typically used for security baselines and hardening, while ApplyOnly is more suitable for one-time provisioning scenarios.

Configuration Mode Frequency (min) #

Controls how often the node performs a consistency check based on the selected Configuration Mode (especially relevant for ApplyAndMonitor and ApplyAndAutoCorrect). This is the main “enforcement cadence” that determines how quickly XOAP/DSC detects drift and (when enabled) auto-corrects it.

Key guidance #

• Lower values = faster drift detection and quicker remediation, but higher endpoint load.
• Higher values = less frequent checks, lower load, slower drift detection.

Recommended usage #

• Desktops: 30–60 minutes (typical)
• Servers: 60+ minutes (typical), unless strict enforcement is required

Refresh Frequency (min) #

Controls how often the node refreshes its configuration context and checks for updated configuration content. This influences how quickly changes in XOAP (new configuration version, updated resources, etc.) are picked up by the node.

Key guidance #

• Lower values = nodes pick up changes faster, but more frequent polling.
• Higher values = slower pickup of changes, reduced polling overhead.

Recommended usage #

• Desktops: 180 minutes (typical)
• Servers: 360 minutes (typical), unless you need faster propagation

Status Retention Time (d) #

Defines how long XOAP retains node run/status history for reporting and troubleshooting (for example, compliance history). Higher values retain more history but may increase storage/retention footprint.

Proxy URL / Proxy Username / Proxy Password #

Optional proxy settings used when nodes must access XOAP endpoints through a proxy.

• Proxy URL: The proxy endpoint (for example, http://proxy.company.local:8080)
• Proxy Username / Proxy Password: Credentials if the proxy requires authentication
  Use Choose Existing to reuse stored values in Parameters consistently.

Reboot Node #

Controls whether a node restart is allowed/triggered as part of configuration execution (where applicable). Enable this only if reboots are acceptable for the target systems and your operational policies allow it.

Tags #

Optional metadata used for filtering and organization (for example, Server, Desktop, RebootAllowed, PoC).

Configuration Mode Frequency vs. Refresh Frequency (how they work together) #

These two values serve different purposes and should not be treated as duplicates:

• Configuration Mode Frequency = how often the node evaluates/enforces the desired state (drift detection and remediation cadence).
• Refresh Frequency = how often the node checks for updated configuration content (how quickly configuration changes propagate).

Practical example #

• If you set Configuration Mode Frequency = 15 min and Refresh Frequency = 360 min, the node will enforce the current configuration every 15 minutes, but it may take up to ~6 hours to start using a newly updated configuration version (until it refreshes).

Minimum values and practical limits #

XOAP enforces minimum values (depending on implementation and policy). Current limits are:

• Configuration Mode Frequency: minimum 15 minutes
• Refresh Frequency: minimum 30 minutes

As a safe best practice: #

• Avoid very low values unless you have a strict need and have tested endpoint impact. (Values below the minimums are not supported and will be rejected.)
• Keep Refresh Frequency  higher than Configuration Mode Frequency  to reduce unnecessary refresh/polling.
• A common approach is Configuration Mode Frequency = 15 min and Refresh Frequency = 60–360 min, depending on how quickly you need nodes to pick up changes.