Group Policy Preferences Drive Maps Not Applying — Item-Level Targeting

Introduction

Someone in Finance asks why their new F: drive never showed up. You added item-level targeting to an existing drive map GPO last week — restrict it to the Finance security group instead of the whole “Finance-OU” it used to be linked to — and it worked fine when you tested it on your own account. Now half of Finance has the drive and half doesn’t, and nothing in the event log even hints that anything went wrong.

This is the defining trait of item-level targeting failures: they are quiet. Unlike a GPO that fails to link, fails security filtering, or fails to replicate, a targeting item that evaluates to false does not produce an error. It produces nothing. The preference item is simply skipped, exactly as designed, and the only way to tell the difference between “correctly filtered out” and “misconfigured” is to go looking.

What It Looks Like

Run gpresult /r on an affected machine and the GPO in question shows up completely healthy:

C:\>gpresult /r

USER SETTINGS
    CN=Jane Doe,OU=Finance,OU=Users,DC=corp,DC=example,DC=com
    Last time Group Policy was applied: 7/19/2026 at 8:41:02 AM
    Group Policy was applied from:      DC02.corp.example.com
    Group Policy slow link threshold:   500 kbps

    Applied Group Policy Objects
    -----------------------------
        Finance-Drive-Map
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    -----------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)

Finance-Drive-Map is listed as applied. No warning, no denial, no filtering reason. If you stop at gpresult, this looks like a dead end — the GPO is doing exactly what it should.

The layer gpresult cannot see is what happens inside the GPO once it applies: whether each individual Drive Maps preference item’s targeting logic actually matched this user. If the Drive Maps client-side extension does hit a real failure — a bad path, an access-denied share, a taken drive letter — that shows up separately, as Event ID 4098 from source Group Policy Drive Maps in the Application log:

Log Name:      Application
Source:        Group Policy Drive Maps
Event ID:      4098
Level:         Warning
Description:
The user 'F:' preference item in the 'Finance-Drive-Map {2A1F...}' Group
Policy object did not apply because it failed with error code
'0x80070035 The network path was not found' This error was
suppressed.

There is a third, easily confused case: a targeting item that fails to evaluate at all, rather than evaluating cleanly to false — for example, a Security Group or LDAP Query targeting item that cannot reach a domain controller to check membership. That case does log, as event ID 4105 or 4106 (“…did not apply because a targeting item failed with error code…”), also from the relevant CSE source in the Application log. The distinction matters: 4105/4106 means the targeting logic itself broke and needs a network or connectivity fix, while a silent skip means the logic ran fine and correctly decided this user does not qualify.

What It Actually Means

A GPP drive map failing to show up has two entirely different failure layers, and they need different tools to diagnose.

The first layer is whether the GPO reaches the user at all — link scope, security filtering, WMI filtering, replication. gpresult is built for exactly this layer, and it tells you clearly when a GPO is filtered out and why. The second layer is what happens after the GPO has already been accepted: whether each preference item inside it, evaluated one at a time against its own targeting rules, actually fires. gpresult has no visibility into this second layer at all — it reports on GPOs, not on the individual preference items inside them.

Item-level targeting and security filtering look similar on paper — both restrict who gets something — but they operate at different scopes and fail differently. Security filtering is enforced by Active Directory access control on the GPO itself; if a computer or user lacks Read and Apply Group Policy permissions, the whole GPO is discarded before it is ever downloaded. Item-level targeting is evaluated entirely on the client, after the GPO has already downloaded successfully, one targeting item at a time, and a false result never gets logged as a denial anywhere central. Diagnosing a targeting problem means proving the GPO applied first, then separately proving what the targeting logic actually evaluated to.

Think of the GPO’s own scope — its OU link, security filtering, WMI filter — as the security desk at the front of the building: fail that check and you never make it past the lobby, and the desk logs exactly why. Item-level targeting is more like a keycard reader on one specific door upstairs. You can clear the front desk without any trouble and still find that one door won’t open, because your card doesn’t match that door’s list — and the front desk has no idea it ever happened, because getting into the building was completely legitimate.

How to Diagnose

Work outward, cheapest check first, until you find the layer where things actually break.

# 1. Confirm the GPO itself is applying (or find out why it isn't)
gpresult /r

# 2. Get the full detail, including any GPO-level denial reasons, as HTML
gpresult /h C:\Temp\gpresult.html

# 3. Check GPO delegation directly -- confirms Read/Apply GP on the
#    security principals you expect, not just what the GUI implies
Get-GPPermission -Name "Finance-Drive-Map" -All

# 4. Force a clean re-application of user-side policy only
gpupdate /force /target:user

# 5. Export the core Group Policy operational log to confirm the engine
#    itself started and finished processing (event 4016 / 5016). This
#    log does NOT contain GPP failures -- those are in the Application
#    log instead, under a source like "Group Policy Drive Maps" (4098)
wevtutil.exe export-log Microsoft-Windows-GroupPolicy/Operational C:\Temp\GroupPolicy.evtx /overwrite:true
wevtutil.exe export-log Application C:\Temp\Application.evtx /overwrite:true

