Software Deployment Question

Software updates require administrator privileges, users are not local administrators.

01/06/2015 4798 views

Good Afternoon!

I work IT support for a midsize company, and we are experiencing some pains when it comes to administrative rights. We are transitioning from XP to Windows 7, and are running into a few permissions issues. We use a program to manage payroll. The majority of the users that managed payroll were on Windows XP. When the program needs to update, it runs an .exe. On XP, there was no issue running this update. When these payroll users were moved to Windows 7, we discovered that running these updates required administrative credentials. At first it was a minor inconvenience, one of our techs would go by and enter the credentials (about 3 times per update). As the number of users grows, we are wasting more and more time putting these credentials in.
Is there a way we can push this update out via kbox? Or perhaps with AD? I have been reading that you can 'advertise' an application via AD, and that any user can install an advertised application without administrative rights. Do any of you have any experience with this? My other thought is writing a PowerShell script that gets the username, elevates the user to an administrator, installs the update, and then demotes the user. Do you think this is possible?

Thank you for any help!
TL;DR : Need away for underprivileged users to install updates via an .exe without tech support intervention.

0 Comments   [ + ] Show comments


Community Chosen Answer

With the kbox you should be able to push the update in a scheduled manner. Based on your description it sounds like the .exe that executes for updating lives locally on each machine. So with a scheduled script you could execute that .exe. When setting up the script you can define the context the script should run as (i.e., Local System, Domain User). That might get around the Admin privileges issues. I find it's not always perfect with Windows 7. Disabling UAC might be necessary here too. I'd recommend testing and retesting.

One other option might be to make it available in the User Console Library under Service Desk. We don't have a need for this in my organization so I'm not too familiar with it. Basically you give the user the ability to log in and get the software or files. There's a way to automate that installation from what I can tell. But, I'm not sure what context this would run under. So you might end up with the same problem if it runs as the logged in user. You might have better luck with a script. 

Let us know how it goes!
Answered 01/06/2015 by: getElementById
Third Degree Blue Belt

All Answers

Thank you getElementById, I will do some experimenting today and post back with my results!
Answered 01/07/2015 by: Mduck
Senior White Belt


Advertising with AD only works with Windows installer packages (MSI and MSP's). If you are using kbox, I would not recommend doing this one update with AD.


You need to do some investigation to see how the updates works. Can they ignore the update for a day or two??
If so, that will give you enough time to get a call logged by the users, then you can get the update and deploy that with your kbox.

it might be worth a shot (about 8 seconds of effort) to contact the vendor, they maybe able to tell you in advance of updates and give you a url to download it.

I would take a wager they will just say 'make your users local administrators' but it should take less than 8 seconds.

Answered 01/07/2015 by: Badger
Red Belt


Thank you for the input Badger!

I have done more research. The program is an .exe, that then calls multiple.msi's (for each module) when its updating.  When it updates, it basicallyreinstalls the entire program over again. We have tried 'extracting' the .msi'sand 'stringing' them together, but to no avail.

Badger, do published applications need admin rights to update? Or do they keeptheir 'special' status? I am thinking more and more that Kbox will not be ableto accomplish this task (I was informed today that we have tried scripting theupdate in the past, but there has been no success), and that I will have to useAD.

I am part of a team that has been struggling with this for a while. I am stilllearning what our AD environment looks like, and this publishing applicationsroute sounds like the best bet.

Answered 01/07/2015 by: Mduck
Senior White Belt

  • On a sacrificial PC (hopefully a VM!):

    - delete the junk from all your TEMP folders
    - enable verbose MSI logging (Google 'voicewarmupx')
    - run the update.

    You'll get a number of .LOG files prefixed "MSI" in %SystemRoot%\TEMP. The timestamp will tell you what order in which the MSIs need to be installed - my guess is that just running them randomly fails because module 'y' requires module 'x' to be installed first. The logs will also show the command line which the stub EXE is passing to MSIEXEC. I can practically guarantee that one of the properties is one called 'ISSETUPDRIVEN' with a value of '1'.

    Once you have all that information, you can build a set of transforms (MSTs) for the MSIs and then create your own deployment, be that by command file or a controlled sequence of deployments by KBox (I don't know these appliances at all so can't help with that).

    Lastly, if you use the MSIs, add to the command line the argument for verbose logging as, if they fail, you stand no chance whatsoever in determining what went wrong without a log.
Thanks for the tip VBScab!

I will give that a go today, and report back with my findings!
Answered 01/08/2015 by: Mduck
Senior White Belt

This content is currently hidden from public view.
Reason: Member has been banned from the site For more information, visit our FAQ's.
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