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 ...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
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:
