Quote: Originally Posted by Julio Cortez
I guess this should be handy:
To change the elevation prompt behavior for administrators
- Click Start, click Accessories, click Run, type secpol.msc in the Open box, and then click OK.
- From the Local Security Settings console tree, click Local Policies, and then Security Options.
- Scroll down to and double-click User Account Control: Behavior of the elevation prompt for administrators.
- From the drop-down menu, select one of the following settings:
- Elevate without prompting (tasks requesting elevation will automatically run as elevated without prompting the administrator)
- Prompt for credentials (this setting requires user name and password input before an application or task will run as elevated)
- Prompt for consent (default setting for administrators)
- Click OK.
- Close the Local Security Settings window.
The original article can be found here: User Account Control Step-by-Step Guide
Hope it helps! *edit*
Still, this makes no mention of the "automatically denying the elevation" case you report.
I'm still convinced that for some reason the user doesn't have the right permissions to start with. Have you perhaps tried with another administrative account, on the machine giving trouble?
We have tried using a domain admin account on the PC that does not prompt and we get the same results of fail to elevate.
We have tried removing the user from Local administrators group and readding them, no joy.
Going through Secpol.msc Local Policies, Security Options, there is no "User AccountControl: Behavior of the elevation prompt of administrators"
Here is was I see:
User Account Control: Behaviour of the evelation prompt for administrators in the Admin Approval Mode
User Account Control: Behavior of elevation prompt for standard users
On the PC this works and on pc this does not work on, The first is set to "Prompt for consent for non-windows binaries"
The second is set to "Prompt for credentials"
No difference in settings.