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.
