Microsoft Windows Vista Community Forums - Vistaheads
Recommended Download



Welcome to the Microsoft Windows Vista Community Forums - Vistaheads, YOUR Largest Resource for Windows Vista related information.

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so , join our community today!

If you have any problems with the registration process or your account login, please contact us.

Driver Scanner

Run As Administrator loses access to mapped drives

microsoft.public.windows.vista.general






Speedup My PC
Reply
  #1 (permalink)  
Old 10-03-2007
Matthew
 

Posts: n/a
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!
Reply With Quote
Sponsored Links
  #2 (permalink)  
Old 10-04-2007
Andrew McLaren
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
"Matthew" <Matthew@discussions.microsoft.com> wrote...
> 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.


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


Reply With Quote
  #3 (permalink)  
Old 10-04-2007
Matthew
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
While I understand your explanation of the split token mechanism, I don't
understand how that can fully be the case.

To simplify, in XP, user1 and user2 have different user contexts, thereby
user2 has no idea of user1's drive mappings. Got that. Makes sense.

In Vista, if the token split creates two different user contexts, so to
speak, then it would stand to reason that administrative-token-me, would have
no idea of standard-token-me's drive mappings. Correct? It seems like
that's what you're trying to say.

Going by that theory, it would also stand to reason that the by seeing what
drives were mapped from the elevated prompt should show "no drives were
mapped" as it would in the XP test. This is where I'm confused. My elevated
command prompt KNOWS exactly what drives I had mapped. They are all just
listed as "unavailable".

So my administrative-token-me knows standard-token-me had drive mappings,
but just isn't allowed to use them. Maybe this only occurs because of the
way Windows "remembers" previous network connections, so that's why it knows
they are there, but just unavailable?

If that is the case, then I kind of understand how it works, although I
don't like it.

On a side note, I don't understand your 'solution'. Your posted solution is
exactly what I do now. I open elevated command prompt, map the H drive so
it's accessible, and then I run my tool. The *problem* with this solution is
it's only temporary. As soon as I close that elevated prompt, and open
another elevated prompt, the H drive is once again "unavailable" requiring me
to re-map it again.

I tried using the /persistent parameter to always remember the drive
mapping, but now everytime I reboot my system and log in, I get a lovely
bubble near my clock telling me my system was unable to re-map all drive
letters and asks me to click the bubble to see my drives that failed to map.
If I click on it, all my drives are there. I can only assume it's the "H
drive under elevated context that couldn't be mapped" and when I click that
bubble to identify which mapped drives failed, that opens explorer in the
standard context preventing me to see the drives for the administrative
context.

All in all this is retarded design! The whole point of UAC is to prevent
apps (not user) from accessing system sensitive areas. Why does it treat my
account differently? It's supposed to treat the app differently.

"Andrew McLaren" wrote:

> "Matthew" <Matthew@discussions.microsoft.com> wrote...
> > 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.

>
> 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
>
>

Reply With Quote
  #4 (permalink)  
Old 10-04-2007
Andrew McLaren
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
"Matthew" <Matthew@discussions.microsoft.com> wrote...

> Maybe this only occurs because of the
> way Windows "remembers" previous network connections, so that's why it
> knows
> they are there, but just unavailable?


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.

> If that is the case, then I kind of understand how it works, although I
> don't like it.


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)

> it's accessible, and then I run my tool. The *problem* with this solution
> is
> it's only temporary. As soon as I close that elevated prompt, and open
> another elevated prompt, the H drive is once again "unavailable" requiring
> me
> to re-map it again.


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


Reply With Quote
  #5 (permalink)  
Old 10-04-2007
Matthew
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
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:

> "Matthew" <Matthew@discussions.microsoft.com> wrote...
>
> > Maybe this only occurs because of the
> > way Windows "remembers" previous network connections, so that's why it
> > knows
> > they are there, but just unavailable?

>
> 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.
>
> > If that is the case, then I kind of understand how it works, although I
> > don't like it.

>
> 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)
>
> > it's accessible, and then I run my tool. The *problem* with this solution
> > is
> > it's only temporary. As soon as I close that elevated prompt, and open
> > another elevated prompt, the H drive is once again "unavailable" requiring
> > me
> > to re-map it again.

>
> 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
>
>

Reply With Quote
  #6 (permalink)  
Old 10-04-2007
Matthew
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
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:

> 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:
>
> > "Matthew" <Matthew@discussions.microsoft.com> wrote...
> >
> > > Maybe this only occurs because of the
> > > way Windows "remembers" previous network connections, so that's why it
> > > knows
> > > they are there, but just unavailable?

> >
> > 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.
> >
> > > If that is the case, then I kind of understand how it works, although I
> > > don't like it.

> >
> > 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)
> >
> > > it's accessible, and then I run my tool. The *problem* with this solution
> > > is
> > > it's only temporary. As soon as I close that elevated prompt, and open
> > > another elevated prompt, the H drive is once again "unavailable" requiring
> > > me
> > > to re-map it again.

