In my computer, I'm used to have a drive created with the SUBST command to map to a local folder deeply nested in my directory structure. I map it on each login for my user only by placing a bat file with the command in the startup menu. Problem is that when I need to elevate a program on that "drive" (or a program that uses it), it simply doesn't sees it. After the user/password of UAC, the program works normally, but only shows the C and D drives. I'm currently using a standard account and UAC ask me for credentials of an admin user. I've already tried the workaround proposed here: http://support.microsoft.com/kb/937624/en-us, but with no luck. Any ideas of a workaround for this annoying bug?

Hi, Based on my research, Im afraid that the only workaround is to run the batch file twice, once for normal privilege and the other for administrative privilege. You can also refer to the similar thread: Problem with 'subst'. Bug or Feature? Hope this helps. Jeremy Wu TechNet Community Support

Hello Jeremy and thanks for the help. But really hasn't solved my problem. I knew that trick and know it works, but it only do so when the affected user is a local administrator (for those who UAC gives a simple yes/no "admin approval mode" elevation). I run automatically once as limited user and then again elevating it and it goes well until I logoff, not ideal but quite usable. In my case, I'm running as a real standard user, not being a member of the local administrators group (for who UAC asks for a full user/password in "over the shoulder" elevation). There, that trick doesn't works. In fact, it only maps the drive for that command window, but for nothing else. Even if I open two elevated cmd's and subst in one, the other don't see it, so the bug essentially remains when I try to elevate anything else on the drive or use any files. Any ideas for getting that running for standard users? Thanks! EDIT: Forgot something. I found an ugly way to solve it, and it's running the subst under the SYSTEM account (not any administrator, but system itself). All users get to see the drive there until next reboot (which I don't like too) and it's not trivial to elevate a command prompt to SYSTEM access, so I keep it at a last resort.

Hi, Would you mind to provide me the detailed steps about how to reproduce the issue? I cannot reproduce the issue on my test machine. Thanks, Spencer Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hello Spencer Here are what I've done to reach at the error: 1) Create 2 accounts in the system, one belonging to the "administrators" group and other that doesn't (and is member of "users" only). 2) UAC is set to the highest level in control panel. 3) Login with the non-admin account. 4) Create a substed drive from a local folder. For example: SUBST g: c:\windows (any path will do here really) 5) I try to "Run as administrator" any executable file located in the substed drive (given my previous step, I might attempt to run notepad.exe elevated for instance). 6) UAC shows it's OTS dialog asking for a user/password with administrators group membership. I provide the credentials for the admin user previously created. 7) Here's the bug: instead of the program appearing and running normally, an error message (generated from Windows itself) says that the executable I just right clicked does not exists. 8) A variation: if instead of running an exe in the substed drive I run an exe in C: directly, it elevates correctly, but instead it hasn't the substed drive at all, for example it does not appears in the open/save common dialogs (while if I run non-elevated, it does appear in such dialogs). I would greatly appreciate any help! Thanks.

Thanks Alejandro, I am doing test for the issue. Will reply you as soon as possible. :) Thanks, SpencerPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

With the SUBST command, I dont think you will be able to accomplish what you are looking to do; drive mappings are user based and dont covey when you change users as in the case of UAC elevation. Another method you can use is symbolic links (directory junctions) using he mklink command. When a directory junction is created by an admin, it will persist between users and survive UAC elevations.

Hi Alejandro, Yes I was able to reproduce the issue now. After performing research, this issue seems by design. Just as DarienHawk67 mentioned, the cause is that the subst is user based. When you create a drive mapping with SUBST, that mapping takes place in the context of the user account used to run the cmd. If you create a drive mapping as a regular user and try to access it with elevated privileges, the elevated-privilege process won't "see" the drive mapping. It can't, because the drive mapping has been done under a completely separate user account. As a workaround, you may try to run the subst command in the normal user context and the elevated user context. Or you may consider to use mklink as DarienHawk67 suggested. For the detailed information, you can refer to the following article: Mklink http://technet.microsoft.com/en-us/library/cc753194(v=WS.10).aspx Thanks, SpencerPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Alejandro, Any update? Thanks, SpencerPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Spencer. Sorry for my late response, I've been a little (lot?) busy these days :P Thanks for the response. I knew a little about that of being "user based" and I'm using that to map the drive only for my user but not to anyone else login in with another account, but guessed that it should work here since the new user is being spawned by the UAC elevation prompt in any case (and it does not in fact). I can't think that this was done so "by design" in this particular case. I agree with the workaround, running the mapping under the elevated account seems to solve it at a first glance, but I can't think of any way of actually doing so in practice. I don't know if even there is a way of running another command before the elevated program launches. For now, I'm doing that by opening an elevated command prompt, mapping there, and using it to launch the real app I want, instead of a simple double-click I want, but it's annoying doing that every time. The mlink thing don't seems to be so good, since it will be exposed to all users and also there are a few problems using it in Windows yet (totally unrelated: I've once accidentally deleted a couple of files when trying to delete a link that pointed there, so I'm not so happy placing them again :D). After that, I decided subst was a good way, but crashed with this problem. Thanks for the help anyway, I will look into trying to run the subst in the elevated context somehow, if that's even possible.

Hi Alejandro, that's OK. :) BR, SpencerPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.