100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Windows

Group Policy Preferences

How Group Policy Preferences differ from Group Policy Policies, common preference extensions like drive maps and scheduled tasks, and item-level targeting.

Group PolicyIntermediate9 min readJul 10, 2026
Analogies

Preferences vs. Policies

Group Policy Preferences (GPP), introduced in Windows Server 2008 and found under the Preferences node (distinct from the Policies node) in the Group Policy Management Editor, differ fundamentally from true policy settings: preferences write their values once during processing and then leave the setting alone, allowing a user or local administrator to change it afterward, whereas policy settings are enforced continuously and rewritten (and grayed out in the UI) on every refresh. This makes preferences ideal for setting an initial default — like a desktop background or a mapped drive letter — that users are allowed to customize, while policies remain the right tool for anything that must be non-negotiable, like disabling Control Panel access. Preferences also don't use the traditional Administrative Templates registry.pol format for most extensions; instead they write directly to the target location (registry, files, drive mappings, local users/groups) using their own XML-based configuration stored in the GPT.

🏏

Cricket analogy: Group Policy Preferences are like a groundskeeper setting the initial pitch length and marking before play starts, which players can then work with, while true policy is like an on-field umpire enforcing a no-ball line on every single delivery without exception.

Common Preference Extensions

The most widely used Preference extensions include Drive Maps (mapping network shares to drive letters without a logon script), Printers (deploying shared or TCP/IP printers), Shortcuts (placing icons on the desktop or Start Menu), Scheduled Tasks (creating or modifying tasks under the newer Scheduled Tasks (At least Windows 7) format), Local Users and Groups (adding a user to the local Administrators group on target machines), and Registry (writing arbitrary registry values without needing an ADMX template). Each of these appears twice in the console — once under Computer Configuration and once under User Configuration — and each individual preference item has an Action setting (Create, Replace, Update, or Delete) controlling exactly how it's applied relative to any existing value, plus a Common tab exposing item-level targeting for fine-grained conditional application.

🏏

Cricket analogy: Drive Maps preferences are like a team manager assigning each player a specific locker before the match without needing to announce it over the PA every time, while Scheduled Tasks preferences resemble pre-booking the team bus for a fixed departure time regardless of who's driving that day.

Item-Level Targeting

Item-Level Targeting (ILT), configured via the Targeting Editor on a preference item's Common tab, evaluates conditions at processing time — security group membership, IP address range, OS version, WMI query, registry value, battery status, and more — combined with AND/OR logic to decide whether that specific preference item applies, all without needing a separate GPO or WMI filter at the GPO level. This is the key differentiator from WMI filtering at the GPO level: ILT operates per preference item within a single GPO, so one Drive Maps preference can map the Finance share only for members of the Finance-Users group while a second Drive Maps item in the same GPO maps a different share for Sales-Users, all coexisting in one GPO instead of requiring separate GPOs and links for each group.

🏏

Cricket analogy: Item-Level Targeting is like a single team-sheet document containing conditional instructions — 'if bowling first, field X at slip; if chasing, field X at cover' — all in one document instead of issuing an entirely separate team sheet for every possible match situation.

powershell
# Preferences are authored through the GPMC UI, but can be inspected via the underlying XML in SYSVOL
# Example: DriveMaps.xml content for a Finance share, targeted to the Finance-Users group
<?xml version="1.0" encoding="utf-8"?>
<Drives clsid="{8FDDCC1A-0C3C-43cd-A6B4-71A6DF20DA8C}">
  <Drive clsid="{935D1B74-9CB8-4e3c-9914-7DD559B7A417}" name="F:" status="F:" image="2" changed="2026-07-10 09:15:00" uid="{...}">
    <Properties action="U" thisDrive="NOCHANGE" allDrives="NOCHANGE"
                userName="" path="\\contoso\shares\finance" label="Finance" persistent="1" useLetter="1" letter="F"/>
    <Filters>
      <FilterGroup bool="AND" not="0" name="CONTOSO\Finance-Users" sid="S-1-5-21-..." userContext="1" primaryGroup="0" localGroup="0"/>
    </Filters>
  </Drive>
</Drives>

Because preferences are set-once, not enforced, a user with local administrator rights can permanently change or delete a preference-mapped drive or scheduled task after it's applied, and it will stay changed until the next Group Policy refresh where the preference's Action (typically Replace or Update) reasserts it. For anything that truly must never be user-modifiable, use a policy setting instead of a preference.

The Local Users and Groups preference, if misconfigured with the 'Update' action on a Domain Users group added to local Administrators across an entire OU, can inadvertently grant every domain user local admin rights on every machine in that OU. Always test Local Users and Groups preference changes on a small pilot OU before deploying broadly, and prefer using Restricted Groups policy for enforcing exact group membership instead.

  • Preferences write a value once during processing and allow later user changes; policies re-enforce their value on every refresh.
  • Common extensions include Drive Maps, Printers, Shortcuts, Scheduled Tasks, Local Users and Groups, and Registry.
  • Each preference item has an Action (Create, Replace, Update, Delete) controlling how it interacts with existing values.
  • Item-Level Targeting lets a single preference item apply conditionally based on group membership, IP range, OS version, and more.
  • ILT operates per preference item within one GPO, unlike WMI filtering which applies to an entire GPO.
  • Preferences store their configuration as XML files in the GPT rather than using ADMX-based registry.pol format.
  • Misconfigured Local Users and Groups preferences can accidentally grant broad local admin rights; test on a pilot OU first.

Practice what you learned

Was this page helpful?

Topics covered

#Windows#WindowsServerActiveDirectoryStudyNotes#MicrosoftTechnologies#GroupPolicyPreferences#Group#Policy#Preferences#Policies#StudyNotes#SkillVeris