Mapped Network Drives with UAC on Windows Vista

User Account Control on Windows Vista provides a convenience feature which allows you to elevate a process without leaving the current desktop. (For a discussion of why this is a convenience feature, rather than a security feature, see Mark Russinovich's blog entry here:

Let's explore this at a fairly high level. To simplify things, let's assume you are running as an administrator with UAC enabled (although, to be more secure, it is better to run as a standard user). When you log in, you create a new token. We then detect that you have UAC enabled, we log in a second time, and end up with a new (highly restricted) token, which we use to launch the shell. There are two separate login events. When you are prompted to elevate, you go through consent.exe, which is able to leverage the Application Information service to essentially call CreateProcessAsUser with the fully-charged admin token. Remember - we are calling CreateProcessAsUser with a token generated with a separate login.

This convenience feature makes it easier to run into issues with mapped network drives. Prior to Windows 2000 SP2, device names remained globally visible until explicitly removed or the system restarted. For security reasons, we modified this behavior beginning with Windows 2000 SP2. From this point forward, all devices are associated with an authentication ID (LUID) - an ID generated for each logon session. (A process running in LocalSystem context can create a device name in the Global device namespace, although local namespace objects can hide global namespace objects.)

Because these mapped drives are associated with LUID, and because elevated applications are using a different LUID generated during a separate login event, the elevated application will no longer see any mapped drives for this user. (You will notice the same behavior previously using RunAs or CreateProcessAsUser, but UAC dramatically increases the number of users who will be using these concepts.)

The result? If you elevate a command prompt, you will no longer see any local namespace mapped drives created from your original login (whether created through a logon script, WNetAddConnection, or otherwise). We do put a mitigation in place for the scenario of launching from the shell. If you double click on an executable that is either detected as a setup or is manifested as requireAdministrator, we can detect that we just elevated and suddenly are getting an error message indicating that the path was not found, and copy that drive mapping over from the original LUID. However, that is the only scenario that we can automate.

So, if you need to leverage mapped drives from an elevated process, you should be certain to map these drives in the contect of the elevated login.

Comments (25)

  1. Josh says:

    you can set this value and you will get access to those drives from both integrity levels.

    UAC team is working on a KB, and I will have a post on this before too long.

  2. Last time around, we looked at an application compatibility side-effect of User Account Control on Windows

  3. Jason says:

    So how does MS expect us to change our logon scripts to work by mapping network drives?  Shouldn’t there be some documentation on how to do this appropriately.  I did try the Launchapp.wsf on the TechNet article but errors out with a syntax error just launching the script.  I have tried the registry key EnableLinkedConnections and it works.  However you can’t make a startup script edit the registry to deploy such a change.  It seems this is a catch 22 situation.  Does anybody else know how to make this work?

  4. jc2871 says:

    I cannot get the EnableLinkedConnections to work.  Anyone else successful?

  5. ReggieB says:

    I have a variation on this behaviour. If the user is a standard user the log on script works fine and maps the drives. However, if I add the user to the local admin group the mappings fail to appear.

  6. Ed says:

    You must reboot after you set the new DWORD.

  7. Alisa says:

    I map network drive in elevated contect, however, if after this I start a DOS window also in elevated contect, I CANNOT see any of the mapped drives.

    However, if I start DOS windows in non-elevated mode, it’s ok.

    Why is this so inconsistent?

  8. cjacks says:

    Mapped drives are associated with a logon session, as mentioned before. It’s not just elevated or non-elevated, but each time you log in. We just happen to have two different logon events when creating the split token we use in Vista.

    If you’re seeing the drives in a non-elevated command shell (DOS is long gone, but I know what you mean), then the mapped drives must have been created from that logon session, and not from the session from which your elevated token came. How are you mapping these drives, and from what application?

  9. says:

    I have also been unsuccessful with utilizing the EnableLinkedConnections = 1 registry fix.  I have rebooted as well.  It just doesn’t work for me.

    On a side note, before applying this fix, if I opened a command prompt under the limited token, my drives show (net use) and are available.  If I opened an elevated command prompt, the drives are listed, however they are all marked "unavailable", thus inaccessible as well.  This functionality existed before and after the registry fix above.

    Any thoughts on how to get this to work?!

  10. cjacks says:

    The registry key is not supported. I’d re-run the script to map your drives after you elevate, or else use UNC paths instead of mapped drives.

  11. steve.darnall says:

    In ref. to

    If the user is NOT an administrator on the Vista computer to which they are logging, the standard drive mapping script (XP) works; but the launchapp approach does not.

    If they ARE an administrator, then the standard mapping script fails; but the launchapp approach works.


  12. Praveen says:

    I guess we are seeing similar issue when we execute our setup program from a network mapped drive in explorer but don’t see that drive in our setup program (InstallShield 12). Any solution or workaround for us to try out?

  13. cjacks says:

    We should be catching and detecting the launch of the setup program and then mapping that over so you can execute after you elevate. What exactly are you doing in the setup that isn’t seeing this? I’m not familiar with all of the versions of InstallShield out there. Are you creating an MSI? Is this a custom action? How are you retrieving the mapped drive? What are you then trying to do with it?

  14. Tom says:


    We’re porting a legacy app that uses Wise Install System.

    Our app uses mapped drives; it can’t use UNC.

    I, too, am having trouble getting mapped drives to be visible to the Wise Installer.  Whether (as we prefer so we avoid your scanning a 100mb file) I use a tiny Setup.exe stub marked as RequiresAdmin which simply shells to the Wise-created .exe, or just run the Wise .exe standalone, no mapped drives are seen by the installer.

    As a developer, I’m running as an admin. I believe that EnableLinkedConnections is necessary for me to see the mapped drives. But as a standard user, I’ve yet to be able to see them from the elevated Wise installer, even if it’s launched from the Explorer.

    In the past we’ve had users map drives in the Windows Explorer and then run our installer and then our app. But it appears that there are additional steps required here?

    I’m not sure what steps are required, or how to make them straight-forward for our end-users.

    Any help?


    Tom (across Lake Washington in Seattle)

  15. cjacks says:

    Hi Tom,

    If you have a setup.exe stub, why not just map the drives in the elevated login session from the stub before launching the installer?



  16. tfield98 says:

    Hi, Chris,

    Thanks for the suggestion.  

    My stub is running elevated to admin. Are you suggesting that somehow it can detect what drives the standard user had mapped, and then do the mapping again?

    Or do I need two stubs: the first runs **without** elevation, a makes a list (say, to the registry) of the mapped drives, then shells out to stub #2, which asks for elevation to admin, reads the registry list and re-maps the drives.   Sounds kinda Rube Goldberg-like to me!

    I’m not familiar with what API functions are available for reading and creating mapping. Can you point me in the right direction? (I’m in Delphi…)

    I REALLY appreciate your help on this.

  17. cjacks says:

    Hi tfield98 (Tom?),

    No, I wouldn’t go about trying to figure out what you have from non-elevated and then marshall that data across and re-create them elevated. Too much work. 🙂 The drives are being mapped in the non-elevated context somehow. Just find that source, and run it again – only elevated.

    To answer the API question, WNetAddConnection3 can be used to create mapped network drives.



  18. tfield98 says:

    Hi, Chris,

    I’ve got the code working now. It was a combination of using EnableLinkedConnections and making sure that drives mapped as a standard user were also mapped when elevated to an admin user.

    I REALLY appreciate your having taken the time.

    Thanks again!!!!

    Tom (tfield98!)

  19. Mike Wilson says:

    I have a .wsf file on a server.  It is called from an HTA also on the same server.  The user logs in as their username not administrator.  Each user also has local admin privileges. The .hta runs fine but I get a permission denied error when I try to run the .wsf file.  All works fine in XP.  Problems occur using Vista.  Is this related to the discussion here?

  20. IJ says:

    So, if you need to leverage mapped drives from an elevated process, you should be certain to map these drives in the contect of the elevated login.

    But when the machine is restarted, the mapped network drive lost the elevated token, I mean, the drive which was mapped in the context of the elevated login, after reboot a elevated process can not see it, for example a setup.exe (which require an Admin token). or am I doing something wrong?

  21. IJ says:

    By the way, can I do this (modify the Windows Registry)


    EnableLinkedConnections =(dword)1

    without lost the Vista logo?

  22. cjacks says:

    Mike Wilson – that sounds like UAC, scripts can’t be set up to elevate. You may want to check this out:

    IJ – I’m not a logo expert. You should try not to depend on this. You should prefer UNC to mapped drives, however, anyplace you can.

  23. Mike says:

    I know this post is about Vista, but some of the side comments lead me to believe you might have an answer to this question.

    On Windows XP I’m using LogonUser, LoadUserProfile, ImpersonateLoggedOnUser, then finally CreateProcessAsUser to have a process running as a service start user applications running in console mode. They appear to run correctly under the logged on username, but the user’s mapped network drives all appear as unavailable (for example, start a .BAT file that has a "net use" command, and the output shows the mapped drive letters and paths but all have a status of "Unavailable").

    Is this a known limitation, or should there be a way for me to get around this and use the user’s mapped drive letters?


  24. cjacks says:


    You’re facing the same issue on XP that I’m describing on Windows Vista. The call to LogonUser creates a new logon session. Mapped drives are stored with each logon session, so you don’t have them. What you want to do is re-use the same logon session. Both COM and scheduled tasks allow you to use the credentials of the interactive user, so I’d probably explore these options.



Skip to main content