0

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?

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

4 Answers 4

Reset to default
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.

Improve this answer
3
  • 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, 2013 at 14:21
  • That's unfortunate. N.b. you can't effectively re-enable UAC once it has been off.
    – andy magoon
    Jul 4, 2013 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, 2013 at 19:24
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.

Improve this answer
1
  • 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, 2013 at 18:08
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

Improve this answer
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 6, 2013 at 19:56
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.

Improve this answer
2
  • The problem is, couldn't these users now go and install unauthorized software using this secondary account's permissions?
    – Ryan Mortier
    Jun 25, 2013 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, 2013 at 8:41

You must log in to answer this question.

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