How RSoP Calculated Group Policy in Windows XP

Resultant Set of Policy (RSoP) was introduced in Windows XP and Windows Server 2003 to help administrators determine and predict the net effect of multiple, often conflicting, Group Policy Objects (GPOs) applied to a specific computer or user. Operating through Windows Management Instrumentation (WMI), RSoP calculated the final policy environment by simulating or querying the standard Group Policy processing order (Local, Site, Domain, and Organizational Unit), accounting for inheritance rules, security filtering, and client-side extensions.

The LSDOU Processing Hierarchy

At the core of RSoP's calculation was the standard Group Policy evaluation order, commonly referred to as LSDOU:

  1. Local: The local computer policy was evaluated first.
  2. Site: Policies linked to the Active Directory site containing the computer were evaluated next.
  3. Domain: Policies linked at the domain level were evaluated third.
  4. Organizational Unit (OU): Policies linked to parent OUs down to the specific OU containing the object were evaluated last.

Because policy processing works cumulatively, settings processed later in the sequence overwrite conflicting settings processed earlier. Therefore, settings in a child OU naturally superseded settings configured at the domain or site level.

Conflict Resolution and Exceptions

When determining the winning policy setting, RSoP factored in specific Group Policy override mechanisms:

  • Enforced (No Override): If a GPO link was set to "Enforced," its settings took precedence over any conflicting settings defined in downstream GPOs, regardless of where they sat in the OU hierarchy.
  • Block Policy Inheritance: If an OU was configured to block inheritance, RSoP excluded all upstream GPOs from Site, Domain, and parent OUs—unless an upstream GPO was marked as "Enforced."
  • Link Order: If multiple GPOs were linked to the exact same Active Directory container (e.g., two GPOs linked to the same OU), RSoP used the link order number. The GPO with Link Order 1 was processed last, allowing its settings to overwrite the others.

Security Group Filtering and WMI Filters

RSoP did not assume a GPO applied simply because it was linked to an object's container. The engine evaluated:

  • Access Control Lists (ACLs): A GPO only applied if the target user or computer possessed both Read and Apply Group Policy permissions on that GPO. If the security filter denied access, RSoP excluded the GPO entirely.
  • WMI Filters: Windows XP introduced WMI filtering, allowing GPOs to execute conditional WQL queries (such as checking available disk space or OS build). RSoP evaluated these queries to verify if the policy conditions evaluated to true.

Client-Side Extensions (CSEs) and WMI

Group Policy calculation did not occur as a single monolithic block. Instead, it relied on Client-Side Extensions (CSEs)—individual DLLs on Windows XP responsible for processing specific areas (such as Software Installation, Folder Redirection, or Security Settings).

During processing, each CSE resolved its own conflicts and reported the results to the local WMI repository under the root\rsop namespace. RSoP retrieved this stored data to display which GPO won for every individual configuration toggle.

Operational Modes: Logging vs. Planning

Windows XP supported two operational modes for RSoP calculation:

  • Logging Mode: Queried the actual, live state of a computer by reading the root\rsop\computer and root\rsop\user WMI namespaces on the target Windows XP client. It showed the policies that were currently enforced.
  • Planning Mode: Executed primarily from Windows Server 2003 domain controllers targeting Windows XP scenarios. It performed a simulated calculation based on hypothetical conditions, such as what would happen if a user moved to a different OU or joined a different security group, without requiring the client machine to actively apply the changes.