Standard User Setup Catch 22

Greetings,

Does anyone know a workaround for the following catch 22:

* From a Standard User Account under Vista, a user runs a setup
program to install an application.

* The setup program requires Administrator Privileges in order to run
and displays the admin password dialog. The admin types in the
password and the setup program proceeds with installation.

* During the installation, the setup program queries for the
CSIDL_LOCAL_APPDATA folder location in order to create folders and
install per-user files there. Since the setup program is running with
administrator privileges, the folder location returned is the
administrator's CSIDL_LOCAL_APPDATA folder, not the user's.

TIA

Tell the guys who wrote the software to make it Vista-compatible?



I know this is frustrating. If there aren't other issues with the software I
guess you could make the user account an admin type, install the software
from that account, then change the account back to standard user type.

Annoying, but (probably) effective.

"Max Plank" wrote:

> Greetings,
>
> Does anyone know a workaround for the following catch 22:
>
> * From a Standard User Account under Vista, a user runs a setup
> program to install an application.
>
> * The setup program requires Administrator Privileges in order to run
> and displays the admin password dialog. The admin types in the
> password and the setup program proceeds with installation.
>
> * During the installation, the setup program queries for the
> CSIDL_LOCAL_APPDATA folder location in order to create folders and
> install per-user files there. Since the setup program is running with
> administrator privileges, the folder location returned is the
> administrator's CSIDL_LOCAL_APPDATA folder, not the user's.
>
> TIA
>

On Jan 9, 2:18 pm, jimmuh <jim...@discussions.microsoft.com> wrote:
> Tell the guys who wrote the software to make it Vista-compatible?
>
>
>
> I know this is frustrating. If there aren't other issues with the software I
> guess you could make the user account an admin type, install the software
> from that account, then change the account back to standard user type.
>
> Annoying, but (probably) effective.
>
> "Max Plank" wrote:
> > Greetings,
>
> > Does anyone know a workaround for the following catch 22:
>
> > * From a Standard User Account under Vista, a user runs a setup
> > program to install an application.
>
> > * The setup program requires Administrator Privileges in order to run
> > and displays the admin password dialog. The admin types in the
> > password and the setup program proceeds with installation.
>
> > * During the installation, the setup program queries for the
> > CSIDL_LOCAL_APPDATA folder location in order to create folders and
> > install per-user files there. Since the setup program is running with
> > administrator privileges, the folder location returned is the
> > administrator's CSIDL_LOCAL_APPDATA folder, not the user's.
>
> > TIA

I guess the question is how to make a setup program Vista compatible
given this catch 22. That is:

* A setup program needs administrator privileges in order to write
files to the Program Files & System32 folders.

* When running with administrator privileges, the call to
ShGetFolder(CSIDL_LOCAL_APPDATA) doesn't return the standard user's
local appdata folder.

"Max Plank" <> wrote in message
news:49f445ca-afd9-4394-b721-...
> On Jan 9, 2:18 pm, jimmuh <jim...@discussions.microsoft.com> wrote:
>> Tell the guys who wrote the software to make it Vista-compatible?
>>
>>
>>
>> I know this is frustrating. If there aren't other issues with the
>> software I
>> guess you could make the user account an admin type, install the software
>> from that account, then change the account back to standard user type.
>>
>> Annoying, but (probably) effective.
>>
>> "Max Plank" wrote:
>> > Greetings,
>>
>> > Does anyone know a workaround for the following catch 22:
>>
>> > * From a Standard User Account under Vista, a user runs a setup
>> > program to install an application.
>>
>> > * The setup program requires Administrator Privileges in order to run
>> > and displays the admin password dialog. The admin types in the
>> > password and the setup program proceeds with installation.
>>
>> > * During the installation, the setup program queries for the
>> > CSIDL_LOCAL_APPDATA folder location in order to create folders and
>> > install per-user files there. Since the setup program is running with
>> > administrator privileges, the folder location returned is the
>> > administrator's CSIDL_LOCAL_APPDATA folder, not the user's.
>>
>> > TIA
>
> I guess the question is how to make a setup program Vista compatible
> given this catch 22. That is:
>
> * A setup program needs administrator privileges in order to write
> files to the Program Files & System32 folders.
>
> * When running with administrator privileges, the call to
> ShGetFolder(CSIDL_LOCAL_APPDATA) doesn't return the standard user's
> local appdata folder.
>


User data shouldn't be created during the install. It should be created
during the first run of the program by each user.

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca/phpBB2/

My apologies. Upon re-reading your original post it's apparent that you
weren't approaching this from the end user's perspective. I guess Kerry Brown
has the idea. I would only add that many installation processes ask at their
terminus if the user would like to launch the software upon completion of
setup. This also results in creation of user data in the "wrong" location.

I shall now dope slap myself and retire to stare into my corner.

"Max Plank" wrote:

> On Jan 9, 2:18 pm, jimmuh <jim...@discussions.microsoft.com> wrote:
> > Tell the guys who wrote the software to make it Vista-compatible?
> >
> >
> >
> > I know this is frustrating. If there aren't other issues with the software I
> > guess you could make the user account an admin type, install the software
> > from that account, then change the account back to standard user type.
> >
> > Annoying, but (probably) effective.
> >
> > "Max Plank" wrote:
> > > Greetings,
> >
> > > Does anyone know a workaround for the following catch 22:
> >
> > > * From a Standard User Account under Vista, a user runs a setup
> > > program to install an application.
> >
> > > * The setup program requires Administrator Privileges in order to run
> > > and displays the admin password dialog. The admin types in the
> > > password and the setup program proceeds with installation.
> >
> > > * During the installation, the setup program queries for the
> > > CSIDL_LOCAL_APPDATA folder location in order to create folders and
> > > install per-user files there. Since the setup program is running with
> > > administrator privileges, the folder location returned is the
> > > administrator's CSIDL_LOCAL_APPDATA folder, not the user's.
> >
> > > TIA
>
> I guess the question is how to make a setup program Vista compatible
> given this catch 22. That is:
>
> * A setup program needs administrator privileges in order to write
> files to the Program Files & System32 folders.
>
> * When running with administrator privileges, the call to
> ShGetFolder(CSIDL_LOCAL_APPDATA) doesn't return the standard user's
> local appdata folder.
>
>

