How to allow program updates without prompting UAC?

Question

We have about 15-20 users who have this software installed.

We have UAC enabled through GPO as you should, which means the software prompts for admin approval if a standard user trys to install it. Thats fine, they can call the help desk to have the software installed.

My problem is, our help desk is being bombarded every day because users can't update the software and there are updates almost every day which is prompting UAC.

Using procmon.exe to find out where it was trying to write to, I then created a GPO to allow file permission access to the program files folder for this particular software, including the program data folder, but it still prompts for admin approval. It seems as though that the software is using msiexec.exe to run a .msp patch file.

The only "ACCESS DENIED"s I can still see in procmon is things like this:

What can I possibly do to stop this software from prompting UAC with admin password credentials aside from disabling UAC?

Are the patches digitally signed? It looks like [this](http://msdn.microsoft.com/en-us/library/windows/desktop/aa372388(v=vs.85).aspx) may help. — Guvante, Mar 06 '13 at 17:52
There is a link in my comment about how to bypass UAC for certain signed MSI patches. — Guvante, Mar 07 '13 at 17:00
Unfortunately, those pretty much all apply to the developer, no? I'm just the end user. — Ryan Mortier, Mar 07 '13 at 20:58
My apologies, I misread and thought the MsiPatchCertificate setting was related to the machine not the original MSI. — Guvante, Mar 07 '13 at 21:19

score 2 · Answer 1 · answered Jun 25 '13 at 10:24

2

Unfortunately this problem of inconvenience is not easily solved, as you're really talking about misbehaving software -- not meant for the enterprise environment where workstations are locked down. You will need to choose software that can run without aggressively applying patches, then you can manage the schedule and push them out yourself after having signed them. This is why systems administrators avoid consumer-grade software that tries to update often.

answered Jun 25 '13 at 10:24

andy magoon

141
4

Unfortunately it wasn't an option for us. As a systems admin, I don't always get to choose which software our users use but it is my job to make sure it works. We ended up opening those systems with less aggressive group policy objects and turning off UAC. Not an ideal solution but necessary. – Ryan Mortier Jun 25 '13 at 14:21
That's unfortunate. N.b. you can't effectively re-enable UAC once it has been off. – andy magoon Jul 04 '13 at 15:28
That's true. It messes around with the virtual store folders and other stuff. Once it's been off for a little while, turning it back on is going to cause issues. – Ryan Mortier Jul 04 '13 at 19:24

score 0 · Answer 2 · answered Mar 06 '13 at 18:04

0

I'm not sure why you say UAC enabled through GPO as you should. I disagree with that statement. Users shouldn't have admin rights, UAC problem solved.

And on the topic of side-stepping the problem, why are you having users install updates, rather than pushing them out through GPO via a startup script or software installation policy? Sounds like it would be easier than trying to debug this with procmon, and should save the helldesk some grief, in addition to "doing it right" and ensuring a consistent environment.

answered Mar 06 '13 at 18:04

HopelessN00b

53,385
32
133
208

Users don't have admin rights, but I'm not disabling UAC since pretty much every recommendation out there says to keep it on. As for the software deployment, the software is using UAC patching: http://msdn.microsoft.com/en-us/library/windows/desktop/aa372388(v=vs.85).aspx The software installs these data updates using that method, which means the software itself has nothing to do with the updates. – Ryan Mortier Mar 06 '13 at 18:08

score 0 · Answer 3 · answered Mar 06 '13 at 19:12

0

You need to sign the MSI packages and the MSP packages. It's a long list of steps that are detailed in the MSI SDK: User Account Control (UAC) Patching

answered Mar 06 '13 at 19:12

Rob Mensching

101
1

I believe you're correct, I've contacted the company to see what is going on. Hopefully I get a non-canned response and when I do, I'll update this thread. – Ryan Mortier Mar 06 '13 at 19:56

score 0 · Answer 4 · edited Jun 25 '13 at 11:25

0

I already got this kind of issue and my work around was to run specific programm under different user account. If it is possible for your software to use the LSA account, you may have better luck.

edited Jun 25 '13 at 11:25

sysadmin1138

131,083
18
173
296

answered Jun 25 '13 at 09:54

Douda

86
5

The problem is, couldn't these users now go and install unauthorized software using this secondary account's permissions? – Ryan Mortier Jun 25 '13 at 14:22
It deserves specific tests for your scenario. The fact that your soft is ran from a different account doesn't necessary means that your users can run the LSA account for every single software if they don't have the LSA credentials. I think -but I might be wrong on this one- that if your software is updated through his own service, just run the service under the LSA account for testing purposes. – Douda Aug 26 '13 at 08:41

How to allow program updates without prompting UAC?

4 Answers4