0

I am managing a small network of about 15 Windows 8.1 computers/users. None of these users have local admin rights (because I don't want to spend 24 hours a day removing viruses and malware from the computers)

We use a softphone for communication from a company called 8x8. The software is great and does NOT require admin rights to run, however, they do put out new releases about once a month or so. When this happens, in order to upgrade the software to the latest version, I have to physically go to the computer and use a local administrator password to allow the upgrade to occur.

I am hoping there is a way to essentially "trust" or "whitelist" a specific running program to allow that program to be upgraded directly from the local user account (who does not have admin access)

For what it is worth, this specific software does check for updates and starts the update from (what appears to me) to be inside of the program. Meaning, I do not have to go to a website, download a .exe file and run it. If this was the case, I can see where it might be harder, since I doubt there is a way to whitelist a certain .exe file by name or something like that.

Any ideas?

3
  • 2
    No, MS has completely rejected the idea of a Whitelist (which is part of why I think sudo is superior to UAC). That said, Usually, per Windows Resource Protection, which causes UAC to prompt, the file system permissions on the Program Files directory subdirectories are the main trigger for escalation. Try allowing the user full control to the application directory and any related registery keys, and they should be able to update, as long as the process doesn't invoke an elevated integrity process like the Trusted Installer service. Sep 17, 2015 at 20:27
  • You could also use remote desktop so you don't have to physically visit each station.
    – cybernard
    Sep 17, 2015 at 22:30
  • You might be able to use WMI or powershell to install them remotely.
    – cybernard
    Sep 17, 2015 at 22:45

1 Answer 1

0

You can use the Application Compatibility Toolkit to white-list an application so that it does not require administrative rights to run...sometimes. The process is pretty simple, but depending on how the application handles things, it doesn't always work. Here is a rough walk through of the process:

  1. Install the software you want to white-list on a computer.
  2. Download and install the appropriate Application Compatibility Toolkit (for you, that would be Windows 8.1 ACT) on the same computer.
  3. Launch the appropriate Compatibility Toolkit - either x86 toolkit if you need to white-list a 32 bit application or the x64 toolkit for 64 bit.
  4. Create a database and add a new "Application Fix" to it.
  5. Follow the "Application Fix" prompts to select the application and fill out appropriate details. The important thing is to set the "Compatibility Mode" to "runAsInvoker". This effectively white-lists the application...usually.
  6. On the final step of creating the "Application Fix" it will show a bunch of information on the application that it will use to "Match" the rule to. If you want this to keep working on a program that regularly updates, you'll need to remove any fields that reference a version number (after all, the version will/should change after updates).
  7. Once finished, you save the database as an "SDB" file.
  8. Install the "SDB" file on each computer using the following command: sdbinst {Local path to sdb file}
  9. I suggest using Group Policy to create a folder on the local machine, copy the SDB file plus a script to it, and run the script during computer startup. In that case your script will need to uninstall the existing SDB file using the 'n' flag, and install quietly using the 'q' flage. The commands for this would be:

    1. sdbinst -n "database-name"
    2. sdbinst -q {Local path to SDB file}

That said, this process will not work when an application downloads files, unzips them, and then tries to launch another application contained in the unzipped files (after all that is a different application as far as the computer is concerned). You can work around this by getting the update files, deploying them to a particular folder on the local computer (networked folders won't work, since the application would be copied to a temporary folder on the local computer before launching), and updating your white-list to point to the appropriate update applications.

This also just won't work for some applications. Depending on how well, or poorly, the application is setup, you may have no choice but to give the required users local admin access for the computers that run those files. I have that problem with some horrible manufacturing software (from an IT management stand point) that we have no choice but to use.

I have successfully used this process for applications such as UPS World Ship that regularly pushes out updates that require admin rights. This process has not worked for software such as Sage 50 Accounting that packages individual update files that are just wrappers for additional update files that all try to run from temp folder locations...

So, bottom line is, even though this is a possible fix to white-list an application for non-admin users, your mileage will vary from application to application. Other than this, you're looking for some application management software that will also handle pushing out updates...which may be too expensive (or plain overkill) for a small business.

Reference: Removing UAC Prompts with Compatability Toolkit

Not the answer you're looking for? Browse other questions tagged .