Mapped drives not seen from elevated Command Prompt and Task Scheduler

When you attempt to access a mapped network drive from an elevated or admin Command Prompt or Task Scheduler (with the highest privileges), the mapped drive won’t be available. Attempting to use the mapped network drives causes the error The system cannot find the path specified (Error code: 0x80070003).

Here are the screenshots from a computer running Windows 10.

mapped network drive not seen from admin command prompt and task scheduler

However, the mapped network drive is accessible from File Explorer and regular (non-elevated) Command Prompt.

There is a registry-based solution that lets you use mapped drives from standard as well as elevated processes.

(Go to the solution directly)

Microsoft articles KB937624 After you turn on UAC, programs may be unable to access some network locations and KB3035277 address this issue.

KB937624 states:

When an administrator logs on to Windows Vista, the Local Security Authority (LSA) creates two access tokens. If LSA is notified that the user is a member of the Administrators group, LSA creates the second logon that has the administrator rights removed (filtered). This filtered access token is used to start the user’s desktop. Applications can use the full administrator access token if the administrator user clicks Allow in a User Account Control dialog box.

If a user is logged on to Windows Vista and if User Account Control is enabled, a program that uses the user’s filtered access token and a program that uses the user’s full administrator access token can run at the same time. Because LSA created the access tokens during two separate logon sessions, the access tokens contain separate logon IDs.

As the drive mappings created from File Explorer are from a standard user token, the drives are not seen from an elevated token (e.g., Administrator Command Prompt or Scheduled Tasks configured to run with the highest privileges.)

Another Microsoft article, KB3035277, titled Mapped drives are not available from an elevated prompt when UAC is configured to “Prompt for credentials”, explains along with a solution that works in Windows Vista through Windows 11.

KB3035277 states:

When UAC is enabled, the system creates two logon sessions at user logon. Both logon sessions are linked to one another. One session represents the user during an elevated session, and the other session where you run under least user rights.

When drive mappings are created, the system creates symbolic link objects (“DosDevices”) that associate the drive letters to the UNC paths. These objects are specific for a logon session and are not shared between logon sessions.

Note The EnableLinkedConnections registry entry forces the symbolic links to be written to both linked logon sessions that are created, when UAC is enabled.

And here is a helpful note from James Finnigan [MSFT].

The “EnableLinkedConnections” policy relies on the user being a member of the Administrators group and sharing across the boundary between non-elevated and elevated (which can lead to intentionally misdirected drive mappings by Malware). It is essentially a workaround for customers that are in the process of moving their users to standard user, but need to do so gradually and keep them as members of the Administrators group in the short-term.

Resolution

As explained earlier, you can fix the problem by creating the EnableLinkedConnections DWORD (32-bit) value in the following registry key and setting its data to 1.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  1. To create/set the registry value, start the Registry Editor (regedit.exe)
  2. Go to the above branch.
  3. From the Edit menu, click New, DWORD (32-bit) Value.
  4. Name the DWORD value EnableLinkedConnections and set its data to 1.
    mapped network drive not seen from admin command prompt and task scheduler - enablelinkedconnections
  5. Exit the Registry Editor and restart Windows.

The EnableLinkedConnections value enables Windows to share network connections between the filtered access token and the full administrator access token for a member of the Administrators group. It would be best if you restarted the computer after creating the registry value.

After restarting Windows, the drives are accessible in regular and elevated processes—i.e., processes running under the filtered access token and the full administrator access token.



mapped network drive not seen from admin command prompt and task scheduler

Using a .REG file

You can automate the above setting by creating a .reg file from the following contents.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001

Task Scheduler still can’t access mapped drives?

If your Scheduled Tasks still fail to access the mapped network drives despite enabling the EnableLinkedConnections registry value, then you’ll need to check two things:

  1. A User Account control-related security policy. (and)
  2. If the scheduled task is configured to run under a different user, you’ll have to map the drive again from that user account. (see Important: note at the end of this article)

If the following UAC Policy setting is configured to Prompt for credentials, the scheduled tasks (running with the highest privileges) fail to access the mapped network drive.

User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode

UAC asks for password even if logged in as an administrator

Using the Security Policy Editor (secpol.msc) or the Registry Editor, you’ll need to set the above policy to Prompt for Content  or Prompt for Content for non-Windows binaries (which is the Windows default setting.)

UAC asks for password even if logged in as an administrator

More instructions to configure the above security policy (along with an alternative registry-based solution) are available in the article UAC asks for a password even if logged in as administrator.

After resetting the above policy, restart Windows. Your mapped drives should be available for scheduled tasks configured to run with the highest privileges.

Important: However, when you’re running the task under a different user account or the SYSTEM (LocalSystem) context, the mapped drives won’t be seen despite the EnableLinkedConnections registry value. This is because the network drive mappings are per-user. That means you’ll need to map the drive again under that specific user account configured to run the scheduled task.

Information in this article applies to Windows Vista through Windows 11.


One small request: If you liked this post, please share this?

One "tiny" share from you would seriously help a lot with the growth of this blog. Some great suggestions:
  • Pin it!
  • Share it to your favorite blog + Facebook, Reddit
  • Tweet it!
So thank you so much for your support. It won't take more than 10 seconds of your time. The share buttons are right below. :)

Ramesh Srinivasan is passionate about Microsoft technologies and he has been a consecutive ten-time recipient of the Microsoft Most Valuable Professional award in the Windows Shell/Desktop Experience category, from 2003 to 2012. He loves to troubleshoot and write about Windows. Ramesh founded Winhelponline.com in 2005.

4 thoughts on “Mapped drives not seen from elevated Command Prompt and Task Scheduler”

  1. Thanks for posting this. I followed a link from this page.

    http://social.technet.microsoft.com/Forums/windows/en-US/4333ae51-2c3d-4cfd-8ab7-df68a3467ee9/mapped-network-drive-letter-not-available-in-command-prompt?forum=itprovistanetworking.

    One of the comments there suggested using “net use”. The KB article you link to has been changed to provide the same solution.

    I know this is an old article but I am still using a Vista machine at home for outside work. I hadn’t run into this issue at work as we turn off UAC through Group Policy and user accounts are restricted. This did provide a resolution I am silling to implement for my own use.

    Reply
  2. Thanks for this. I have a policy against messing with the registry on the platform that we deploy across the state, but it was extremely helpful to quickly get confirmation about the corner into which I have been backed.

    This is Vista and beyond. I particularly like the aspect that connectivity “may” be lost. A guy thinks he has tested and then finds out that yet another Windows behaviour is non-deterministic. In this environment, software correctness is a nonsense term with no formal definition.

    The blog suggests that productivity is a goal. Here’s a suggestion for dramatically improved productivity: don’t use Windows.

    Reply

Leave a Comment