> >
> > 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
> >
> >

Reply With Quote
  #7 (permalink)  
Old 12-06-2007
RoninV
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
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:

> 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:
>
> > 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:
> >
> > > "Matthew" <Matthew@discussions.microsoft.com> wrote...
> > >
> > > > Maybe this only occurs because of the
> > > > way Windows "remembers" previous network connections, so that's why it
> > > > knows
> > > > they are there, but just unavailable?
> > >
> > > 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.
> > >
> > > > If that is the case, then I kind of understand how it works, although I
> > > > don't like it.
> > >
> > > 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)
> > >
> > > > it's accessible, and then I run my tool. The *problem* with this solution
> > > > is
> > > > it's only temporary. As soon as I close that elevated prompt, and open
> > > > another elevated prompt, the H drive is once again "unavailable" requiring
> > > > me
> > > > to re-map it again.
> > >
> > > 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
> > >
> > >

Reply With Quote
  #8 (permalink)  
Old 12-06-2007
Matthew
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
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:

> 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:
>
> > 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:
> >
> > > 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:
> > >
> > > > "Matthew" <Matthew@discussions.microsoft.com> wrote...
> > > >
> > > > > Maybe this only occurs because of the
> > > > > way Windows "remembers" previous network connections, so that's why it
> > > > > knows
> > > > > they are there, but just unavailable?
> > > >
> > > > 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.
> > > >
> > > > > If that is the case, then I kind of understand how it works, although I
> > > > > don't like it.
> > > >
> > > > 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)
> > > >
> > > > > it's accessible, and then I run my tool. The *problem* with this solution
> > > > > is
> > > > > it's only temporary. As soon as I close that elevated prompt, and open
> > > > > another elevated prompt, the H drive is once again "unavailable" requiring
> > > > > me
> > > > > to re-map it again.
> > > >
> > > > 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
> > > >
> > > >

Reply With Quote
  #9 (permalink)  
Old 12-07-2007
RoninV
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
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:

> 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:
>
> > 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:
> >
> > > 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:
> > >
> > > > 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:
> > > >
> > > > > "Matthew" <Matthew@discussions.microsoft.com> wrote...
> > > > >
> > > > > > Maybe this only occurs because of the
> > > > > > way Windows "remembers" previous network connections, so that's why it
> > > > > > knows
> > > > > > they are there, but just unavailable?
> > > > >
> > > > > 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.
> > > > >
> > > > > > If that is the case, then I kind of understand how it works, although I
> > > > > > don't like it.
> > > > >
> > > > > 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)
> > > > >
> > > > > > it's accessible, and then I run my tool. The *problem* with this solution
> > > > > > is
> > > > > > it's only temporary. As soon as I close that elevated prompt, and open
> > > > > > another elevated prompt, the H drive is once again "unavailable" requiring
> > > > > > me
> > > > > > to re-map it again.
> > > > >
> > > > > 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
> > > > >
> > > > >

Reply With Quote
  #10 (permalink)  
Old 12-07-2007
Matthew
 

Posts: n/a
Re: Run As Administrator loses access to mapped drives
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:

> 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:
>
> > 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:
> >
> > > 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:
> > >
> > > > 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:
> > > >
> > > > > 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:
> > > > >
> > > > > > "Matthew" <Matthew@discussions.microsoft.com> wrote...
> > > > > >
> > > > > > > Maybe this only occurs because of the
> > > > > > > way Windows "remembers" previous network connections, so that's why it
> > > > > > > knows
> > > > > > > they are there, but just unavailable?
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > > If that is the case, then I kind of understand how it works, although I
> > > > > > > don't like it.
> > > > > >
> > > > > > 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)
> > > > > >
> > > > > > > it's accessible, and then I run my tool. The *problem* with this solution
> > > > > > > is
> > > > > > > it's only temporary. As soon as I close that elevated prompt, and open
> > > > > > > another elevated prompt, the H drive is once again "unavailable" requiring
> > > > > > > me
> > > > > > > to re-map it again.
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >

Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Access Denied when Opening Office Documents Netware Mapped Drives lroot microsoft.public.windows.vista.networking sharing 2 07-20-2007 02:20
pb with rights on mapped drives shoros@hotmail.fr microsoft.public.windows.vista.administration accounts passwords 0 03-11-2007 11:58
Mapped Drives Michael O microsoft.public.windows.vista.general 8 02-28-2007 21:08
Mapped Drives Michael O microsoft.public.windows.vista.administration accounts passwords 1 02-28-2007 14:10
Mapped Drives Michael O microsoft.public.windows.vista.networking sharing 0 12-23-2006 14:25




All times are GMT +1. The time now is 16:43.




Driver Scanner - Free Scan Now

Vistaheads.com is part of the Heads Network. See also XPHeads.com , Win7Heads.com and Win8Heads.com.


Design by Vjacheslav Trushkin for phpBBStyles.com.
Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.6.0 RC 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120