Mapping drives with a logon script is a habit from a decade ago. It still runs, but it’s clumsy: targeting different drives to different teams means if statements and group checks, errors are silent, and the next admin has to read your batch file to figure out what’s happening. Group Policy Preferences replaced all of that with a configuration item you point and click through, with proper targeting and actions built in.
The Drive Maps preference lets you map a share to a drive letter, decide whether to create, update, replace, or delete it, and target it to specific users or groups — without a single line of script. This guide covers building a Drive Maps item, choosing the right action (this is where most problems start), targeting it cleanly, and fixing the drives-don’t-appear issues that come up.
Why Preferences beat logon scripts
Group Policy Preferences treat a drive mapping as an object you manage, not a command you run. That brings a few concrete wins:
- Item-level targeting — map a drive only for members of a security group, a specific OU, an operating system, or dozens of other conditions, all from a dialog.
- Actions — create, update, replace, or delete a mapping, so one item can both add new drives and clean up old ones.
- Error handling — failures are logged to the event log instead of vanishing, which makes troubleshooting tractable.
You still need a working file share with sane NTFS and share permissions behind it. Preferences map the drive; they don’t grant access. If the user can’t reach \\fileserver\finance in Explorer, a GPP item won’t change that.
Create a Drive Maps item
Build a GPO and link it where your users live, then edit it:
- In Group Policy Management, create a new GPO (for example
Map-Drives) and link it to the OU containing your users. - Right-click it and choose Edit.
- Navigate to User Configuration > Preferences > Windows Settings > Drive Maps.
- Right-click Drive Maps and choose New > Mapped Drive.
In the dialog, set:
Drive Maps item — key fields
| Action | Update (recommended for most mappings — see the next section) |
|---|---|
| Location | The UNC path, e.g. \\fileserver\finance |
| Reconnect | Ticked, so the drive persists across logons |
| Label as | A friendly name shown in Explorer, e.g. 'Finance (F:)' |
| Drive Letter | Use existing or assign a specific letter such as F: |
Set the action to Update, enter the UNC path, tick Reconnect, give it a label, assign the drive letter, and click OK. That’s a working mapping for everyone the GPO applies to. The next two sections make it correct and targeted.
Choose the right action — this is where drives break
The Action field has four options, and picking the wrong one causes most “the drive keeps dropping” complaints.
Drive Maps actions
| Create | Maps the drive only if it doesn't already exist. Never updates it afterward. |
|---|---|
| Update | Creates the drive if missing, refreshes its settings if present. The safe default. |
| Replace | Deletes the existing mapping and recreates it on every policy refresh. |
| Delete | Removes the mapping. Use it to retire an old drive letter. |
Update is the right choice almost always. It quietly keeps the mapping correct without disturbing it.
Replace is the trap. Because it deletes and recreates the drive on every Group Policy refresh, an open file or an idle session can hit the moment the drive is briefly gone — which surfaces as the mapping disconnecting, an open document throwing a network error, or Explorer flashing the drive away and back. Microsoft has documented this exact behavior, where a Replace-based drive mapping disconnects and reconnects on each refresh and causes “network access was interrupted” errors. If your drives are misbehaving and the action is Replace, switch it to Update before anything else.
Target the drive with item-level targeting
A single GPO usually maps several drives, and not everyone should get all of them. Item-level targeting solves that without separate GPOs per team.
On the Drive Maps item, go to the Common tab, tick Item-level targeting, and click Targeting. The Targeting Editor lets you build conditions — the most common is Security Group:
- Click New Item > Security Group.
- Browse to the group, e.g.
CORP\Finance. - Confirm. Now the drive only maps for members of that group.
You can stack conditions with And/Or and even nest them. A typical setup maps a department share to its group and a shared “company” drive to everyone:
Example targeting plan
| S: Company (all staff) | No targeting, or target Domain Users |
|---|---|
| F: Finance | Security Group = CORP\Finance |
| H: HR | Security Group = CORP\HR |
| E: Engineering | Security Group = CORP\Engineering |
Targeting by group is far more maintainable than by user. Add someone to the Finance group and they get F: at next logon; remove them and it goes away. No GPO edits needed.
Apply and verify
Mapped drives apply at logon (and at background refresh for Update). To test without waiting:
gpupdate /forceThen log off and back on — drive maps fully apply during logon, so a refresh alone may not show the new drive. After logging back in, confirm the drive is there:
Get-PSDrive -PSProvider FileSystem
net useTo prove the GPO is reaching the user and see whether the preference applied, run the resultant-set-of-policy report:
gpresult /h C:\gpresult.htmlOpen that HTML report and look under the user’s settings for the Drive Maps preference and its result. If the GPO isn’t listed at all, the problem is GPO scope (link, security filtering, or the user being in the wrong OU), not the drive item itself.
When drives don’t appear
A handful of issues come up repeatedly:
- Nothing maps. The GPO isn’t reaching the user. Check the link location, security filtering, and that the user account sits under the OU the GPO is linked to.
gpresult /htells you fast. - Drive shows a red X but works when clicked. Usually harmless — Windows shows reconnectable drives as disconnected until something touches them. The mapping reconnects on access.
- Drive drops mid-session. Almost always the Replace action. Switch to Update.
- Drive missing from an elevated command prompt. This is by design. User Account Control gives elevated processes a separate token, and drives mapped under the standard token aren’t visible to it. When you genuinely need the mapping in both contexts, Microsoft documents the
EnableLinkedConnectionsregistry value as the supported workaround:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
-Name "EnableLinkedConnections" -Value 1A reboot is needed for that to take effect. Test it before rolling it out broadly, since it changes how mapped drives behave across the UAC token split.
Drive mapping checklist
- GPO is linked to the OU where the user accounts live
- Drive Maps item is under User Configuration > Preferences
- Action is set to Update, not Replace
- Reconnect is ticked so the drive persists
- Item-level targeting maps each drive to the right security group
- The underlying share grants the user share + NTFS access
- Verified with gpresult /h after a fresh logon
Wrapping up
Group Policy Preferences make drive mapping a configuration task instead of a scripting one. Create a Drive Maps item under User Configuration, set the action to Update, point it at the UNC path, and use item-level targeting by security group so each team gets only the drives it should. That covers the vast majority of real-world setups cleanly.
When something goes wrong, the two usual suspects are the Replace action dropping drives mid-session and the GPO not actually scoping to the user. Check the action first, then confirm scope with gpresult /h. If you’re managing other settings the same way, the troubleshooting steps when Group Policy isn’t applying apply here too.
