Why You Sometimes Map a Drive in Windows 7... But Then Can't See It

I've gotten this question literally three times in the past month, so it must be time to put it in a newsletter.

Here's the scenario.  It will appear on any Vista, Server 2008, Windows 7 or Server 2008 R2 system with User Account Control enabled.  (Remember UAC's on by default.)  You've opened an elevated command prompt -- one wherein you didn't just double-click the "Command Prompt" icon, you right-clicked the icon and chose "Run as administrator" -- and you map a drive with the NET USE command, mapping it to, say, drive G:.  Then you pop out to Explorer... and whaddya know, no drive G:!  Maybe an F5 to refresh will... no, no change.  Perhaps a reboot, assuming you mapped it persistently?  No on that score either.

What's going on here?  Well, as you know if you've read my Vista security book or heard me talk about User Account Control, then you'll know that when you log onto your system, UAC causes Windows to create not one but two security tokens.  One of those tokens contains all of your privileges and group memberships (the "administrative token"), and Windows builds the other -- the "standard user token" -- by copying your administrative token and then removing from that token any of four particular powerful group memberships and removing any of nine particularly powerful privileges that appear in the administrative token.

But there's more to it than simply having two tokens.  Two tokens, you see, mean two logon sessions... and those sessions don't really talk all that much.  Thus, drives that you've mapped from the "high power session" (the one with the administrative token) aren't visible in the "low power session," the one with the standard user token.  It's also true the other way around, although folks don't seem to run into it much -- map a token from the lower power token and it's invisible to sessions for the high power token.  To see this, try this simple test, which requires a Vista or Windows 7 system and a server with more than one share.

Let's call the file server \\server1 and let's say that you've got shares named \\server1\share1 and \\server1\share2.  Let's also say that you have the right to access these shares because you're a member of some group other than the four that UAC would yank out of your token -- Power Users, Administrators, Backup Operators or Network Configuration Operators.  Log on and do the following.

  1. Open an elevated command prompt window.
  2. In that window, type net use t: \\server1\share1 and press Enter.
  3. Open a second command prompt window, but this time, don't elevate the command prompt, just double-click on the icon.  You'll have two separate command prompt windows open now, and the elevated one will have "Administrator:" in its title.
  4. In the second, non-elevated command prompt window, type net use v: \\server1\share2 and press Enter.
  5. Next, while still in the non-elevated command prompt window, type net use and press Enter.  You will see V: listed but you will not see T: listed.
  6. Finally, pop back over to the elevated command prompt window and, again, type net use and press Enter.  This time, you'll see T: listed but not V:.

Again, this has nothing to do with any kind of refreshing.  If you like, close both command prompt windows, open two new ones up in the same way and do the "net use" command in each, and you'll still see only T: in the elevated window and V: in the non-elevated one.

So what's the fix?  As KB 937624 explains, you can hack the Registry with a "EnableLinkedConnections" setting:

  1. In Regedit, navigate to HKLM\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\ System
  2. Create a new entry named "EnableLinkedConnections" of type REG_DWORD.
  3. Set its value to 1.

Reboot and you'll see the change take effect.  I hope this helps someone!