Mapped drives not seen from elevated Command Prompt and Task Scheduler

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

Here are the screenshots from a computer running Windows 10 version 1903.

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.

Various forums suggest that people use UNC paths (as a workaround) instead of mapped drive letters when in elevated Command Prompt mode or running batch files with Task Scheduler. Also, they advise users to disable Run with highest privileges for that specific scheduled task job to be able to use the mapped network drive.

However, those workarounds are not necessary as there is a permanent registry-based solution that lets you use mapped drives from standard as well as elevated processes.

(Go to the solution directly)

Microsoft Knowledgebase article KB937624 After you turn on UAC, programs may be unable to access some network locations addresses this issue. But the real fix is given in KB3035277 (also mentioned below) instead.

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 highest privileges.)

Another Microsoft article KB3035277 titled Mapped drives are not available from an elevated prompt when UAC is configured to “Prompt for credentials” offers an explanation along with a solution that works in Windows Vista through Windows 10 (tested on v1903)

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 useful 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.

Fix: Mapped drives not seen from Admin Command Prompt and Task Scheduler

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

  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 as 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. As said earlier, you must restart the computer after creating the registry value.

After restarting Windows, the drives are accessible in regular as well as elevated processes — i.e., processes running under filtered access token as well as 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


Task Scheduler still can’t access mapped drives?

If your Scheduled Tasks still fail to access the mapped network drives despite enabling EnableLinkedConnections registry setting, 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 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 (which is the Windows-default setting)

UAC asks for password even if logged in as an administrator

Full 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 highest privileges.

Important: However, when you’re running the task under a different user account or under 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 which is configured to run the scheduled task.

Information in this article applies to Windows Vista through Windows 10. The solutions have been last tested in Windows 10 v1903.

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 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.

    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.

  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.


Leave a Comment