Run as Admin and Network Drive

I have a Drobo set up as a network drive -via droboshare - everything works fine, however applications (specifically backup software, drobo copy or Bonkey) cannot see the dirve which is mapped to z: when the application are set to run as administrator. Drobocopy requires this so turning it off is not an option. Bonkey doesn't but I am having issues running it and I think turning it on might help. Any ideas? I have tried turning off my firewall but that hasn't helped.

Short version: network drive definitions exist only for the user who mapped them. If userX defines a "Z:" network drive mapping, userY will be unable to access it (they won't even see a "Z:") unless they too map the drive under their own account.


======================================================
Detail: for security reasons, network drive mappings in XP and later versions of Windows are user-specific. Administrative group membership has nothing to do with it. Each user sees the "global" drive definitions which correspond to local devices (A:, C:, D:, ... whatever), plus those network drive definitions which they themselves created.

On a code level, the identity of the user account which calls the drive-mapping DefineDosDevice API determines who gets to "see" the mapping. If the account is anybody other than SYSTEM, the mapping will be placed into a session-specific namespace which is invisible to other sessions/accounts.

In situations where you want all users to see a particular network drive, the obvious workaround is to call DefineDosDevice() in the SYSTEM context. That will lead to the definition being placed in the global namespace where it will be available to all users, just like A:, C:, ...

One way to run code as system is to use the PsExec utility from sysinternals with its "-s" command line option. Start a CMD prompt in an elevated context (run as admin), and use that to issue something like the following command:

PSEXEC -S -I CMD.EXE

That will start a second CMD instance which will run in the SYSTEM context. If you map the Z: drive from there, it'll subsequently be visible to all users:

NET USE Z: \\TargetName\TargetShare

Because child processes inherit the access token of their parent, in this instance NET.EXE will also run in the SYSTEM context. You could also specify the "net use" comand-line argument to PsExec, but it's not as obvious what's happening, expecially while you're tinkering with this stuff the first few times.

There's also a registry value that tells Windows to link the drive mappings for elevated and non-elevated processes within the same user account:

Windows Vista UAC Tip - Drives not mapped for admin token - Windows Connected
After you turn on User Account Control in Windows Vista, programs may be unable to access some network locations

Both articles are about Windows Vista, but I have verified that the same tweak works in Windows 7.