Mapped Network Drives Keep Disappearing at Login — The Persistent Fix

31 Jul 2026
Mapped Network Drives Keep Disappearing at Login — The Persistent Fix

You sign in to Windows 11 expecting to see the usual shared folders under This PC, but one or more mapped network drives have disappeared.

Sometimes they return after signing out and back in. Sometimes they show a red cross until you double-click them. On remote laptops, the drives may not appear until the VPN connects. In other cases, the mapping works manually but vanishes again after the next restart.

The problem is often described as a “non-persistent” drive mapping, but ticking Reconnect at sign-in is only part of the solution.

A mapped drive can disappear because Windows attempts to restore it before the network is ready, the drive is being recreated incorrectly through Group Policy, the VPN connects too late, credentials no longer match or several management methods are fighting over the same drive letter.

The persistent fix is to identify who owns the mapping, ensure the network is available before it runs and use one reliable deployment method rather than repeatedly remapping the drive by hand.

What Is a Mapped Network Drive?

A mapped network drive assigns a drive letter to a shared network location.

For example:

P: → \\FileServer\Projects

Instead of browsing to the full UNC path each time, users can open P: from File Explorer and work with the shared folder like a local drive.

Mapped drives are commonly used for:

  • Departmental file shares
  • Personal home folders
  • Finance and payroll data
  • Shared templates
  • Project directories
  • Line-of-business application data
  • Scanned documents
  • Archive locations

Windows can create mappings manually, through the net use command, PowerShell, a logon script or Group Policy Preferences. Microsoft’s Drive Maps preference extension was designed specifically to manage drive-letter mappings through Group Policy. 

Why Do Mapped Drives Disappear at Login?

The most common causes are:

  • The network is not ready when Windows restores the mapping
  • Wi-Fi has not connected before sign-in completes
  • A VPN is established only after the desktop appears
  • Group Policy applies before a domain controller or file server is reachable
  • A drive-map preference uses an unsuitable action
  • The mapping was created without persistence
  • Stored credentials are invalid or belong to another account
  • The same drive letter is defined by several scripts or policies
  • The server name cannot be resolved through DNS
  • The file server, NAS or share is temporarily unavailable
  • An elevated application cannot see mappings created in the normal user session
  • The user no longer has permission to the share
  • An old mapping remains cached

Microsoft documents a current troubleshooting scenario for drive mappings that do not apply correctly through Group Policy, which reflects how many parts of policy processing, connectivity and user context can affect the result. 

First: Is the Drive Missing or Merely Disconnected?

A mapped drive can behave in several different ways.

Completely missing

The drive letter does not appear under This PC.

This usually means:

  • The mapping never ran
  • It was deleted by another policy
  • The user was not targeted by the mapping
  • The logon script failed
  • The network was unavailable at mapping time

Visible with a red cross

The drive appears but Windows has not yet established the connection.

Double-clicking it may reconnect immediately.

This often indicates:

  • The network became ready after sign-in
  • Windows restored the persistent mapping before the server was reachable
  • The VPN was not connected
  • Credentials needed to be refreshed

Visible in File Explorer but missing from an elevated application

This is a different issue involving User Account Control and separate security contexts. Microsoft documents that mapped drives may not be visible in an elevated command prompt or application even though they exist in the standard user session. 

Do not apply drive-remapping fixes until you know which symptom you actually have.

Step 1: Confirm That the Share Is Reachable

Press:

Windows key + R

Enter the UNC path directly:

\\FileServer\Projects

If the share opens, the server and permissions are broadly working, and the problem may be limited to the drive mapping.

If it does not open, investigate:

  • Network connectivity
  • VPN status
  • DNS resolution
  • Server availability
  • Share permissions
  • NTFS permissions
  • Firewall rules
  • Stored credentials

A mapped drive cannot reconnect when the underlying UNC path is unavailable.

Step 2: Test the Server Name

Open Command Prompt and run:

ping FileServer

Then:

nslookup FileServer

The server may intentionally block ping, so a failed ping alone does not prove it is offline. However, nslookup should normally resolve the server name to the expected address.

You can also test the file-sharing port in PowerShell:

Test-NetConnection -ComputerName FileServer -Port 445

A successful result confirms that the SMB service is reachable over TCP port 445.

If the server works by IP address but not by hostname, the issue is likely related to DNS rather than drive persistence.

Avoid permanently mapping drives using raw IP addresses unless there is a specific design requirement. Server names are generally easier to maintain and align better with domain authentication.

Step 3: Check the Existing Mappings

Open Command Prompt and run:

net use

This displays current network connections and their status.

You may see:

  • OK
  • Disconnected
  • Unavailable

Look for:

  • Duplicate mappings
  • The same server connected with several usernames
  • The wrong UNC path
  • Old drive letters
  • Connections to retired servers
  • A mapping with an unexpected status

The net use command can display, create and remove network connections. 

Step 4: Remove a Broken Mapping Cleanly

To remove one mapping:

net use P: /delete

To remove all current mapped connections:

net use * /delete /y

Be cautious with the second command. It disconnects every active network mapping in that user session.

Close documents and applications using network files first.

If Windows reports that the connection already exists under another username, clearing stale sessions and stored credentials may be necessary before remapping. Microsoft guidance and support discussions commonly recommend clearing existing net use connections when hidden or conflicting SMB sessions are present. 

Step 5: Recreate the Drive as a Persistent Mapping

To create a persistent mapping manually:

net use P: \\FileServer\Projects /persistent:yes

Windows should remember the connection for future sign-ins.

To specify a different account:

net use P: \\FileServer\Projects /user:DOMAIN\UserName /persistent:yes

Allow Windows to prompt securely for the password.

Do not place plaintext passwords inside logon scripts, batch files or command histories.

PowerShell can also create a persistent Windows drive:

New-PSDrive `

    -Name "P" `

    -PSProvider FileSystem `

    -Root "\\FileServer\Projects" `

    -Persist

Microsoft documents that New-PSDrive can create persistent Windows mapped network drives when used with a filesystem location and the -Persist switch. 

Step 6: Tick “Reconnect at Sign-In” for Manual Mappings

When mapping through File Explorer:

  1. Open This PC.
  2. Select Map network drive.
  3. Choose a drive letter.
  4. Enter the shared-folder path.
  5. Tick Reconnect at sign-in.
  6. Select Finish.

This stores the mapping for future sessions.

However, it does not guarantee that the network will be ready when Windows tries to restore it. That is why some drives still appear disconnected or missing even though persistence is enabled.

Step 7: Make Windows Wait for the Network

Domain-joined Windows devices can process logon more quickly by allowing the user interface to appear before all network-dependent policy processing has finished.

When drive mappings depend on Active Directory, DNS or a file server, the mapping can run too early.

Enable:

Computer Configuration > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon

This tells Windows to wait for the network before completing computer startup and user logon policy processing.

This setting is frequently recommended when drive mappings fail during the first sign-in but work after signing out and back in. 

Important trade-off

Enabling the policy can lengthen sign-in time, especially on laptops with slow Wi-Fi, unavailable domain connectivity or poor DNS.

Test it on a small device group before applying it organisation-wide.

Step 8: Use Group Policy Preferences for Business Drive Maps

For an Active Directory environment, Group Policy Preferences is usually more manageable than manual mappings on every computer.

Open Group Policy Management and navigate to:

User Configuration > Preferences > Windows Settings > Drive Maps

Create or edit the drive mapping.

Configure:

  • Location: \\FileServer\Projects
  • Drive letter: P:
  • Reconnect: Enabled
  • Label: A useful business name
  • Action: Usually Update

Microsoft’s Drive Maps preference extension is designed to manage remote drive letters and apply mappings during policy processing. 

Which Group Policy Action Should You Use?

Group Policy Preferences provides four actions:

  • Create
  • Replace
  • Update
  • Delete

The chosen action can have a major effect on reliability.

Update

Update changes the existing mapping or creates it when it does not exist.

This is usually the safest default for a persistent everyday drive mapping because it avoids deleting and recreating the connection during every policy refresh.

It can update settings while preserving aspects that are not explicitly changed.

Replace

Replace deletes the existing mapping and recreates it.

This can help clear a corrupted or outdated mapping, but it can also disconnect users from open files when Group Policy refreshes.

Using Replace permanently may result in:

  • Brief drive disconnections
  • Applications losing file handles
  • Open documents reporting network errors
  • Drives disappearing and reappearing during policy refresh

Use it temporarily when you intentionally need to rebuild a mapping, then consider returning to Update.

Microsoft support guidance commonly recommends Update for normal ongoing mappings and warns that Replace removes and recreates the drive. 

Create

Create adds the mapping only when it does not already exist.

It may not correct an existing mapping that points to the wrong server or path.

Delete

Delete removes the specified mapping.

This is useful during migrations or when retiring a drive letter.

Step 9: Enable the Reconnect Option in Group Policy

Inside the Drive Maps preference item, ensure Reconnect is enabled.

This instructs Windows to retain the mapped connection.

Persistence still depends on:

  • Network availability
  • Correct credentials
  • Policy targeting
  • Server availability
  • The absence of conflicting scripts

Reconnect should be part of the configuration, not the only troubleshooting step.

Step 10: Review Item-Level Targeting

Group Policy Preferences can target a mapping using criteria such as:

  • Security-group membership
  • Computer name
  • Organisational unit
  • IP range
  • Operating system
  • Site
  • User
  • Registry value

Open the drive-map preference item and review:

Common > Item-level targeting

A drive may disappear because the device or user no longer matches the targeting rule.

Check for:

  • Renamed security groups
  • Nested-group membership delays
  • Incorrect AND/OR logic
  • Old IP subnet conditions
  • WMI filters
  • Site membership
  • Laptop versus desktop conditions

Generate a Group Policy report on an affected computer:

gpresult /h C:\Temp\DriveMappingPolicy.html

Open the report and confirm that the intended GPO is applied rather than denied or filtered out.

Step 11: Stop Using “Use First Available” Carelessly

Group Policy Drive Maps can assign the first available drive letter.

That sounds convenient, but it can remove or interfere with mappings created manually.

Microsoft documents an issue in which Group Policy Preferences can remove manual drive mappings when the Use first available setting is enabled. 

For predictable business deployments, assign fixed drive letters and document them.

For example:

  • H: Home folder
  • P: Projects
  • S: Shared
  • F: Finance

Avoid letters commonly used by:

  • USB drives
  • Card readers
  • Optical drives
  • Application-created virtual disks

Step 12: Check for Conflicting Logon Scripts

A drive may be created by several different mechanisms:

  • Group Policy Preferences
  • User logon script
  • Computer startup script
  • Active Directory user-profile script
  • Scheduled task
  • Microsoft Intune script
  • RMM platform
  • Manual mapping
  • Application installer

One method may map the drive while another removes or changes it.

Search scripts for commands such as:

net use

New-PSDrive

Remove-PSDrive

Also check the user account’s Profile tab in Active Directory for an assigned logon script.

The persistent fix is to give one platform ownership of the mapping and retire the others.

Step 13: Account for Wi-Fi Timing

A laptop may reach the Windows desktop before wireless networking has fully connected.

This is particularly common when:

  • Wi-Fi authentication is user-based
  • The device has not joined the wireless network before sign-in
  • Signal strength is poor
  • The wireless driver starts slowly
  • 802.1X authentication is delayed
  • The machine moves between office locations

Test the device through Ethernet.

If the drives consistently appear on wired connections but fail on Wi-Fi, focus on:

  • Wireless authentication
  • Driver and firmware
  • Domain connectivity
  • The wait-for-network policy
  • Logon-script timing

For domain devices, computer-based Wi-Fi authentication can allow network connectivity before the user signs in, depending on the organisation’s wireless design.

Step 14: Account for VPN Timing

A drive mapping to an internal file server cannot succeed before the VPN connects.

When users sign in from home:

  1. Windows loads the desktop.
  2. The drive-mapping policy or script runs.
  3. The corporate server is unreachable.
  4. The VPN connects later.
  5. The drive remains missing or disconnected.

A standard persistent mapping cannot solve this timing problem by itself.

Better options include:

  • Pre-logon VPN
  • Always On VPN
  • A scheduled task triggered by VPN connection
  • A script that retries after the network becomes available
  • A user-accessible reconnect shortcut
  • Migrating suitable shared content to SharePoint and OneDrive

