How to: Script requires Admin privileges to run an update.
Dell KACE K1000 (Version 6.4.120756)
A end user program we use is updated periodically for which I have to run an install against workstations in the blind (after hours - no one logged on). I believe the MSI Install package was changed because the installer now removes the previous version - something it didn't do before. Users have Admin restrictions on them that prevents them from installing or removing software. Before the changes to the MSI and the Admin restrictions, we would run the install and when the end user launched the program, they would be prompted to complete the update cycle no problem. Now, they encounter an error message 1730 saying they need Admin privileges. How can I modify my script to provide temporary Admin permissions for this? The script is being run as a credentialed user "InstallerAdmin" -- permanent permissions cannot be left in place due to security policy. I need a way to turn on permission for the user on a per instance basis if possible and then turn it off again. Ideally, it needs to be restricted to only this install function and nothing else and I need to be able to demonstrate that it is all secure after the fact... I know this is a big request but I've been wrestling with this since before January and thought it would be worth a shot to ask. Thanks.
A end user program we use is updated periodically for which I have to run an install against workstations in the blind (after hours - no one logged on). I believe the MSI Install package was changed because the installer now removes the previous version - something it didn't do before. Users have Admin restrictions on them that prevents them from installing or removing software. Before the changes to the MSI and the Admin restrictions, we would run the install and when the end user launched the program, they would be prompted to complete the update cycle no problem. Now, they encounter an error message 1730 saying they need Admin privileges. How can I modify my script to provide temporary Admin permissions for this? The script is being run as a credentialed user "InstallerAdmin" -- permanent permissions cannot be left in place due to security policy. I need a way to turn on permission for the user on a per instance basis if possible and then turn it off again. Ideally, it needs to be restricted to only this install function and nothing else and I need to be able to demonstrate that it is all secure after the fact... I know this is a big request but I've been wrestling with this since before January and thought it would be worth a shot to ask. Thanks.
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
Pressanykey
8 years ago
Hi,
not an easy one, but I suspect that the MSI is performing some kind of custom action in the execute immediate that stops an "normal" user from completing the installation. It also sounds as if active set-up is being used...
The only thing that I can think of of the top of my head is to sign the MSI signing the MSI using your own (internal / domain internal/ organisation internal) certificate and allowing the installation of signed MSI per GPO by everyone.
I personally would repackage this shite non-conform MSI. If you have support you could put pressure on the vendor to sort it out... VBScab and a few others here (myself included) could offer our services on how to create and maintain ISV installations ;-)
Other than that I can only guess, like I said, see if you can get a log-file of the failed installation and perhaps you can edit it via a transform to get it working correctly.
Cheers
Phil
not an easy one, but I suspect that the MSI is performing some kind of custom action in the execute immediate that stops an "normal" user from completing the installation. It also sounds as if active set-up is being used...
we would run the install and when the end user launched the program, they would be prompted to complete the update cycle no problem.Is it possible that you get a log file to provide more information?
The only thing that I can think of of the top of my head is to sign the MSI signing the MSI using your own (internal / domain internal/ organisation internal) certificate and allowing the installation of signed MSI per GPO by everyone.
I personally would repackage this shite non-conform MSI. If you have support you could put pressure on the vendor to sort it out... VBScab and a few others here (myself included) could offer our services on how to create and maintain ISV installations ;-)
Other than that I can only guess, like I said, see if you can get a log-file of the failed installation and perhaps you can edit it via a transform to get it working correctly.
Cheers
Phil
Comments:
-
I'll see what I can come up with Phil. Thanks for the input. It is appreciated. - John5tephan 8 years ago
Posted by:
anonymous_9363
8 years ago
My thoughts...the MSI might simply have a LaunchCondition set for 'IsPrivileged' or similar, in which case it can be bypassed using a transform to remove it.
Alternatively, it might be that the vendor has fallen into the trap of mixing machine-level and user-level components in a feature. That can also be fixed using a transform but, of course, is somewhat more involved.
@OP: can this MSI be downloaded for us to have a look at?
Comments:
-
Unfortunately no as it is proprietary vendor software. I wish I could. It would certainly help matters. Thanks for the input. - John5tephan 8 years ago
-
@VBSCab, Is 1730 a launch condition error? I think that it's a CA that's trying to do "voodoo" as a normal user and failing...
Regarding the pick&mix of user/machine could also be a problem, but without a log, or the msi crystal balling is difficult ;-) - Pressanykey 8 years ago
Posted by:
jknox
8 years ago
Was this installed by an Active Directory GPO? If so, that may be why it needs the prior installer. It should give you the location if that is the case. If so, recreate the location and put the required version there.
Past that, you should be able to set the Kscript with admin rights to overcome the rights issue.
Comments:
-
jknox, Thanks for the input. I was informed late yesterday afternoon that there is a newly discovered defect in the KACE Agent (6.4.522) that is causing the problem I am experiencing. This defect has been submitted for analysis to the Devs group at KACE. Looks like I'll be waiting a while longer for resolution. - John5tephan 8 years ago
