Software Deployment

Custom actions that write to protected files on the destination computer need elevated rights.
While the UAC is enabled and such installer is run, the user is prompted in 2 ways:

1. The user with administrator account is prompted to confirm whether they should continue to run.
2. The user with standard account is prompted to enter a password for an administrator account in order to continue the installation.

I doubt whether UAC can be completely avoided when running an MSI installer.
However, if you're using WPS - You can elevate the rights temporarily by editing the UAC Compatibility Settings on the Windows Installer Options (Target System) tab.

if you're using WPSDon't quote me but I think this is available only in WPS v8 and above.

This happens post install when the standard user tries to Run the application.

I am fairly certain there may be solution or a possible root cause (why doesn't UAC think your app is trusted)? Might be a cert/signing issue? At least with installs, I think that is the case.

Not sure about after installation though, I don't think the Not Trusted prompt is the same as a normal UAC elevation prompt.

Either way, this could solve your issue:

http://www.techrepublic.com/blog/window-on-windows/run-uac-restricted-programs-without-the-uac-prompt/730

Essentially you have to create a scheduled task which has the option to run with elevated rights, then create shortcut to start the scheduled task (which starts the exe bypassing UAC prompt).

We are just getting into Win7 evaluation, but I suspect this has serious drawbacks...

If you right click the installed programs launching exe, click properties and select Compatibility, at the bottom there is a button for Change Setting for All Users. On the next windows at the bottom below Privilege level there is a check box for Run this program as an administrator. How you do this programmatically I haven't figured out yet, but I am guessing there must be a trusted or allowed list somewhere. Then again, there may not be because it would be a way to circumvent UAC.

Still investigating, I have the same problem.

LMAO, good ol MS does it again.

http://www.howtogeek.com/howto/windows-vista/create-administrator-mode-shortcuts-without-uac-prompts-in-windows-vista/

wow, crude and rough, is there a nicer way to deal with this?

Yes.

- Go to your store room
- Pick up The Packager's Persuader (sometimes also known as a baseball bat)
- Visit the idiot who decided that UAC should be switched on
- Begin the education process

Seriously, UAC has no business being present in a properly locked-down environment.

Ha! thanks VB dude, I needed a good laugh.

sigh...

how is one supposed to understand UAC with all this misinformation out there. :-)

Custom actions that write to protected files on the destination computer need elevated rights.


Actually a custom action that writes anywhere protected or not should only be run in the deferred phase as admin where protected areas are concerned.

While the UAC is enabled and such installer is run, the user is prompted in 2 ways:

1. The user with administrator account is prompted to confirm whether they should continue to run.
2. The user with standard account is prompted to enter a password for an administrator account in order to continue the installation.


how this actually works is .

The application information service intercepts any calls to run a new process. There are 3 checks run against a newly launched process.

fusion
installer detection
and heuristics

if any of those 3 checks fail an additional check is made against the user type (either user / admin). When a std user is running the process they are presented with a OTS prompt. If the user is admin they are presented with a consent prompt.

where an admin user is concerned it runs the 3 checks again I can't recall why.

All of this can be toggled with GPO.

http://technet.microsoft.com/en-us/library/dd835564(WS.10).aspx

I would suggest you leave non admin users with the prompt as typically you open a can of security worms allowing std users to bypass this. Where admin users are concerned you can allow it to run without issue.

packaging for UAC is not that hard if you follow the standard packaging best practices that have been around for years and ignored by most.

I am not sure why vbscab doesn't like UAC typically I agree with almost everything he says. In this case I am somewhat confused by his answer.

Are you sure you want to understand UAC?
Are you really sure you want to understand UAC?
Did you ask your system administrator if you really really want to understand UAC?

UAC does nothing but blameshift. This is MS's solution for NOT fixing the OS properly. Now they can blame you for clicking Yes when the OS breaks of gets a virus.

FYI, you should never try to fix your unsecure and improperly configured network at the desktop OS.

My 1cent, saving the other for gas.

Hi all,
my solution for UAC prompts which appear when the user tries to run a application is, that
in the first step i try to figure out why the UAC warning is showing up.
Mostly this happens because the program needs write permission to a specific folder. RegMon
will tell you.
In the second step i create a security template which contains the needed permission on the file system/registry/whatever and apply it with a custom action which calls secedit.

I hope this helps you.

KR
Severin

So, basically by using security permissions to alter the locations that are supposed to be secure, your disabling UAC for those locations and opening up security holes.

Is it really that critical to give the user write permissions to one work directory which an application uses when it is needed?

UAC actually has a lot of good security happening under the covers. It is still insecure but it certainly has made some significant attempts at fixing the OS layer. I wonder if you actually know everything that it is intended to do.

So many people blame UAC for prompts.

If you you dont understand MIC, UIPI, Session 0, filtered tokens AAM, AIS, PM IEPM and many other items then your understanding of UAC perhaps should be revised.

Sure its not perfect but what solution is.

Prompting is not a solution but rather an annoyance that will result in a learned response. Besides, if I were to write a virus, I would mimic the UAC prompt and set the buttons to execute the install which would be an elevated scheduled task which can be set through command line (see the link I posted above). When the actual UAC prompt appears, the user would panic click it to continue the install.

The fixes that UAC may have in the background should be configurable through GPO without having to enable the prompt.

sigh...

back to the OP's question.

You can force an override on any exe to run with elevated privs in a few different ways.

a) you can shim the application with an elevate priv shim.
b) you can manifest the exe you are running to elevate upon execution
c) you can relax perms on the folders where the exe is attempting to write etc.
d) you can use virtualisation / redirection techniques on locked down areas (somewhat cumbersome to implement and can get pretty untidy).
e) you can digitally sign the application

I would suggest you look at the ACT toolkit / App Verifier and look into the LUA tools to help fix your issue.

re The fixes that UAC may have in the background should be configurable through GPO without having to enable the prompt.



as stated earlier UAC prompts can have limited control placed on the number of prompts through GPO http://technet.microsoft.com/en-us/library/dd835564(WS.10).aspx