G
Guest
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!
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!