Share via

User getting old network drive mapping, but I can't figure out where it's coming from.

Joe Grover 631 Reputation points
2025-09-02T20:09:39.5366667+00:00

We have a Windows Server 2022 AD environment and have user accounts with login scripts defined on the Profile tab of the AD object. These logon scripts contain non-persistent drive mappings. Clients are Windows 11 24H2.

A couple of weeks ago we removed a drive mapping from a resource that we've migrated to SharePoint online. Despite this we have one user that continues to get the old drive letter mapped on login.

This is the order of operations of what we did:

  • At EOB on Friday 8/22 we set the share-level permissions on the on-prem fileshare to Read Only.
  • After this, we removed the drive letter mapping F: from pointing to the on-prem fileshare from all login scripts. One of the scripts in particular (the one used by this affected user) we'll call old-script.bat.
  • We created a new login script (new-script.bat) and assigned it to a specific subset of users (one of which is the affected user). This script also does not have any F: drive mapping at all.
  • Last week (Friday 8/29) this user indicated issues saving to his F: drive. Looking at the screenshot he'd provided, the F: drive mapping was to the on-prem fileshare, and his error was predictably that he did not have permissions to do so.
  • I confirmed his AD object is set to use new-script.bat, and that the script did not include a drive mapping for F. I confirmed this on all domain controllers in all sites (in the event there was some kind of replication issue), starting with the server that showed as being his logon server (determined via echo %logonserver%).
  • I'd confirmed that it wasn't an issue of just having a user session that had been logged in since before the changes, as his computer had been rebooted shortly before he put in the ticket. I also had signed him out and back in multiple times (after disconnecting the drive in File Explorer, using net use f: /d from the command prompt, etc), with the old drive mapping coming back each time.
  • I checked the startup folder in his user profile, as well as scheduled tasks, the Startup Apps tab in Task Manager, and HKCU\Network to see if there were any scripts or entries that would be mapping the drive and did not see anything.
  • I checked to see if a Group Policy had been set up and applied to this machine but didn't find anything.
  • No other users are affected by this problem (including the other 20+ users set to use the same login script).

I'm at a loss for what else to look at. I see his current user session started this morning. Checking in with him I confirmed that the F: drive mapping was back again. I still need to have him try logging into a different machine, which I hope to do tomorrow when he's back in the office.

Where else should I be looking?

Windows for business | Windows Server | Directory services | User logon and profiles
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Harry Phan 10,535 Reputation points Independent Advisor
    2025-09-02T20:59:58.5933333+00:00

    Dear Joe Grover,

    Based on your description, you've already ruled out most common causes—including login script replication, Group Policy, startup tasks, and registry entries. Given that the F: drive mapping continues to reappear even after manual disconnection and reboot, we recommend investigating the following additional areas:

    Roaming Profile or Cached Credentials If the user has a roaming profile or previously cached credentials, remnants of the old mapping may be reapplying during session initialization. Try logging the user into a clean test machine to confirm whether the issue is profile-specific.

    Mapped Drive Persistence via Credential Manager Check Control Panel > Credential Manager for any saved network credentials that may be triggering automatic reconnection to the legacy share.

    Logon Script Execution via Alternate Mechanism Use gpresult /h result.html or rsop.msc to confirm that no other Group Policy Object is applying a drive mapping outside of the expected login script.

    Registry Tattooing Occasionally, drive mappings can be "tattooed" into the registry. Inspect HKCU\Network\F and HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters for any residual entries.

    DFS Namespace or Alias Mapping If the original share was part of a DFS namespace or alias, the mapping may be resolving through an alternate path. Confirm that no DFS links are redirecting the F: drive.

    We also recommend temporarily assigning the user a blank login script and monitoring behavior across multiple machines. If the issue persists only on one device, a local profile reset may be necessary.

    You can find a similar case and community discussion on Microsoft Q&A, which may offer additional insights.

    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    Best regards,

    Harry Phan

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.