Mapped drives are not seen from elevated Command Prompt in Vista


When I tried to access a network drive via elevated Command Prompt, the drive was not found and I got the error The system cannot find the path specified. However, the drive-letter is listed in (My) Computer and accessible from non-elevated Command Prompt.

Fig 1: Mapped drive not seen from Elevated Command Prompt.

Fig 2: Mapped drive accessible from a standard Command Prompt.

Upon searching the net, I found a Microsoft Knowledgebase article After you turn on User Account Control in Windows Vista, programs may be unable to access some network locations which address the problem. Here is an excerpt from that article that explains everything:

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 I created the drive mappings from a standard user token earlier, the drives are not seen from an elevated token (For example, when using an admin Command Prompt.)

The problem was solved after I created the EnableLinkedConnections DWORD value in this registry key and set its Value data to 1:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Policies \ System

The EnableLinkedConnections value enables Windows Vista to share network connections between the filtered access token and the full administrator access token for a member of the Administrators group.

You must restart the computer after creating the registry value.

Fig 3: Mapped drive seen from both standard and elevated Command Prompt Windows.

Registry fix

To automate the above setting, dowload, unzip and extract the contents to a folder. Double-click enablelinkedconnections.reg to run it. To reverse the changes use the undo.reg file.

And here is a useful note from James Finnigan [MSFT] posted at the MS Newsgroup.

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.


Mapped drives created from an elevated access token will not be visible from processes running in limited user token. If you use Group Policy to create mapped drives, it uses the elevated access token. As a result, your user account (runs with the limited user token by default) won’t see the mapped drives. For more details and a workaround see: Group Policy Scripts can fail due to User Account Control. The script launchapp.wsf helps you create mapped drives under limited user token via Group Policy.


About the author

Ramesh Srinivasan founded back in 2005. He is passionate about Microsoft technologies and has a vast experience in the ITeS industry — delivering support for Microsoft's consumer products. He has been a Microsoft MVP [2003 to 2012] who contributes to various Windows support forums.

5 thoughts on “Mapped drives are not seen from elevated Command Prompt in Vista”

  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