In Windows Vista, drive mappings not preserved across admin, regular-user apps

Admins will often create a drive mapping to a deeply-nested directory in current use through the SUBST command. In Vista, when the user tries to elevate privileges on a process and then access the material in the folder through the share, they can't. It's not a bug. Here's why.

In Vista, even an administrative user is forced to run everything as a regular user by default. They have to manually...

elevate privileges if they want something to run as administrator.

This is just one of the many unexpected real-world consequences of Vista's finer-grained handling of security and permissions, which admins are discovering as they work with Vista day to day.

Being forced to run everything as a regular user by default isn't so bad for the most part. But it can have some unexpected consequences that might be misinterpreted as a bug.

One such behavior is the way Vista handles drive mappings through the SUBST command. A common productivity trick is to create a drive mapping to a deeply-nested directory that happens to be in current use; this is typically done through the SUBST command, as run in a logon script or some other automatic mechanism.

But when the user tries to elevate privileges on a process and then access the material in the folder through the share, they discover they can't. Here's the reason for this.

Creating drive mappings with SUBST

When you create a drive mapping with SUBST, that mapping takes place in the context of the user account used to run the command. 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. This cuts both ways: If you create a drive mapping in the admin context and try to access it as a regular user, you can't. If you're running Vista, experiment with this yourself and see the results.

As tempting as it is to call this a bug, it's not, and it shouldn't be regarded as one. Vista is simply honoring the fact that drive mappings created in one user account are not typically accessed in another. If you rely on drive mappings in both the regular and elevated security contexts, you may need to run your drive-mapping scripts twice—once in a regular-user context and again in an elevated context—as a workaround.

Note: I'm researching possibly more elegant solutions to the problem. Stay tuned.

About the author: Serdar Yegulalp is editor of the Windows Insight, (formerly the Windows Power Users Newsletter), a blog site devoted to hints, tips, tricks and news for users and administrators of Windows NT, Windows 2000, Windows XP, Windows Server 2003 and Vista. He has more than 12 years of Windows experience under his belt, and contributes regularly to and

More information on this topic:

This was first published in March 2007

Dig Deeper



Find more PRO+ content and other member only offers, here.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:









  • Virtual desktop security guide

    To secure virtual desktops, consider antivirus, certificates and network vulnerabilities. Just remember, VDI doesn't always ...

  • Guide to low-cost desktop virtualization

    In this guide, learn to virtualize desktops without spending more than you would when deploying PCs, and what VDI vendors are ...

  • VDI pilot project guide

    A VDI pilot project should start with a VDI project plan. Know what pitfalls to avoid and test product options to achieve a ...