[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 434
  • Last Modified:

Power User vs. Compatws template


One of our applications has a built-in auto-update program. The suppliers tell us it requires Power user rights for it to work. We don't want to give Power User rights to a couple of hundred people. I was hoping to use a security template instead.
The compatws doesn't work : the files seem to transfer and the installation gets all the way to the end, but nothing happens. (Trying again causes a very vague file access error)
I've tried running comparison programs (snapshots of the files/folders/registry permissions) before and after a good install (with admin rights). I've created a template based on these, but it doesn't work.

So, the question is: Is there something else about Power Users, apart from the file/folder/registry permissions, which might affect the ability of a user to install programs? And, is there anyway to get around it?

  • 4
  • 3
2 Solutions
To try to find out which permissions are missing where, get FileMon (http://www.sysinternals.com/ntw2k/source/filemon.shtml) and RegMon (http://www.sysinternals.com/ntw2k/source/regmon.shtml) from Sysinternals.
Log on as a regular user without additional rights. Start FileMon and RegMon using runas and an administrative account. Filter both to log only update application.
Start the update, check for errors. Adjust NTFS or registry (using regedt32) permissions until you can run the software as user.

Another possibility, using only native tools:
Turn on auditing on your machine (local security policy -- auditing policy: turn on auditing for rights usage and object access).
Then enable auditing on the usual suspicious folders (using Windows Explorer, folder properties/Security/Advanced/Auditing): The program folder of the program, %AllUsersProfile%, and %CommonProgramFiles%.
Turn on auditing as well for HKLM\Software (using regedt32).
Obviously, you only need to audit failures.
Log on as the user you're auditing; use runas.exe to start the event log (runas /user:administrator "mmc eventvwr.msc"), then start the program.
Look in the security event log for access violations and adjust the necessary rights until the program can be run by the user. (Note: some of the violations there are "normal" and can be ignored. Look especially at the ones related somehow to the program in question.)
Paul SCommented:
what about deploying the updates from a master computer with admin rights on the domain?
PeteKingAuthor Commented:
I've used filemon/regmon (thanks for the link), as well as auditing, to establish where the regisitry entries and files are written. As far as I can tell, I've got them all.
However, the install still fails, right at the very end of the install process, before the application shuts down and restarts itself.

I have also been playing with the idea of a central pushout. The first problem with that it that it removes the smoothness of an auto-install and puts the workload back on the IT dept to deploy the package.
The patches are in an exe file format (installshield), with accompanying cab files etc. I've tried using a repackager to turn them into an msi, but the install fails. Any idea how to deploy a patch in this format?
When ransomware hits your clients, what do you do?

MSPs: Endpoint security isn’t enough to prevent ransomware.
As the impact and severity of crypto ransomware attacks has grown, Webroot fought back, not just by building a next-gen endpoint solution capable of preventing ransomware attacks but also by being a thought leader.

Paul SCommented:
what program is this? why does it need to be updated? are all the computers using the same exact hardware? i am not sure how to deploy it from the server.

what about copying the file to each computer on the network and then using some remote network program to run the update.

You could potentially deploy the .exe and use some command like the "net" command. maybe a batch file that uses the runAs command that gets executes remotely.
PeteKingAuthor Commented:
The program is a department wide, niche system, which the manufacturers have been pumping out patches for at the rate of 1 per week. It currently requires a support guy to visit each machine in order to update it (70+ machines). PCs have different hardware but are all w2k.
I've been trying GPO pushes to an OU - which works fine, except the msi packager doesn't like the patches either.

We're trying to get something long-term in place, for minimum impact on our time. The batch file idea might work - I'll try it.
Paul SCommented:
well i don't know if you can run programs or batch files remotely, but you can start services right? create a batch file (or write a program) that runs the update from a folder like "C:\upate". turn that batchfile or program into a service. Then when updating is needed copy the update to all machines from the server. The remotely start the process. You could probably start all the machines using a batch file also.
Paul SCommented:
so how did you get it to work?
PeteKingAuthor Commented:
Well firstly, we're continually hassling the manufacturer, who is now working on an msi package for us.
In testing, we got the service-controlled update (in your last comment) to work, but were not allowed to roll it out. Instead, we had a few desktop support guys run around and update the machines individually, which it looks like we'll continue to do until the msi package arrives.

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now