4.3 Group Policy Preferences, Item-Level Targeting & Central Store

Group Policy Preferences, Item-Level Targeting & Central Store

While standard Group Policy Settings (GPS) (also known as Administrative Templates or Policies) enforce rigid, non-negotiable configuration boundaries, enterprise IT environments frequently require flexible baseline configurations, user-customizable defaults, and granular resource mapping. Group Policy Preferences (GPP) provides this flexibility by expanding Group Policy capabilities to manage network drive maps, shared printers, environment variables, local user accounts, scheduled tasks, and arbitrary registry keys.

Furthermore, by leveraging Item-Level Targeting (ILT) and establishing a centralized SYSVOL Central Store for Administrative Templates (.admx/.adml), administrators can eliminate GPO sprawl and ensure consistent policy authoring across global administrative teams.

1. Group Policy Preferences (GPP) vs. Group Policy Settings (GPS)

Understanding the architectural and operational differences between Preferences and Policies is critical for enterprise administration and the AZ-800 exam.

+-----------------------------------------------------------------------------------+
|                GROUP POLICY SETTINGS (GPS) VS. PREFERENCES (GPP)                  |
|                                                                                   |
|  [GROUP POLICY SETTINGS / POLICIES]             [GROUP POLICY PREFERENCES]        |
|                                                                                   |
|  - Target: Protected Policy Registry Keys       - Target: Standard Registry Keys  |
|    HKLM\Software\Policies                       (Same keys used by applications)  |
|    HKCU\Software\Policies                       - UI State: Fully interactive     |
|  - UI State: Greyed out / Locked                (User can modify the setting)     |
|  - Removal: Cleanly "un-tattoos" registry       - Removal: "Tattoos" registry     |
|    when GPO is unlinked / out of scope            (Value remains unless deleted)  |
|  - Enforcement: Mandatory re-enforcement        - Modes: Supports "Apply once and |
|    on every background refresh cycle              do not reapply" for baselines   |
+-----------------------------------------------------------------------------------+

The Concept of Registry Tattooing:

• Policies (GPS): Write to designated policy registry branches (HKLM\Software\Policies, HKCU\Software\Policies, HKLM\Software\Microsoft\Windows\CurrentVersion\Policies). The operating system locks the corresponding configuration UI in Windows. If the GPO is unlinked or deleted, the Group Policy engine automatically purges these keys during the next refresh cycle, returning the OS setting to its unconfigured state.
• Preferences (GPP): Write directly to the standard registry keys utilized by applications and the OS shell. The configuration UI remains fully accessible to end users. If the GPO is unlinked or deleted, the configured settings remain in place indefinitely (this behavior is termed tattooing the registry). To remove a preference setting, administrators must explicitly configure an action of Delete or enable Remove this item when it is no longer applied.

Comprehensive Architectural Comparison: Policies vs. Preferences

2. GPP Lifecycle CRUD Operations & Common Tab Settings

Every Group Policy Preference item utilizes one of four standard lifecycle operations (CRUD):

1. Create:
   • Creates the resource (e.g., mapped drive, shortcut, environment variable, registry key) if it does not already exist.
   • If the resource already exists, the Group Policy engine leaves the existing resource completely untouched.
2. Replace:
   • Completely deletes and purges the existing resource and recreates a brand-new instance with the newly specified attributes.
   • Example: For a Drive Map, Replace unmaps the existing drive letter and maps the new UNC path from scratch.
3. Update (Default Action):
   • Modifies existing settings of the resource in place without recreating it.
   • If the resource does not exist, Update automatically creates it.
   • Best Practice: Use Update for ongoing configuration maintenance where existing connections should not be severed.
4. Delete:
   • Removes the resource if it exists on the endpoint.
   • If the resource does not exist, no action is taken.

+-----------------------------------------------------------------------------------+
|                         GPP COMMON TAB ADVANCED CONTROLS                          |
|                                                                                   |
|  [ ] Stop processing items on this extension if an error occurs on this item      |
|  [x] Run in logged-on user's security context (user policy option)                |
|  [x] Remove this item when it is no longer applied                                |
|  [x] Apply once and do not reapply                                                |
|  [x] Item-level targeting  [ Targeting... ]                                       |
+-----------------------------------------------------------------------------------+

