Vista - Run As Administrator loses access to mapped drives

When I run an install as Administrator, per UAC, most installers complain
about not having an H drive (H:\ invalid). I've narrowed this down to the
fact that my "My Documents" is redirected to my H drive, but for some reason
when running anything elevated, those apps lose access to any/all drive
mappings that is currently mapped.

I've found that if I run a Command Prompt elevated and run the "net use"
command, it lists all of my drive mappings but they all list as
"unavailable". If I manually map the H drive in this elevated command
prompt, and then start the install that previously failed, everything works
as intended.

Why does running elevated lose access to all mapped drives? I've seen
theories that when you run as administrator, you're running as a different
user account and it doesn't have access to the drives mapped under the normal
user context. I see this as a false claim. Running as Administrator in
VISTA does not change what user you run as. It just authorizes the app to
have administrative access to the system.

To test what I just said, I ran my elevated command prompt and issued the
command "echo %username%". It returns my normal user account. Echo
%userprofile% returns the profile directory of the normal user account. 'Net
Use' displays all of my drives, but they are just "unavailable" until I map
them *again*.

Obviously I'm running under the same user context regardless if I'm running
elevated or not. To further show this, I opened task manager and turned on
the Session ID column to note which session ID was running my elevated
command prompt. It was the same session as any app running under normal user
context.

I understand in XP when running as a different user, these issues would
exist because obviously I am telling the app to run as a completely different
user, in which case that user's profile is loaded and also has no knowledge
of the user context that initiated the run as command.

I don't understand why Vista has this problem because I'm running as the
same user. I'm just elevating the app under the same user context.

Can someone explain to me why this happens, and if there is a proper
solution? I'm getting tired of trying to install applications, that by
default prompt for elevation, per rules in VISTA, but then failing because it
cannot access my "my documents" folder due to inability to see my
redirected/mapped drive. Having to load up elevated command prompts, running
a script to map my drive, and then kicking off the install is a bit tedious
and asinine.

Please help!

"Matthew" <Matthew@xxxxxx> wrote...Hi Matthew

This is actually normal behaviour. As you saw on XP, drive mappings are
specific to a user context. So if User1 has a drive H: mapped to
\\server\share1, User2 does not automatically get any access to this H:
drive mapping; it only exists in User1's session. If User2 wants to access
\\server\share1, they need to create their own mapping, either H: drive or
any other drive which suits.

Well, it is kind of the same in Vista .... only moreso.

Unlike previous versions of Windows, when an administrator logs on to a
computer running Windows Vista, the user's full administrator access token
is split into two access tokens: a full administrator access token and a
standard user access token. During the logon process, authorization and
access control components that identify an administrator are removed,
resulting in a standard user access token. The standard user access token is
then used to start the desktop, the Explorer.exe process. Because all
applications inherit their access control data from the initial launch of
the desktop, they all run as a standard user as well. After an
administrator logs on, the full administrator access token is not invoked
until the user attempts to perform an administrative task.

So, when an administrator "elevates" to perform som kind of action which
requires administratice access, their "split token" is replaced,
temporarily, with a a full administrative token. In effect, this means they
now have a different user context. So the drive mappings are changed, as
well. So the H: drive, no longer has a valid mapping in the current context.

The workaround I have used is to open an administrative command pompt -
where you have an elevated token all the time - and create a matching drive
mapping from there (net use h: \\server\share1). Since the statndard user
and the elevated administrator have a common understanding of what "H:"
drive means, everything runs okay.

I understand (well, sort of!) why this design is in place. I won't attempt
to criticise or defend it. But, there you have it.

In an ideal world, administrators would have been able to configure "global"
mappings, which automatically applied to every user context on the machine
(almost like real devices). But, that didn't happen. Most operating systems
have a mish-mash of untidy compromises, in varying degree.

Hope it helps,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

"Matthew" <Matthew@xxxxxx> wrote...
To tell the truth, I haven't investigated it in any closer detail. So I
can't say, positively. If anyone else here has extra info, I'd sure welcome
to hear it.

But I suspect that, yes: the elevated token "remembers" mappings from
previous administrative-token-me sessions; but in the new session they are
"unavailable". Once you delete and remap the mapping, it works fine.
As I said, I don't seek to defend the existing design.

(I'm being diplomatic; but you can guess how I really feel :-) I think we're
in broad agreement)
I have a script which maps the drive automatically, when I open a comand
prompt. It's configured via the AutoRun value in the Registry:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
Value: AutoRun
Type: REG_SZ
Example: C:\Users\Public\Profile.CMD

Profile.CMD sets up all kinds of stuff, so that I have a nice command line
environment to work in, every time. It works like a ( ... dare I say it?
.... ) like a Korn Shell .profile.