# 6. Enable Group Policy Service debug logging for a full trace of
#    which targeting items evaluated true or false
md %windir%\debug\usermode
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t REG_DWORD /d "0x00030002"
gpupdate /force /target:user

Step 6 is the one that actually answers the item-level targeting question. After enabling GPSvcDebugLevel and forcing a refresh, %windir%\debug\usermode\gpsvc.log shows the Drive Maps CSE processing each item in order:

[pid=0x1a34,tid=0x2f0] Entering ProcessGroupPolicyExDrives()
[pid=0x1a34,tid=0x2f0] GPO Display Name : Finance-Drive-Map
[pid=0x1a34,tid=0x2f0] Starting class <Drive> - F:.
[pid=0x1a34,tid=0x2f0] Policy is not flagged for removal.
[pid=0x1a34,tid=0x2f0] Completed class <Drive> - F:.
[pid=0x1a34,tid=0x2f0] Completed class <Drives>.

If the item’s targeting evaluates to false, the trace shows the item being skipped instead of a “Starting class” line proceeding to completion — the absence of the expected EVENT : success line for that specific drive letter is the tell. Turn debug logging back off once you have what you need — it is verbose and eats disk space:

# Disable GPSVC debug logging once you have the trace you need
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t REG_DWORD /d "0x00000000" /f

Common Causes

The Fix

The most common real cause behind “GPO applies, drive doesn’t map” is a targeting item that quietly stopped matching the people it was meant to — usually after a security group was rebuilt, or after someone edited the AND/OR logic without testing the new combination. Here is how to walk it end to end.

Open Group Policy Management Console, edit the GPO, and browse to User Configuration > Preferences > Windows Settings > Drive Maps. Double-click the affected drive map item, select the Common tab, and click Targeting to open the Targeting Editor.

# In the Targeting Editor, for each targeting item:
# 1. Confirm whether it should be Is or Is Not (Item Options menu)
# 2. Confirm the logical operator joining it to the item above (And / Or)
# 3. For a Security Group item, click Browse and reselect the group --
#    this forces the SID to be re-resolved against the current object,
#    not whatever was cached when the item was first created
# 4. Use Add Collection if you need parenthetical grouping, e.g.
#    (GroupA OR GroupB) AND OU=Finance, instead of a flat AND/OR chain
#    that evaluates left to right with no precedence

Save the change, then confirm it from the client side rather than trusting the console:

# Force a user-side-only refresh so you are not waiting on the
# background cycle (typically every 90-120 minutes)
gpupdate /force /target:user

# Confirm the GPO applied and check for any denial or filtering reason
gpresult /r

# If it still doesn't map, capture the GPSVC trace as covered in
# "How to Diagnose" to see exactly which targeting item excluded this user

If the Targeting Editor logic checks out and the item still doesn’t fire, move to the Security Group SID check next — it is the second most common cause and produces the exact same symptom (GPO applied, drive map silently skipped) with no visual difference in the Targeting Editor, because the editor displays the group’s current display name regardless of whether the stored SID still points at it.

How to Prevent It

Because targeting failures produce no error, prevention is mostly about making the logic reviewable rather than catching a specific failure after the fact.

Use the Label and Comment options on each targeting item (available from the Item Options menu in the Targeting Editor) to document what each item is supposed to restrict and why — a plain AND/OR chain with six unlabeled items is unreviewable six months later, and unreviewable logic is exactly what produces silent regressions. Treat any security group used in item-level targeting as tied to that GPO: if the group is ever deleted and recreated rather than just renamed, re-open every targeting item that references it.

Keep Authenticated Users or an equivalent broad Read grant on GPOs that carry user-side settings, and use item-level targeting rather than removing Authenticated Users from Security Filtering to achieve the same narrowing — it avoids reintroducing the MS16-072 computer-permission trap for a result item-level targeting already handles more granularly. Before rolling out a cumulative update broadly, check its known-issue notes for Group Policy Preferences regressions — Windows Server 2019 and 2022’s August 2024 updates briefly disabled selecting User in group for newly authored targeting items, exactly the kind of client-side behaviour change that would look identical to a genuine misconfiguration until you check the KB.

For the layer underneath all of this — whether the GPO itself is even reaching the OU it should — the general checklist in Group Policy Not Applying covers link scope, replication, and SYSVOL read failures that have nothing to do with preferences at all.

Final Thoughts

Item-level targeting is powerful precisely because it fails quietly — that is the design, not a defect. A targeting item that doesn’t match is meant to look identical to a targeting item that was never relevant in the first place. The cost of that design is that troubleshooting it requires proving what happened, not reading what went wrong, because nothing gets written down when a filter correctly (or incorrectly) excludes someone.

Once you separate the two layers — did the GPO apply, and did the specific preference item’s targeting logic evaluate true — the fix is usually a five-minute change in the Targeting Editor. The time sink is always in figuring out which layer you are actually looking at.