Do not add a fixed 60-second delay to every office login merely to accommodate remote VPN users unless there is no better trigger.

Step 15: Use a Delayed Reconnection Script

Where the network genuinely becomes available shortly after sign-in, a retrying PowerShell script can be more reliable than a single immediate mapping attempt.

Example:

$DriveLetter = "P"

$SharePath = "\\FileServer\Projects"

$MaxAttempts = 6

$DelaySeconds = 10


 

for ($attempt = 1; $attempt -le $MaxAttempts; $attempt++) {

    if (Test-Path $SharePath) {

        if (Get-PSDrive -Name $DriveLetter -ErrorAction SilentlyContinue) {

            Remove-PSDrive -Name $DriveLetter -Force -ErrorAction SilentlyContinue

        }


 

        New-PSDrive `

            -Name $DriveLetter `

            -PSProvider FileSystem `

            -Root $SharePath `

            -Persist `

            -ErrorAction Stop


 

        exit 0

    }


 

    Start-Sleep -Seconds $DelaySeconds

}


 

Write-Error "Unable to reach $SharePath after $MaxAttempts attempts."

exit 1

This waits for the actual share rather than assuming the network will be ready after an arbitrary delay.

Deploy scripts carefully and log failures so they do not silently mask server, DNS or permission problems.

Step 16: Use Task Scheduler for VPN-Dependent Mappings

A scheduled task can map drives:

  • At user logon
  • After a delay
  • When a network event occurs
  • When a VPN-related event is logged

Configure the task to run as the signed-in user, because mapped drives belong to the user’s session.

A task running as SYSTEM may successfully access the share but will not necessarily create a drive visible in the user’s File Explorer.

Do not run a drive-map task with elevated privileges unless there is a specific reason. Elevation can create a mapping in a separate security context.

Step 17: Check Credential Manager

Open:

Control Panel > Credential Manager > Windows Credentials

Look for credentials associated with:

  • The file server
  • The NAS
  • The server’s fully qualified domain name
  • The server’s IP address

Remove obsolete entries carefully, then reconnect using the correct account.

Problems can arise when Windows tries to connect to the same server with:

  • A domain account
  • A local server account
  • Old credentials
  • A different Microsoft account
  • Another user already cached in the session

Windows normally prevents simultaneous connections to the same server using different usernames in one session.

Use domain-integrated authentication where possible instead of maintaining separate stored passwords for every drive.

Step 18: Understand Windows Hello and PIN Sign-In

A Windows Hello PIN unlocks the credential protected on that device; it is not simply sent to the file server as a network password.

In a properly configured domain or Microsoft Entra environment, network authentication should still work through the user’s organisational identity.

Problems arise more often when:

  • The share uses a separate local account
  • Stored credentials are missing
  • The device is outside the domain
  • The NAS does not support the organisation’s normal identity system
  • The password has changed but stored credentials have not

Do not place the user’s password in a script to work around this. Correct the authentication and credential-storage design.

Step 19: Use the Full Server Name Consistently

Do not mix these names casually:

\\FileServer\Projects

\\FileServer.domain.local\Projects

\\192.168.1.20\Projects

Windows may treat them as different connection targets, even when they reach the same server.

This can create:

  • Duplicate credential prompts
  • Conflicting SMB sessions
  • Multiple cached connections
  • Authentication inconsistencies

Choose the approved server name and use it consistently in:

  • Group Policy
  • Scripts
  • Shortcuts
  • Applications
  • Documentation

Step 20: Check Share and NTFS Permissions

A drive can appear to vanish when the mapping policy is applied but the user cannot access the destination.

Review both:

  • Share permissions
  • NTFS permissions

The effective access is determined by the combination.

Check:

  • Security-group membership
  • Nested groups
  • Removed inheritance
  • Explicit deny entries
  • Recently migrated folders
  • DFS permissions
  • Whether the user can open the UNC path directly

Do not grant broad access merely to make the drive appear. Correct the intended group membership and permissions.

Step 21: Check Drive-Letter Conflicts

A mapped drive cannot reliably use a letter already assigned to:

  • A USB device
  • A local partition
  • An optical drive
  • A card reader
  • Another network mapping
  • A virtual-disk application

Open Disk Management:

diskmgmt.msc

Review local drive letters.

Also run:

net use

to review network mappings.

Choose a drive letter that is consistently free across the fleet.

Step 22: Check Offline Files

Windows Offline Files can cache network content for use when disconnected.

When misconfigured or corrupted, it can cause confusing behaviour involving:

  • Stale data
  • Sync conflicts
  • Slow sign-in
  • Shares appearing unavailable
  • Unexpected offline status

Open Sync Centre and check whether the share is configured for offline access.

Do not clear the Offline Files cache casually. Unsynchronised changes could be lost.

For modern cloud-managed work, consider whether OneDrive or SharePoint is a better fit than Offline Files for the affected data.

Step 23: Check DFS Referrals

The mapped path may use Distributed File System:

\\domain.local\Shares\Projects

In that case, the mapping depends on:

  • Domain connectivity
  • DNS
  • DFS namespace availability
  • Correct referrals
  • Reachability of the selected file server

Test both:

  • The DFS path
  • The direct backend share

For example:

\\domain.local\Shares\Projects

and:

\\FileServer02\Projects$

Do not permanently replace a designed DFS path with a direct server mapping merely because the latter works. Investigate the namespace, site or referral issue.

Step 24: Check Group Policy Event Logs

Open Event Viewer and review:

Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational

Look for events around the user’s sign-in.

Check for:

  • GPO processing failures
  • Slow-link detection
  • Network-unavailable messages
  • Drive Maps client-side extension errors
  • Access denied
  • Path not found
  • Security filtering problems

Microsoft’s current troubleshooting guide recommends collecting Group Policy diagnostic data when a drive-map GPO does not apply as expected. 

Step 25: Run a Group Policy Update

On an affected device:

gpupdate /force

Then review whether the drive appears.

If the mapping appears after a manual policy refresh but not at initial sign-in, that strongly suggests a timing or connectivity issue.

It may mean:

  • The network was not ready
  • A domain controller was unavailable
  • Wi-Fi or VPN connected later
  • The Drive Maps extension initially failed

Do not solve this by telling every user to run gpupdate. Correct the policy timing or connectivity.

Step 26: Check Whether Fast Startup Is Confusing the Test

Fast Startup does not perform the same full reload as a restart.

When troubleshooting:

  • Use Restart, not only Shut down
  • Compare restart with sign-out and sign-in
  • Compare wired and wireless startup
  • Test on-site and remotely

If the drive returns after sign-out but not after startup, focus on early network availability and user policy processing.

Step 27: Check Server and SMB Availability

If several users lose the same drive simultaneously, the issue is unlikely to be an individual Windows mapping problem.

Investigate:

  • File-server uptime
  • SMB service
  • Server event logs
  • Network switch
  • DNS
  • Storage availability
  • Failover cluster
  • DFS namespace
  • Authentication services

A drive-remapping script will not fix a file server that is intermittently unavailable.

Step 28: Avoid Legacy SMB Workarounds

Do not enable SMBv1 merely because an old NAS cannot connect reliably.

SMBv1 is obsolete and lacks modern security protections.

A better long-term response is to:

  • Update the NAS firmware
  • Enable a supported SMB version
  • Replace unsupported storage
  • Move the data to a supported file server or cloud platform

Do not weaken the security of every Windows device to preserve one ageing appliance.

Step 29: Decide Whether a Drive Letter Is Still Necessary

Mapped drives remain useful for:

  • Applications that require a drive letter
  • Traditional departmental file shares
  • Large LAN-based datasets
  • Specialist equipment
  • Legacy workflows

They are less suitable for:

  • Highly mobile users
  • Files required before VPN connection
  • Multi-device collaboration
  • External sharing
  • Browser-based work
  • Teams-centric document management

SharePoint and OneDrive can provide:

  • Internet-based access
  • Version history
  • Co-authoring
  • Search
  • Mobile access
  • Sharing controls

Do not migrate blindly. Applications, permissions, file types, path lengths and user workflows must be assessed first.

The Persistent Fix for a Single PC

For one unmanaged or small-office computer:

  1. Confirm that the UNC path works.
  2. Remove the broken mapping.
  3. Clear incorrect stored credentials.
  4. Recreate the mapping with Reconnect at sign-in.
  5. Use /persistent:yes.
  6. Use a consistent server name.
  7. Ensure Wi-Fi or VPN is connected.
  8. Test after a full restart.
  9. Use a delayed user-level task if the network connects late.

Example:

net use P: /delete

net use P: \\FileServer\Projects /persistent:yes

The Persistent Fix for a Domain Environment

For an Active Directory-managed business:

  1. Choose Group Policy Preferences as the mapping owner.
  2. Remove duplicate logon scripts and manual mappings.
  3. Use fixed drive letters.
  4. Use Update for normal mappings.
  5. Enable Reconnect.
  6. Configure appropriate item-level targeting.
  7. Enable Always wait for the network for affected device groups where justified.
  8. Ensure pre-sign-in network connectivity where possible.
  9. Create a separate approach for VPN-only users.
  10. Monitor Group Policy logs and file-server availability.

The Persistent Fix for Remote Users

For remote or hybrid users:

  1. Confirm that the file share should remain an SMB mapped drive.
  2. Use pre-logon or Always On VPN where appropriate.
  3. Avoid mapping before the VPN is available.
  4. Trigger the mapping when connectivity exists.
  5. Use retries rather than one immediate command.
  6. Consider SharePoint or OneDrive for collaboration-based content.
  7. Keep applications requiring SMB separate from general document storage.

What Not to Do

Avoid:

  • Putting passwords in batch files
  • Mapping the same letter through several systems
  • Using Replace permanently without understanding policy refresh
  • Enabling SMBv1
  • Mapping drives by IP to hide DNS problems
  • Adding arbitrary delays without testing connectivity
  • Running user mappings as SYSTEM
  • Clearing Offline Files without protecting unsynchronised data
  • Granting Everyone full access to solve permissions
  • Telling users to remap the drive manually every morning
  • Ignoring recurring server or network outages

The Best Troubleshooting Order

Work through the issue in this sequence:

  1. Check whether the drive is missing or merely disconnected.
  2. Open the UNC path directly.
  3. Confirm DNS and TCP port 445 connectivity.
  4. Review net use.
  5. Remove stale mappings.
  6. Clear incorrect stored credentials.
  7. Recreate the drive with persistence enabled.
  8. Check drive-letter conflicts.
  9. Identify whether GPO, script, Intune or manual setup owns the mapping.
  10. Review Group Policy action and Reconnect settings.
  11. Check item-level targeting and security-group membership.
  12. Run gpresult and review Group Policy events.
  13. Test whether the problem is Wi-Fi or VPN timing.
  14. Enable network-wait policy for the appropriate devices.
  15. Use a connectivity-aware retry script where required.
  16. Investigate server, DFS and network availability.
  17. Modernise the storage method when mapped drives no longer suit the workforce.

How Hamilton Group Can Help

Mapped-drive problems can interrupt access to essential documents, applications and shared data.

The visible symptom may be a missing drive letter, but the underlying cause could involve Group Policy, DNS, permissions, VPN timing, Wi-Fi authentication, file-server availability or several competing scripts.

Hamilton Group can help with:

  • Windows 11 mapped-drive problems
  • Group Policy Preferences
  • Logon scripts and PowerShell
  • Active Directory security groups
  • VPN and remote-access timing
  • DNS and SMB troubleshooting
  • File-server and DFS support
  • NAS compatibility
  • Share and NTFS permissions
  • Microsoft Intune scripting
  • OneDrive and SharePoint migrations
  • File-server modernisation
  • Managed IT support

We can identify what is creating—or removing—the mapping, correct the login sequence and build a reliable solution for both office-based and remote users.

Stop Remapping the Same Drive Every Morning

A mapped network drive that disappears at every login is usually not fixed by repeatedly ticking Reconnect at sign-in.

The lasting solution is to ensure that the share is reachable, use one mapping method, create the connection in the correct user context and delay or trigger it when the network or VPN is genuinely available.

For help fixing disappearing mapped drives, Group Policy issues or unreliable file-server access, call Hamilton Group on 0330 043 0069 or book a call with one of our experts today.


 

Previous Next