There might be better workarounds, but I haven't found them (I haven't
looked very hard).

--
Andrew McLaren
amclar (at) optusnet dot com dot au

Agreement indeed!

OK. Since obviously there's no option to enable/disable and I can't stand
opening a new elevated command prompt to re-map my H drive and then start the
installer from within that command prompt, is there a better way to do it? I
still didn't fully understand your potential solution, as it seemed that was
exactly what I was already doing, but you hinted at it being a 'one time
thing', at least per logon session.

Any idea why the elevated token does not remember a /persistent drive
mapping and subsequently causes windows to throw error messages about not
being able to remap a drive?

Maybe I should set an option on my windows explorer process to always run
elevated? God I hate the idea of that. That'd probably freak Vista out
during boot/login, on top of being very insecure haha. I'm reaching.

"Andrew McLaren" wrote:

In case any others come in and didn't fully understand "need for solution",
since obviously you can run an installer elevated, without a command prompt.

My issue stems around the fact that my "My Documents" are redirected to my H
drive. Installshield and some other setups apparently need the "my
documents" during installation. When running the installer elevated (this
drive mapping issue happens) and causes the setup to error out prematurely.

I know a couple of solutions I could implement, but I really don't like them
for various reasons. I'm so stubborn!
1) I could redirect my documents to the UNC path instead of my H drive
specifically.
I don't like this because right now, the start menu shows my "my
documents" as "My Documents (H". I fear using UNC may have aesthetic
issues haha.

2) Just not redirect my documents. Not really an option as I need them on
the network so they are backed up properly with our regular server backups.
This is my user profile we're talking about.

"Matthew" wrote:

I'm going to jump in and try to get some clarification on this mapping issue.
It use to be that users with administrator level access could make changes to
pre-Vista computers (domain environment) that impact all other users. From
what has been written here, it seems like this may not be the case with
Vista. If an administrator signs on to a Vista computer (domain environment)
and maps a drive, shouldn't that drive be available to all users no matter
their access level. For example, in a corporate environment, every user needs
to have access to drives M-N-O-P. Would it not be ridiculously impractical,
in a corporate domain environment where everyone can sign on to nearly every
computer as themselves, that each time a user signs on to a computer that is
not the computer they mainly use, they would have to map these four drives
each time? Of course, I could be reading this thread entirly wrong, but isn't
there a way that a administrator user could map drives M-N-O-P so every user
that logs into that Vista computer does not have to do him/herself?

"Matthew" wrote:

Ronin,

As you thought, you have indeed misinterpreted some of the responses here.
The use of the term "administrator" is not being referenced akin to the same
term in XP. Whereas a user account can have "administrator" access to the
machine in Vista (just like XP), we're referring to the applications you
launch that have that same access.

The UAC (user account control) in Vista makes everyone (even an
administrator) authorize applications that require "administrative" access to
various system folders/drives/settings/etc.

Every user account now has two possible tokens with different access rights
to certain parts of the system. When you log in, you log in with the
"limited" token. Drives are mapped under this token. When you launch an
application "as administrator", i.e. right click -> run as Administrator, you
are then running that application with the "elevated token".

This post is regarding the fact that drives are generally mapped under your
limited token account. When you are utilizing the elevated token, you have
no access to the mapped drives that currently are mapped under the limited
token.

I hope that made sense.

Also, to answer your question, mapped drives are a userprofile based
setting, i.e. unique to each user on the machine. There's no way to map a
network drive to a letter so that any user logging onto that machine will
automatically have it when they login. This is why there are login scripts
in a domain environment. The login scripts usually map the drives for each
user everytime they log in. If they all require the same mappings, then they
would typically all use the same script, or different scripts with the same
mappings in them.

"RoninV" wrote:

Thanks for the clairification. I just added six Vista (Bus Ed) computers to
our office's network, but I thought I was missing something. I guess you
could say I was trying to lessen calls to IT about missing network drives. I
could not do a 'global' mapping of specific drives that would impact all
users. This might be rhetorical, but the obvious follow up question is, can I
input 'global' scripts that impact all user at log in?

"Matthew" wrote:

You're welcome.

We're actually getting out of scope of this thread now, but yes there are a
couple of ways you could accomplish your task.

If you have a domain-based environment running Active Directory (AD), you
can create a group policy (GPO) containing the login script that needs to be
run. You then link that GPO to all Organizational Units (OU) that contain
the users you want to map the drives. Please note, the "users" container in
the root of your domain is a container, not an OU. GPO can not apply to this
container. Your users have to reside in another OU. This is the preferred
and most effective method.

A dirty approach, and unpreferred, would be to put the login script in the
C:\documents and settings\all users\start menu\programs\start up folder on
each local machine. Then any user that logs into the machine will run that
script.

"RoninV" wrote: