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

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

Requires Free Membership to View

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 SearchWinComputing.com and SearchSQLServer.com.

More information on this topic:

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.