Critical Common Tab Options:

• Run in logged-on user's security context: Evaluates and executes the preference item using the logged-on user's security token and Kerberos ticket rather than the local NT AUTHORITY\SYSTEM account. Essential for User Drive Maps and user-specific network printers that require access to authenticated file shares.
• Apply once and do not reapply: The preference item is evaluated and configured only on the user's initial logon or first policy processing cycle. Subsequent background refresh cycles (every 90 minutes) skip this item. This allows IT to seed default corporate settings while allowing users to customize their preferences without having them reset.
• Remove this item when it is no longer applied: When the GPO falls out of scope (e.g., the user moves to another OU or group membership changes), the Group Policy engine automatically deletes the preference item, preventing registry tattooing.

3. Item-Level Targeting (ILT) Mechanics

Item-Level Targeting (ILT) allows administrators to apply individual preference items within a single GPO to specific users, computers, hardware architectures, or network locations. Rather than creating 50 separate GPOs to map 50 departmental network drives, an administrator can create a single GPO containing 50 drive map items, each protected by an ILT filter.

+-----------------------------------------------------------------------------------+
|                     ITEM-LEVEL TARGETING (ILT) FILTER LOGIC                       |
|                                                                                   |
|  GPO: Corporate-Drive-Mappings                                                    |
|  |                                                                                |
|  +-- Drive S: (\\fs01\sales)   --> ILT: User is a member of SG-Sales-Dept        |
|  |                                                                                |
|  +-- Drive F: (\\fs01\finance) --> ILT: User is a member of SG-Finance-Dept       |
|  |                                                                                |
|  +-- Drive E: (\\fs01\eng)     --> ILT: User is a member of SG-Engineering        |
|  |                                      AND Operating System is Windows 11        |
|  |                                      AND IP Address in Range 10.20.0.0/16      |
|  |                                                                                |
|  +-- Printer (Bldg-2-Color)    --> ILT: Computer IP Address in 192.168.50.0/24    |
|                                         AND Battery is NOT Present (Desktop)      |
+-----------------------------------------------------------------------------------+

Primary ILT Targeting Categories:

• Security Group: Checks whether the user or computer is a member of a specified domain or local security group (supports primary group checks and SID resolution).
• Operating System: Evaluates the OS version, edition, architecture (32-bit vs 64-bit), and build number.
• IP Address Range: Matches the client's current IP address or subnet mask (ideal for location-aware printer and file share mapping across branch offices).
• Battery Present: Detects whether the device contains a battery (distinguishing portable laptops from fixed desktops/servers).
• Disk Space / RAM / Processor: Evaluates hardware resource thresholds before executing compute-intensive tasks.
• LDAP Query: Executes dynamic LDAP search filters against Active Directory objects (e.g., querying whether (department=Marketing) or (title=*Director*)).
• Registry / File / Environment Variable: Evaluates the presence or value of a specific registry key, file path, or environment variable on the endpoint.

Logical Operators & Parenthetical Grouping:

ILT supports complex boolean logic including AND, OR, Is, Is Not, and parenthetical grouping collections ((A OR B) AND C).

4. Common Enterprise GPP Implementations

# Inspecting GPP XML Configuration Files Directly in SYSVOL
$GpoGuid = "{31B2F340-016D-11D2-945F-00C04FB984F9}"
$Domain = "corp.contoso.com"
$DriveMapXmlPath = "\\$Domain\SYSVOL\$Domain\Policies\$GpoGuid\User\Preferences\Drives\Drives.xml"

# Reading XML contents to review Item-Level Targeting rules
[xml]$DrivesXml = Get-Content -Path $DriveMapXmlPath
$DrivesXml.Drives.Drive.Filters.FilterGroup

Key Preference Configurations:

1. Drive Maps (User Configuration -> Preferences -> Windows Settings -> Drive Maps):
   • Configures network drive letters (H:, S:, P:), UNC paths (\\fileserver\share), reconnect settings, and label names.
   • Best Practice: Use Action = Update with ILT based on departmental security groups.
