Take the 2-minute tour ×

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:

procmon log

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

share|improve this question
Are the patches digitally signed? It looks like this may help. –  Guvante Mar 6 '13 at 17:52
@Guvante Yes they are and the signature is legit. –  Ryan Mortier Mar 7 '13 at 14:20
There is a link in my comment about how to bypass UAC for certain signed MSI patches. –  Guvante Mar 7 '13 at 17:00
Unfortunately, those pretty much all apply to the developer, no? I'm just the end user. –  Ryan Mortier Mar 7 '13 at 20:58
My apologies, I misread and thought the MsiPatchCertificate setting was related to the machine not the original MSI. –  Guvante Mar 7 '13 at 21:19

4 Answers 4

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.

share|improve this answer
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 4 '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 4 '13 at 19:24

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.

share|improve this answer
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: msdn.microsoft.com/en-us/library/windows/desktop/… The software installs these data updates using that method, which means the software itself has nothing to do with the updates. –  Ryan Mortier Mar 6 '13 at 18:08

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

share|improve this answer
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 6 '13 at 19:56

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.

share|improve this answer
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 8:41

Your Answer


