Mapped Network Drives Keep Disappearing at Login? Here’s the Persistent Fix
You sign into Windows 11 expecting to see:
P: Projects
S: Shared
F: Finance
But one or more drives have disappeared.
Perhaps they return after signing out and back in.
Perhaps they appear with a red cross until you double-click them.
Or perhaps everything works perfectly in the office but the drives disappear whenever the employee works from home.
The usual advice is:
“Tick Reconnect at sign-in.”
That helps.
It does not solve every mapped-drive problem.
A reliable mapping depends on four things:
the share must be reachable
the correct user must receive the mapping
the network must be ready when the mapping runs
and:
another policy or script must not undo it afterwards.
First: Missing or Merely Disconnected?
These symptoms mean different things.
Drive completely missing
The drive letter does not appear at all.
That usually means:
the mapping never ran
Group Policy did not target the user
a script failed
another policy deleted it
the network was unavailable when the mapping was created
Drive visible with a red cross
The mapping still exists, but Windows has not established the connection yet.
This often means:
network became available after sign-in
file server was temporarily unreachable
VPN had not connected
credentials needed refreshing
Drive works in File Explorer but not an elevated application
That is a different issue involving Windows security contexts and UAC.
Do not use the same fix for all three.
Step 1: Test the Share Without the Drive Letter
Before fixing the mapping, prove that the underlying share works.
Press:
Windows + R
and enter:
\\FileServer\Projects
The folder opens
Good.
The server, share and basic permissions are working.
Focus on the drive mapping.
The folder does not open
A persistent mapping cannot repair an unreachable share.
Investigate:
network connectivity
VPN
DNS
server availability
SMB access
permissions
credentials
You can also test SMB connectivity in PowerShell:
Test-NetConnection -ComputerName FileServer -Port 445
If the server works by IP address but not by hostname, investigate DNS rather than drive persistence.
Step 2: See What Windows Thinks Is Mapped
Open Command Prompt and run:
net use
Look for the affected drive.
Possible states include:
OK
Disconnected
Unavailable
Also look for:
duplicate drive letters
old server paths
mappings to retired servers
several connections to the same server using different accounts
The distinction matters.
If net use still shows:
P: → \FileServer\Projects
then the mapping exists.
If P: is absent entirely, something failed to create it—or removed it.
Step 3: Remove a Broken Mapping Cleanly
For one mapping:
net use P: /delete
Then recreate it.
Avoid using:
net use * /delete /y
unless you genuinely intend to disconnect every network mapping in that user session.
Close documents using network drives first.
Step 4: Create a Persistent Manual Mapping
For a simple manually managed PC:
net use P: \\FileServer\Projects /persistent:yes
Or through File Explorer:
This PC > Map network drive
Select:
Reconnect at sign-in
That tells Windows to remember the mapping.
But this is the important bit:
Persistent does not mean Windows will patiently wait forever for the server to become available.
If Wi-Fi, VPN or the domain network is unavailable when Windows attempts the reconnection, the drive can still appear disconnected or fail to appear as expected. Your current article already explains this correctly.
Step 5: If It Works After a Second Sign-In, Suspect Timing
This is one of the strongest clues.
Imagine:
First login → drive missing
Sign out
Sign in again → drive appears
The credentials and mapping itself are probably fine.
The difference is that the network was fully ready the second time.
For domain-joined PCs, Windows can allow users to reach the desktop before all network-dependent Group Policy processing has completed.
Microsoft documents that Drive Maps is one of the Group Policy extensions affected by asynchronous logon processing.
Step 6: Make Domain PCs Wait for the Network
For appropriate Active Directory environments, enable:
Computer Configuration > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon
Microsoft says this changes policy processing so Windows waits for the network during startup/logon instead of relying on background processing for network-dependent extensions.
This can solve the classic:
mapping works after second login
problem.
However, there is a trade-off:
login may take longer.
That is particularly noticeable on:
laptops
weak Wi-Fi
remote machines without domain connectivity
So test it before deploying it across the entire organisation.
Step 7: Use Group Policy Preferences for Domain Drive Maps
For traditional Active Directory environments, drive mappings are usually cleaner when managed centrally with:
User Configuration > Preferences > Windows Settings > Drive Maps
Configure:
Location: \\FileServer\Projects
Drive letter: P:
Reconnect: Enabled
meaningful label
Then choose the correct action.
Update vs Replace Matters
This is a very important detail.
Update
Modifies an existing mapping or creates it if required.
For an ordinary permanent drive mapping, this is generally the better default.
Replace
Deletes the existing mapping and creates it again.
That sounds harmless.
It can cause problems if Group Policy refreshes while employees have files open because the drive may temporarily disappear and reconnect.
Create
Creates the mapping only if it does not already exist.
It may not correct an existing mapping pointing at the wrong location.
Delete
Removes it.
For stable everyday mappings, I would normally start with:
Update
rather than permanently using Replace.
Step 8: Check Group Policy Targeting
If only some employees lose the drive, check whether the mapping is being targeted correctly.
Drive-map preferences may be scoped using:
security groups
OUs
users
computers
IP ranges
sites
operating systems
Generate a report:
gpresult /h C:\Temp\DriveMapping.html
Open it and confirm the expected GPO is actually applying.
Microsoft’s current mapped-drive troubleshooting guidance specifically recommends tracing the applied Group Policy and looking for other scripts or GPOs that may be changing or deleting the mapping.
Step 9: Look for Conflicting Scripts
This is one of the most common causes in older business environments.
The same P: drive may be controlled by:
Group Policy Preferences
login script
scheduled task
Intune script
RMM script
manual mapping
One process creates:
P: → \NewServer\Projects
while another old script still runs:
net use P: /delete
Microsoft documented a real mapped-drive failure scenario where Group Policy was applying correctly, but another logon script was subsequently deleting the drive.
The long-term fix is:
one mapping → one owner.
Do not manage the same drive letter in four different places.
Step 10: Remote Users Need a Different Approach
A persistent mapping cannot connect to an internal file server that does not yet exist from the laptop's point of view.
Typical home-working sequence:
1. User signs into Windows.
2. Drive-map policy runs.
3. Internal server is unreachable.
4. Desktop appears.
5. VPN connects.
6. File server becomes reachable.
The mapping attempt happened too early.
Better options can include:
pre-logon VPN
Always On VPN
reconnect script triggered after VPN
scheduled task triggered by network availability
retry logic
Do not delay every office employee's login by 60 seconds just because remote laptops need to wait for a VPN.
A Retrying Script Can Be Better Than a Fixed Delay
If the network typically becomes available shortly after sign-in, test for the actual share rather than blindly waiting a fixed number of seconds.
For example:
$Drive = "P"
$Share = "\\FileServer\Projects"
for ($i = 1; $i -le 6; $i++) {
if (Test-Path $Share) {
if (Get-PSDrive -Name $Drive -ErrorAction SilentlyContinue) {
Remove-PSDrive -Name $Drive -Force -ErrorAction SilentlyContinue
}
New-PSDrive `
-Name $Drive `
-PSProvider FileSystem `
-Root $Share `
-Persist
exit
}
Start-Sleep -Seconds 10
}
This waits for the thing you actually need:
the file share.
Microsoft has also published a retry-based workaround for unavailable persistent mappings and notes that scripts creating mapped drives should run in the standard user's security context, not elevated, if they need to appear in that user's File Explorer session.
Do Not Run the Mapping as SYSTEM
Mapped drives belong to a logon session.
A scheduled task running as:
SYSTEM
may successfully access:
\\FileServer\Projects
but that does not mean the signed-in employee will see:
P:
in File Explorer.
Likewise, Microsoft warns that mappings created in an elevated context may not appear to the standard user session.
Run user-visible drive mappings in the user's normal security context.
Check Credentials Only When Credentials Are Actually the Problem
If Windows prompts repeatedly for credentials or reports an authentication failure, inspect:
Credential Manager > Windows Credentials
Remove obsolete credentials for the server where necessary.
Then reconnect using the correct account.
Do not put passwords directly into scripts such as:
net use P: \\Server\Share /user:DOMAIN\User Password123
That leaves credentials exposed in scripts, logs or command history.
Allow Windows to prompt securely or use properly managed authentication.
Wi-Fi Can Be the Cause Even When Wi-Fi “Works”
A laptop may reach the desktop before enterprise Wi-Fi authentication is complete.
If:
Ethernet login → drives appear every time
but:
Wi-Fi login → mappings intermittently fail
investigate:
Wi-Fi authentication
wireless driver
802.1X timing
domain connectivity before login
Group Policy timing
The mapped-drive command may be perfectly correct.
It is simply running too early.
Do You Still Need Mapped Drives?
This deserves a place in a 2026 version.
Mapped drives remain completely valid for:
line-of-business applications
large local file servers
specialist workflows
legacy applications
But some general collaboration data may be better suited to:
SharePoint
Teams
OneDrive
particularly for hybrid workers.
That does not mean:
“Replace every file server with SharePoint.”
It means businesses should stop rebuilding increasingly elaborate VPN/login scripts merely to preserve a mapped drive when the workload itself no longer requires SMB file access.
The Best Troubleshooting Order
If a mapped network drive keeps disappearing:
1. Open the UNC path directly.
2. Run net use.
3. Determine whether the drive is missing or merely disconnected.
4. Remove stale mappings.
5. Confirm persistence/reconnect is enabled.
6. Determine who actually owns the mapping.
7. Check Group Policy targeting.
8. Check for conflicting scripts or policies.
9. If it fails only at first login, investigate network timing.
10. Use Always wait for the network where appropriate for domain devices.
11. Handle VPN-dependent mappings after the VPN becomes available.
12. Run mappings in the normal user's security context.
13. Use one authoritative mapping method.
14. Consider whether the workload still genuinely requires a drive letter.
The key principle is:
Do not keep remapping the drive. Find out why the original mapping is not surviving or reconnecting.
How Hamilton Group Can Help
Hamilton Group can help businesses diagnose recurring mapped-drive problems involving:
Windows 11
Active Directory
Group Policy
file servers
SMB
VPN
Wi-Fi
DNS
user permissions
PowerShell
network migrations
For businesses, we can also rationalise old drive-mapping scripts and policies so one controlled configuration owns each mapping instead of several legacy systems repeatedly overwriting one another.
Visit hgmssp.com or call 0330 043 0069 to discuss Windows, server and network support.