"jimmuh" <> wrote in message
news:2296D21E-0816-4C8A-875C-...
> My apologies. Upon re-reading your original post it's apparent that you
> weren't approaching this from the end user's perspective. I guess Kerry
> Brown
> has the idea. I would only add that many installation processes ask at
> their
> terminus if the user would like to launch the software upon completion of
> setup. This also results in creation of user data in the "wrong" location.
>


It shouldn't matter though. Other than the user being annoyed at setting up
the user settings twice they should still get the user setup portion the
first time the program is run in the context of their account.

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca/phpBB2/

That's true, except when the software manages to continue to try to use the
wrong (admin) profile even when run from the regular user profile. I've seen
several instances of this, especially in malware detection software. In one
notable instance you wind up always writing log files to a location under
Documents in the original profile from which the software was run, regardless
of which profile you start it from later on. Ugh.

"Kerry Brown" wrote:

> "jimmuh" <> wrote in message
> news:2296D21E-0816-4C8A-875C-...
> > My apologies. Upon re-reading your original post it's apparent that you
> > weren't approaching this from the end user's perspective. I guess Kerry
> > Brown
> > has the idea. I would only add that many installation processes ask at
> > their
> > terminus if the user would like to launch the software upon completion of
> > setup. This also results in creation of user data in the "wrong" location.
> >
>
>
> It shouldn't matter though. Other than the user being annoyed at setting up
> the user settings twice they should still get the user setup portion the
> first time the program is run in the context of their account.
>
> --
> Kerry Brown
> Microsoft MVP - Shell/User
> http://www.vistahelp.ca/phpBB2/
>
>
>

> User data shouldn't be created during the install. It should be created
> during the first run of the program by each user.
>
> --
> Kerry Brown
> Microsoft MVP - Shell/Userhttp://www.vistahelp.ca/phpBB2/

That is how I've always handled it, but when testing from a Standard
User account, I find that folders and files created under Vista by an
installer running with administrator privileges cannot be accessed
(not even copied) by a program running "asInvoker" from a Standard
User account.

From what I (poorly) understand at this moment, the key is for the
installer to grant ACL permissions to any folders/files created during
the setup process so they can be accessed later by the program running
asInvoker under a standard user account. I'm hoping it's merely a
question of the installer calling SHGetFolderPath() with the proper
htoken:

http://msdn2.microsoft.com/en-us/lib...81(VS.85).aspx
htoken: An access token used to represent a particular user. This
parameter is usually set to NULL, in which case the function tries to
access the current user's instance of the folder. However, you may
need to assign a value to hToken for those folders that can have
multiple users but are treated as belonging to a single user. The most
commonly used folder of this type is Documents.

Some references to the problem and potential solution:

http://www.msdner.com/dev-archive/89/24-113-898420.shtm
http://forums.microsoft.com/MSDN/Sho...76841&SiteID=1
http://msdn2.microsoft.com/en-us/lib...98(VS.85).aspx
http://technet2.microsoft.com/window....mspx?mfr=true

###

Max

Are you including a Manifest file with the application? Here are some links
that are recommended if you are developing applications for Vista.

Go here first for a quick overview on this subject.
Windows Vista Application Development Requirements for User Account Control
(UAC):

http://msdn2.microsoft.com/en-us/library/aa905330.aspx


Download the following document. This includes a complete discussion of the
subject including code examples. Windows Vista Application Development
Requirements for User Account Control Compatibility:

http://tinyurl.com/2pf8n3


There is also a very comprehensive help file that deals with the subject of
developing applications for a least privilege environment that you can
download here:

http://tinyurl.com/2uh8ve


--

Ronnie Vernon
Microsoft MVP
Windows Shell/User


"Max Plank" <> wrote in message
news:4b4efe5b-23b1-4c4f-9bfe-...
>> User data shouldn't be created during the install. It should be created
>> during the first run of the program by each user.
>>
>> --
>> Kerry Brown
>> Microsoft MVP - Shell/Userhttp://www.vistahelp.ca/phpBB2/
>
> That is how I've always handled it, but when testing from a Standard
> User account, I find that folders and files created under Vista by an
> installer running with administrator privileges cannot be accessed
> (not even copied) by a program running "asInvoker" from a Standard
> User account.
>
> From what I (poorly) understand at this moment, the key is for the
> installer to grant ACL permissions to any folders/files created during
> the setup process so they can be accessed later by the program running
> asInvoker under a standard user account. I'm hoping it's merely a
> question of the installer calling SHGetFolderPath() with the proper
> htoken:
>
> http://msdn2.microsoft.com/en-us/lib...81(VS.85).aspx
> htoken: An access token used to represent a particular user. This
> parameter is usually set to NULL, in which case the function tries to
> access the current user's instance of the folder. However, you may
> need to assign a value to hToken for those folders that can have
> multiple users but are treated as belonging to a single user. The most
> commonly used folder of this type is Documents.
>
> Some references to the problem and potential solution:
>
> http://www.msdner.com/dev-archive/89/24-113-898420.shtm
> http://forums.microsoft.com/MSDN/Sho...76841&SiteID=1
> http://msdn2.microsoft.com/en-us/lib...98(VS.85).aspx
> http://technet2.microsoft.com/window....mspx?mfr=true
>
> ###