/build/static/layout/Breadcrumb_cap_w.png

Active Setup asks for Admin rights

Hey guys

I need to deploy Adobe Photoshop Elements 5 in our shop where all users are PowerUsers only. To install the app I use a different admin User. So far so good.
To be able to deploy a few settings, I wanted to use Active Setup so the newly logged on user gets the repair (and I always thought that in Active Setup one has Admin rights).
However during Active Setup the Repair stops and says that you need admin rights. I checked the MSI and the AdminUser condition is in the LaunchCondition table.

What can I do now? Should I remove the LaunchCondition? Can I elevate the rights during Active Setup?

Thanks for your ideas.

Cheers
Roland

0 Comments   [ + ] Show comments

Answers (8)

Posted by: spartacus 13 years ago
Black Belt
0
How about altering the launch condition to AdminUser OR Installed ?


Spartacus
Posted by: aogilmor 13 years ago
9th Degree Black Belt
0
Isn't Active Setup non-MSI? that is, if the EXE requires admin rights you might get that prompt. Also, it's advisable to use Active Setup for per user settings; if you have machine settings put them in the MSI and let Active setup do only the per user settings.
Posted by: Tone 13 years ago
Second Degree Blue Belt
0
I would assume they are talking after the stub has launched msiexec.

[;)]
Posted by: spartacus 13 years ago
Black Belt
0
... and of course a lot might depend on what the actual msiexec command is in the StubPath

msiexec /fup {ProductCode} /qn

is frequently used for a (silent) repair of the user specific settings

Regards,

Spartacus
Posted by: WayneB 13 years ago
Blue Belt
0
G'day all,

Roland; wouldn't the stubpath run the msiexec in the system context, if it was installed from SMS as administrator? How do you install the app and do you log the install?

Could someone clarify this for me?

Cheers
Wayne
Posted by: fosteky 13 years ago
Purple Belt
0
The following is a guess:

I think Active Setup runs the stubpath in the user's context, but with temporarily elevated rights (that's its whole point I think). Anyway, the MSI's Launchcondition will just check if the user effectively belongs to the local admin group - which it wont - thus the failure. But Active Setup achieves elevated rights for the user some other way. So just remove the Launchcondition.

For instance, if you wrote a VBscript that did the following three things:
1) copied a new file to Program Files
2) reported current user credential
3) reported all members of Local Administrators group

and ran it using an Active Setup stubpath and logged in with a basic user account I suspect you would get the following:
1) it would copy to Program Files
2) it would accurately report the user's credentials
3) you would see that that credential wasn't in the local admin group (directly or nested)
Posted by: rpfenninger 13 years ago
Second Degree Green Belt
0
Thank you all guys.

I hope I can clarify a few things:

Spartacus, I couldn't find the time yet to try the modified LaunchCondition as you told me to do. I hope I will find the time next week...

aogilmor, yes the settings that I try to deploy with ActiveSetup are user settings only.

I use the following command line to achieve this: msiexec /fup {ProductCode}

WayneB, that's what I thought too. However, if we log in as a PowerUser, the installation triggered through ActiveSetup aborts with the message that one needs admin rights [:(]
We install this package (the original with a custom transform) with ZENworks for Desktops 4 using an install user with AdminRights (so it definitely is a per-machine installation) however the user can't even repair it %*#!$
I haven't logged the installation so far as the message seems pretty clear.

Ok, I will definitely start with modifying the LaunchCondition and come back to the forum.

Thanks a lot!
Posted by: jmcfadyen 13 years ago
5th Degree Black Belt
0
active setup does run in user context for those that want to know.

users are allowed to run MSI's even when policy prohibits it if the MSI has been preinstalled. The user will however still need rights to any areas the MSI will write to.

as for the launch conditions you should remove AdminUser on all MSI's destined for enterprise deployment or at least swap them out for PriviledgedUser
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