2. Printers (User/Computer Configuration -> Preferences -> Control Panel Settings -> Printers):
   • Deploys TCP/IP printers, shared network printers (UNC), and local printers.
   • Configures the Default Printer dynamically based on the client computer's IP subnet.
3. Environment Variables: Sets user or system-level environment variables (e.g., APP_SERVER_URL or JAVA_HOME).
4. Shortcuts: Automatically distributes application shortcuts, web links, and utilities to the Desktop, Start Menu, or Quick Launch toolbar.
5. Registry Settings: Directly writes, updates, or deletes arbitrary registry keys and values in HKLM or HKCU without requiring custom .admx authoring.
6. Power Options: Standardizes power plans (Balanced, High Performance), sleep timers, and display turn-off timeouts across desktop fleets.

5. The SYSVOL Central Store for Administrative Templates (ADMX / ADML)

The Problem of Local Administrative Template Drift:

Administrative Templates define the registry-based policy settings available in the Group Policy Management Editor (gpme.msc). Historically, template files were stored locally on each administrator's workstation in %SystemRoot%\PolicyDefinitions.

If Administrator A edited a GPO from a Windows 10 workstation and Administrator B edited the same GPO from a Windows Server 2022 domain controller, template version discrepancies led to administrative template drift, missing policy settings, and duplicate namespace errors.

+-----------------------------------------------------------------------------------+
|                    SYSVOL CENTRAL STORE ARCHITECTURE & STRUCTURE                  |
|                                                                                   |
|  UNC Path: \\<Domain>\SYSVOL\<Domain>\Policies\PolicyDefinitions\                 |
|                                                                                   |
|  \PolicyDefinitions\                                                              |
|   |-- WindowsUpdate.admx        (Language-neutral XML policy schema definitions)  |
|   |-- BitLocker.admx                                                              |
|   |-- SecGuide.admx                                                               |
|   |                                                                               |
|   |-- \en-US\                   (Language-specific localized display strings)     |
|   |    |-- WindowsUpdate.adml                                                     |
|   |    |-- BitLocker.adml                                                         |
|   |    |-- SecGuide.adml                                                          |
|   |                                                                               |
|   |-- \de-DE\                                                                     |
|   |    |-- WindowsUpdate.adml                                                     |
|   +-- \fr-FR\                                                                     |
|        |-- WindowsUpdate.adml                                                     |
+-----------------------------------------------------------------------------------+

The Central Store Solution:

Creating the PolicyDefinitions folder in SYSVOL establishes the Central Store. When the Group Policy Management Editor launches on any domain-joined machine, it automatically detects the Central Store in SYSVOL and loads all template definitions from SYSVOL rather than the local %SystemRoot%\PolicyDefinitions folder.

File Formats:

• .admx Files: Language-neutral XML files stored directly in the root of the PolicyDefinitions folder. They define the policy category, registry key paths, value types, and UI structure.
• .adml Files: Language-specific XML files stored in language subfolders (e.g., \en-US\, \de-DE\, \fr-FR\). They provide the localized display text, setting titles, and explanatory help strings.

# Creating and Populating the SYSVOL Central Store via PowerShell
$DomainFQDN = (Get-ADDomain).DNSRoot
$CentralStorePath = "\\$DomainFQDN\SYSVOL\$DomainFQDN\Policies\PolicyDefinitions"

# 1. Create the Central Store directory if it does not exist
if (!(Test-Path -Path $CentralStorePath)) {
    New-Item -Path $CentralStorePath -ItemType Directory -Force
}

# 2. Copy ADMX files from local system to Central Store
Copy-Item -Path "$env:SystemRoot\PolicyDefinitions\*.admx" -Destination $CentralStorePath -Force

# 3. Copy localized ADML language directories (e.g., en-US)
Copy-Item -Path "$env:SystemRoot\PolicyDefinitions\en-US" -Destination $CentralStorePath -Recurse -Force

[!TIP] Updating the Central Store: When Microsoft releases new Windows client builds (e.g., Windows 11 23H2/24H2) or Microsoft 365 Apps administrative templates, download the administrative template package, extract the files, and overwrite the .admx files and .adml language folders in \\<Domain>\SYSVOL\<Domain>\Policies\PolicyDefinitions. DFSR will automatically replicate the updated definitions to all domain controllers.