Effective Policy

The Effective Policy view shows the resolved set of all policy settings applied to an agent, including collision detection across multiple policy sources. This is the Resultant Set of Policy (RSoP) for each endpoint.

Conformance vs. Compliance

The Effective Policy tab uses the term conformance (Conformant / Non-Conformant) rather than "compliance." This is intentional. In TridentStack Control, "compliance" refers specifically to security compliance frameworks (DISA STIGs, Microsoft Security Baselines) managed under the Compliance tab. Effective Policy conformance is a different concept: it measures whether the actual value of a policy setting on the endpoint matches the desired value configured by the winning policy source. Using distinct terminology avoids confusion between these two features.

Why This Matters

In real environments, policy settings can come from multiple sources simultaneously:

• TridentStack Control platform policies you configure in the Configuration Policies page
• Active Directory Group Policy Objects (GPOs) from your domain controllers
• Local Group Policy edited on the endpoint itself with the Local Group Policy Editor or LGPO.exe
• Intune MDM policies from Microsoft Endpoint Manager
• Local registry values TridentStack Control could not attribute to any of the sources above

When the same setting is defined by more than one source, conflicts arise. The Effective Policy view shows you exactly which source wins for each setting and highlights any conflicts that were resolved.

Policy Sources

Every effective setting is attributed to one source. Knowing what each source means makes the settings table, the per-source counts, and the conformance results easy to read.

• Platform: A setting managed by a TridentStack Control policy assigned to this endpoint.
• Domain GPO: A setting delivered by an Active Directory Group Policy Object linked in your domain.
• Local GPO: A setting written into the endpoint's own local Group Policy, edited on the machine with the Local Group Policy Editor or LGPO.exe. It is a real, structured policy object, separate from a domain Group Policy Object.
• Local: A registry value TridentStack Control could not attribute to any current policy source, such as a policy, a Group Policy Object, or a device management profile. It is shown as observed on the endpoint. Because TridentStack Control has no intended value to compare it with, its conformance always reads N/A.
• Tattooed: A security setting configured on the endpoint that no current policy or Group Policy Object manages. A removed policy, a Group Policy Object that no longer applies, a device management profile, or a manual change can each leave one behind. Windows keeps the value until something changes it. See Tattooed Settings below for details.
• Intune MDM: A setting delivered by Microsoft Intune device management. This source appears only when the endpoint reports Intune-managed settings.

Viewing Effective Policy

Navigate to any Windows agent's detail page and select the Effective Policy tab.

info

The Effective Policy tab is only available for Windows agents. Linux agents do not have the same multi-source policy model.

Summary Strip

At the top, a summary shows:

• Settings per source: Count of settings from each source (Platform, Domain GPO, Local GPO, Local, Tattooed, and Intune MDM when the endpoint reports Intune-managed settings)
• Conformance rate: Of the settings whose current value the endpoint has reported, the percentage where that value matches what the winning policy asked for. Settings with no reported value yet are counted separately as Unknown and are left out of the percentage, so the rate always equals Conformant divided by Conformant plus Non-Conformant. An endpoint with nothing non-conformant reads 100%, with any Unknown count shown alongside it
• Conflicts: Number of settings that more than one policy competes to set. This counts competition between different sources (a domain GPO and a platform policy) and competition inside one source (two platform policies, or two domain GPOs). Click it to filter the table down to exactly those settings (highlighted in amber when greater than zero)
• Domain context: The domain name if the agent is domain-joined

Settings Table

Each row in the table represents a single enforced value. Most settings are one row; a setting that configures several values at once, such as one with a list plus its own on/off value, appears as one row per value, each named after the setting with the value name in parentheses.

Column	Description
Setting Name	Human-readable name (e.g., "Configure Automatic Updates")
Type	Setting type: Registry, Security, Drive Mapping, or Service
Policy	Which policy object defined this setting
Desired Value	The exact value the policy enforces. Shows "Remove value" when the policy removes the value from the endpoint rather than setting one
Actual Value	What the agent currently reports. For a setting that holds a list, this is the number of entries the endpoint carries; hover it to see which of your configured entries are not there yet
Conformance	Whether desired matches actual (Conformant / Non-Conformant / N/A). N/A means conformance could not be assessed: the setting has no desired value to compare against, or its current value is not available
Conflict	How many other policies also set this setting, or a dash when nothing competes for it. Sort by this column to bring every contested setting to the top
Source	Which source provided the winning value (Platform, Domain GPO, Local GPO, Intune MDM, Local, Tattooed)

