Basically I either need to Click the UAC button with my program(which i don't believe is possible) or somehow make it so I don't need to click the button to install the software. I will also need to click buttons during the install with my program but I know how to do that. I am only concerned with the UAC things.
One way or the other, the user is going to have to click that button to give you permission to proceed. That's the whole point of UAC, if there were a way to work around it, it would serve absolutely no purpose.
You can either ask for permission sooner (at the beginning of your installation) or later (at the point in the installation when the privileges are first actually required), but you have to do it one of those times.
The standard course of action is to embed a manifest in your application that indicates you require administrative privileges. The applicable line looks like this:
<requestedExecutionLevel level="requireAdministrator" />
Alternatively, you could choose to rely on UAC's "Installer Detection" functionality:
The first application compatibility technology that is part of UAC is called Installer Detection. Because most installers write binaries to the Program Files directory, they overwhelmingly need administrator privileges. Installer Detection is designed to scan the name and the resources of the EXE to determine whether an application is an installer. For example, an executable would be marked as an installer if the executable name or description contained the strings "install" or "setup". So an application named setup.exe, without an application manifest, would trigger a UAC elevation if launched by a token without administrator privileges.
Clicking buttons during your install isn't a very good idea, either. If this is an installer that you're writing, code in some "silent install" flags that you can specify when executing the installer app. If this is a third-party installer that you're using, check the documentation; chances are such flags already exist. The point of these flags is that interactive UI is not displayed at all during setup, meaning that no one has to bother clicking any buttons (which is very hard to get right).
you can install your program in the user's home directory or any other directories which is writable without administrator privilege.
if you're writing an installer wrapper, you can ask for UAC on the wrapper and the wrapper can start the real installer(s) with administrator privilege. Most installers also provides command line options for unattended installations, so you might want to check those instead of scripting button clicks.
You can't click button on UAC consent dialog.
Your other options depend on what you really try to achieve. So give us more details on the your task: there could be better design choices than clicking installer buttons from an application.
To avoid UAC, you can install a service which will start the installation. But user has to consent when you install the service.
Related
i am developing a desktop application.
how can i make it to always run as admin for non-admin user without UAC and admin password by making change in windows registry.
windows change registry option would be preferred but if there is any other option please tell.
any help will be appreciated
thanks
There is no such feature. The point of UAC is to ensure the user is aware that the program being started will have access to admin privileges. If there were a way to turn that off, then malware would do it.
The user can disable the UAC prompts via a control panel setting, but not for a particular program.
If your program always requires admin privileges to do what it needs to do, you should have an entry in its manifest. Modern versions of Visual Studio have options in the project settings for the executable for setting common items like this in the manifest automatically.
I need to create an NSIS installer, which runs with administrator privileges. I request these privileges with
RequestExecutionLevel admin
So far this works. But I also need to place shortcut links on the users desktop. I do NOT want to create the shortcuts for all users but only for the currently logged in user. So I use
SetShellVarContext current
in the installer sections. If the current user has admin privileges, this works. If I have a normal user, Windows (7) asks for credentials for a privileged user, which is also correct. But the installer then creates the icons on the privileged users desktop, and not on current users.
So, how can I tell NSIS, that it should create desktop icons for the current user if she has no admin privileges?
FYI, if I omit both RequestExecutionLevel and SetShellVarContext, I am also prompted for administrative rights but the installer creates icons on the current user desktop as well as for the admin user. I think this is some kind of compatibility behavior.
You are not really supposed to do this (because of this exact issue) and you are basically asking how to create a installer that is broken by design. This is not a NSIS specific problem and not even UAC specific, it has existed since runas was added in Win2000! When you elevate with runas/UAC the new process is executed as that user and with their HKCU and shell folders...
If you need "RequestExecutionLevel admin" in your script then you are doing machine level things and should therefore call "SetShellVarContext all" and install the files in $ProgramFiles and write the uninstall registration under HKLM. This is true for any version of NT, not just Vista+/UAC. (Most people forget to test as non-admin on NT4 and NT5)
If creating shortcuts for all users is such a big problem then I suggest you enable the "Don't create shortcuts" checkbox on the startmenu page so the user can decide.
If you still want to force broken behavior then you need to use this plugin. (You should be able to find plenty of topics about this plugin on the NSIS forum)
When deleting a file in Windows Explorer (Windows 7), if admin privileges are required to delete the file, this dialog is displayed:
Is there a way to achieve this kind of effect in my app?
Currently I am launching a process 'as administrator' to perform the same sort of action (replacing a file rather than deleting it), so the user is shown the generic UAC dialog, asking:
"Do you want to allow the following program to make changes to this computer?"
Is the kind of helpful UI shown by Explorer (as opposed to the generic UAC dialog) possible in a 3rd party app?
I'm guessing no, since it would allow 3rd parties to elevate privileges in a sneaky way.
Use Button_SetElevationRequiredState to add the shield to the button. When the user pushes the button, use the COM elevation moniker to create the helper object.
The default setting on Windows 7 is for most system components to not show the UAC dialog.
If you change your setting to always prompt, you will see that clicking Continue in the Explorer dialog would create the normal UAC prompt.
As a non-system binary, your code would always prompt except at the most lenient UAC setting (never prompt.)
When a normal user runs a WiX installer which requires elevation, there appears to be a delay of 30 seconds or more between the user clicks the "Install" button and the UAC prompt comes up. This happens even though the install button is marked with the UAC shield, suggesting the installer "knows" that elevation will be required.
Is there a way to IMMEDIATELY throw up the UAC when the user 1) runs the installer or 2) clicks that "Install" button?
The length of time for the UAC prompt to come up depends on the size of the exe. (Try it yourself by right-click run as admin various exes of various sizes.) Therefore I have heard it suggested that you make a teeny launcher exe that will bring the prompt up quickly, and have it launch everything else. Anything launched from an elevated process is elevated.
Be sure to name your launcher well, for the 1% of users who actually read the UAC prompts.
How big is your MSI file? I don't know for a fact, but I think splitting your files into a separate .cab file and possibly digitally signing it might make the validation of the MSI file go faster.
Otherwise, there really isn't anything you can do about it to my knowledge. I hope someone proves me wrong. :-)
I have a program that was written on XP. What I've found out is that it doesn't work properly on Win7 because HLKM is no longer writable by non-admins.
Essentially, when you register the program, the licensing information is supposed to go into the registry. That information is valid for everyone on the computer, not just the one user, so I don't want to put it in HKCU. But any copy of the program needs to be able to edit that registry (even if it's a non-admin running it), because there are certain situations when it's going to go get updated license information from my web server (for example, if the registry data is lost or damaged, or if your current license is expired and it needs to see if we've applied an extension).
It's not horrible if it goes out to the web server for every unique user who starts up the program, but it causes some annoying issues, so I'd rather it continue to work the way it did in XP. Is there a way to store data in the registry and still have it shared under Win7, or am I going to have to start looking at storing an INI file on the drive?
Here is how I would architect it: your setup runs elevated and sets up the key. Then if their licensing gets corrupted or whatnot, you enable a button or menu item that has text like "fix license" or "update license". You put a shield on that button or menu item. When they click it, you launch a separate exe using ShellExecute. That exe has a manifest that requires elevation. It can then write to the protected area of the registry. The rest of the app can have a manifest with asInvoker.
If you want it to be completely invisible, either the whole app must always run elevated (annoying) or sometimes the app will just launch another exe that asks for elevation without warning - in which case the smart users will say no. A little less invisibility is a good thing imo.
Could you get the installer to make your particular area of the registry to be writeable by everyone? The installer will need to be run with elevated privileges anyway, I'd expect - so this would seem an ideal approach.