Mapped drives are not available in Windows Explorer

Drive mapping and the local administrator group.
Or: What do you have to do that mapped drives are available (if you are an admin)?

Besides them being integrated into the logon script, the drives are not visible.

The reason is the different treatment of “standard” and “privileged” context.

Recently, I had to create a login script for a customer. During that task, I faced a well-known fact which I want to explain in this article: mapped drives are not visible in the Explorer, even though they have been integrated correctly.

At first, I’d like to explain the circumstances in which I bumped into the problem. After that, I am going to explain the technical background and the solution.

Drive mapping in a login script

Let’s take a look at the login script:

<login-script.ps1>

This command causes a connection to the share „share“ and the subfolder „folder“ on the server „server“ with the drive letter „X:“.

Please pay attention to the parameter “/persistent:no”: it validates connections only during one session. The validation will be lost after the user logs off. In case the user logs off and then in again without a network connection (or without the login script), the drive is no longer connected.

Without the parameter “/persistent:no” the connection would be there even without network connection / login script after the next login.
For this reason, it is common practice to set “/persistent:no” for drive connections.

Usually this is not a problem, but in my case the script seemed not to work for some users. After a quick analysis I realized that these users were in the local administrator group on their PCs.

Note: It is generally not recommended to make your users local admins.  

Background: standard and privileged context

Since Windows Vista, Microsoft offers the User Account Control (UAC). The UAC does the following:
When a user who is a local administrator logs in to his or her PC, two contexts are created:

• A “standard” context and
• a “privileged” context

Most of the time, the user works in the standard context. As soon as he or she wants to use his or her administrative privileges, the system prompts him or her to confirm it:

Here the application (here: the command line cmd.exe) has been started in the privileged context.

Another specialty is that login scripts are always run in the “admin“ context in case the user is member of the local administrator group.  

View members of local administrator group

You can view all members of the local administrator group by starting “Local User Manager”.
The easiest way to do that is typing in “lusrmgr.msc” into the Start menu:

Windows 7 Lusrmgr.exe – (Use the Modern-UI in Windows 8.x to run it)

In our case, the application is “net use”.
With other words: the drive mapping is run in the “Admin” context.

Due to security reasons, the two contexts do not share all available information. Besides other things, drive mappings are not shared between “Admin” and “User” contexts.

Analysis

We can easily reproduce and prove this behavior.

First, let’s take a look at our local administrator group:

As we can see, user SANCTUARY\tuser1 is a member of the local admin group. We are going to use him for our tests.

Open the command line (cmd) and run the command from our login script with true data:

Checking our explorer, we can see that the drive has been connected successfully:

When we now run a cmd as administrator and try to access our newly connected drive, there seems to be a problem:

Note: With the command “whoami” you can quickly see on Windows 7 and newer PCs which user is logged in and which domain he is authenticated against!

With “net use” we can have mapped drives displayed in the two command lines and compare them:

Below is the “privileged” DOS-box and above the „standard” one.

As we can see, the drive connection is only active in the “standard” context.

For our login script this effect happens exactly vice versa. The login script is executed in the “Admin” context. That’s why “net use” runs in the “privileged” context and the connection can only be seen there.

Solution: How to make mapped drives visible

The solution is really simple and supported by Microsoft (Technet).

Via the Registry-Key

HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections
 

you can force the automatic “copying” of drive connections created in either one of the contexts into the other.
Expressed differently: drive mappings are then automatically available in the “Admin” as well as in the “User” context.

The key is not available by default and has to be created as REG_DWORD and set to the value “1”.

The whole thing looks like this:

Alternatively you can change the /persistent:no into a /persistent:yes. This causes the drive connections to be displayed in the “User” context as well. With the side effect of being valid until manual disconnection, however.

Note: The error “0x8007003” (“The system cannot find the path specified.”) during the installation of a network drive, it has most likely the same reason. When starting the installation program, the user is prompted to change into the “privileged” context (UAC). The system, however, “forgets” the drive connection to the installation file. Error 0x8007003 can thus be solved with Registry Key EnableLinkedConnections as well!