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.
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.
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
- To create/set the registry value, start the Registry Editor (
regedit.exe) - Go to the above branch.
- From the Edit menu, click New, DWORD (32-bit) Value.
- Name the DWORD value
EnableLinkedConnectionsand set its data to1.
- 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.
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:
- A User Account control-related security policy. (and)
- 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
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.)
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!
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.
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.
EnableLinkedConnections is broken for me on Windows 10. Does not work. Can you confirm? 🙁
Mixed reports really: http://superuser.com/questions/1031344/running-programs-as-administrator-from-network-drive-windows-10 Some say it works for them but it doesn’t for me in Windows 10 TH2. Always worked in Vista/7/8.1 after a reboot. Well I’ll try doing a clean install again. This was an installation upgraded in-place from pre-RTM builds.