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?
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.
You can enable that also mapped drives are visible to the administrator by a registry entry:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System
create DWORD EnableLinkedConnections with value 1
as described here:
http://www.winability.com/how-to-make-elevated-programs-recognize-network-drives/
This worked for me on Win 10.
