DriveInfo.GetDrives() not returning mapped drives when run as administrator

Question

I'm creating a WPF app that among other things should check for the existence of several mapped drives. The code is straightforward:

DriveInfo[] systemDrives = DriveInfo.GetDrives();
foreach (DriveInfo i in systemDrives)
{
     if ((i.Name.Contains("V")) && (i.IsReady))
     {
          result = true;
          break;
     }

 }

The mapped drives are mapped fro all users. The code above works fine when run as a regular user, however is Visual Studio 2010 is run as administrator the GetDrives method only returns the Fixed drives and the DVD drive but not the mapped drives. The same happens if the executable is run as an administrator. Any ideas why this might be happening?

Answer 1

From http://www.vistaheads.com/forums/microsoft-public-windows-vista-general/125180-run-administrator-loses-access-mapped-drives.html,

(via http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/31c9eff2-ece3-4430-886d-19b54796e411/):

This is actually normal behaviour. As you saw on XP, drive mappings are specific to a user context. So if User1 has a drive H: mapped to \server\share1, User2 does not automatically get any access to this H: drive mapping; it only exists in User1's session. If User2 wants to access \server\share1, they need to create their own mapping, either H: drive or any other drive which suits.

Well, it is kind of the same in Vista .... only moreso.

Unlike previous versions of Windows, when an administrator logs on to a computer running Windows Vista, the user's full administrator access token is split into two access tokens: a full administrator access token and a standard user access token. During the logon process, authorization and access control components that identify an administrator are removed, resulting in a standard user access token. The standard user access token is then used to start the desktop, the Explorer.exe process. Because all applications inherit their access control data from the initial launch of the desktop, they all run as a standard user as well. After an administrator logs on, the full administrator access token is not invoked until the user attempts to perform an administrative task.

So, when an administrator "elevates" to perform some kind of action which requires administrative access, their "split token" is replaced, temporarily, with a a full administrative token. In effect, this means they now have a different user context. So the drive mappings are changed, as well. So the H: drive, no longer has a valid mapping in the current context.

The workaround I have used is to open an administrative command prompt - where you have an elevated token all the time - and create a matching drive mapping from there (net use h: \server\share1). Since the standard user and the elevated administrator have a common understanding of what "H:" drive means, everything runs okay.

I understand (well, sort of!) why this design is in place. I won't attempt to criticize or defend it. But, there you have it.

In an ideal world, administrators would have been able to configure "global" mappings, which automatically applied to every user context on the machine (almost like real devices). But, that didn't happen. Most operating systems have a mish-mash of untidy compromises, in varying degree.