List settings

A setting that holds a list, such as an antivirus exclusion list, is checked entry by entry against what the endpoint reports rather than as a single value. It reads Conformant when every entry you configured is present on the endpoint. Extra entries put there by other software do not count against it, because Windows adds to these lists rather than replacing them. When an entry is missing, hover the Actual Value cell to see which ones.

If the endpoint has not reported anything for the list yet, the row keeps the result inferred from the deployment instead of reading as an empty list. An endpoint that cannot report its local settings is not the same as an endpoint with no exclusions.

Conflict Details

Click any row to expand it and see three sections:

1. Setting Details: Registry key path, category, and state
2. Conformance Check: Side-by-side comparison of desired vs. actual values
3. Policy Precedence: Shows which sources competed for this setting and which one won

When a setting has a conflict, the expanded view displays the full precedence chain. For example:

Policy Precedence
  [Winner]     Server Hardening Policy (Platform)
  [Overridden] Default Domain Policy (Domain GPO)

How Conflicts Are Resolved

Source Priority

When the same setting is defined by multiple sources, the highest-priority source wins:

Priority	Source	Description
4 (highest)	Platform	TridentStack Control configuration policies
3	Intune MDM	Microsoft Endpoint Manager policies
2	Domain GPO	Active Directory Group Policy
1 (lowest)	Local GPO	The endpoint's own local Group Policy
1 (lowest)	Local	Registry values TridentStack Control could not attribute to another source

TridentStack Control platform policies take precedence over all other sources. This ensures your TridentStack Control-managed settings are always enforced, even when GPOs or MDM policies target the same setting.

Local Group Policy and Local share the lowest priority. Both give way to a domain GPO, an Intune MDM policy, or a TridentStack Control policy that targets the same setting.

Within-Platform Conflicts

When an agent has multiple TridentStack Control platform policies targeting the same registry key (e.g., two policies both configure "Minimum password length"), the system resolves the conflict automatically and deterministically, and shows which policy won on the setting's detail. There is no per-policy priority for you to set; the resolution is handled for you.

Detection, Not Manual Resolution

Conflict resolution is automatic. You cannot manually pick a winner for individual settings. To change which policy wins:

• Remove the conflicting setting from one of the competing policies
• Reassign tags so the agent only receives one of the conflicting policies

Tattooed Settings

Some security settings remain configured on an endpoint even after whatever applied them is gone. A policy that was removed, a Group Policy Object that no longer applies, a device management profile, or a manual change can each leave a value behind. Windows keeps such values until something changes them; these are commonly called tattooed settings.

The Effective Policy view identifies them: a security setting observed on the endpoint that no current policy or Group Policy Object manages, and whose value differs from the Windows factory default, is shown with a Tattooed source badge. Values that match what a fresh Windows installation ships are not reported: they are factory state, not leftovers. Each tattooed row shows the value currently on the endpoint, the registry location it was observed at, and when it was last observed. Tattooed settings are informational: they do not count toward the conformance rate, because no policy defines a desired value for them.

To take ownership of a tattooed setting, add it to a configuration policy that targets the endpoint with the value you want. Once a policy manages the setting, the row moves to that policy's source and joins conformance tracking.

note

Settings applied by a device management (MDM) profile can appear as tattooed, because MDM-managed values are not always distinguishable from unmanaged ones. If your endpoints are MDM-managed, check your management profiles before treating a tattooed setting as unowned.

Filtering and Search

• Source filter: Toggle buttons to show/hide settings from specific sources (Platform, Domain GPO, Local GPO, Intune MDM, Local, Tattooed)
• Type filter: Filter by setting type (Registry, Security, Drive Mapping, Service)
• Search: Find settings by name or registry key path
• Sort: By setting name, type, policy name, conformance status, or source

Data Sources

The Effective Policy tab combines data from multiple agent telemetry channels:

Source	How Data Is Collected
Platform policies	Agent receives desired state from TridentStack Control server during check-in
Domain GPO	Agent runs gpresult /xml and sends the parsed output
Local GPO	Reported in the same gpresult /xml output, as the endpoint's local Group Policy container, distinct from any domain GPO
Intune MDM	Agent reads Configuration Service Provider (CSP) registry entries
Local	Registry values TridentStack Control could not attribute to any of the other sources
Actual values	Agent reports current registry values for comparison

The RSoP document is cached and refreshed when policy changes are detected. It uses ETag-based caching so the agent only re-downloads when something has changed.