I have a msi file when I install it writes instructions to HKEY_LOCAL_MACHINE;and give UAC to user to do it or not I want to edit this behaviour I mean prompting for a UAC in a way that it will do all the installation without prompting to user for a UAC in windows 7.My question is what needs to be modify in a file.
When UAC is enabled an elevation dialog is always required to get the privileges to write to HKLM. There isn't anything you can modify to prevent this requirement for elevated privilege. You could run the MSI as administrator, or start it from an exe (but the exe will require an elevation dialog anyway), but again these are just ways to get the required elevated privileges.
So you could open the MSI file with Orca, View Summary Information, and then check the UAC compliant box, but if the install really requires elevation then the install will fail with "You do not have sufficient privileges...."
Related
It's a common practice to disallow users from installing programs without elevated privileges, especially in larger companies. When the user runs the installation executable (whether .exe or .msi), the user is prompted for these admin credentials before User Access Control will allow the installation. A lot of programs that require installation take advantage of the default Windows installer .msi packaging or something similar, but an executable file could perform all the same functionalities, right?
Is it this common installation-packaging solution that tells Windows, "Hey, I'm an installer. Something is being installed."? Windows isn't analyzing the actual behavior of the executable file, right?
If your question is about asking for admin credentials, that's normal behavior when an executeable has a manifest that says it requires admin privilieges. I guess that if you say your InnoSetup requires admin privileges it will include a manifest requiring elevation, and Windows will show the elevation prompt.
There is no such thing as Windows InstallShield, in case you are thinking that InstallShield is a Microsoft Windows product. InstallShield is a 3rd party product that in many cases creates an MSI file. MSI files are marked (when built) as to whether they require elevation or not. It's the summary information strean Word Count that says whether the MSI requires elevation to install or not:
https://msdn.microsoft.com/en-us/library/aa372870(v=vs.85).aspx
In the case of an .MSI, sure, Windows automatically knows your installing something. I think your question is more along the lines of what about anything other then an .MSI? Windows has some heuristics built in that AFAIK are managed by the application compatibility team. They do things to detect what they is a setup (like file name, process name, inspection of the summary information stream and so on ) and perform various functions such as detecting a possible failed install, asking if it was an install and if it failed and them performing application compatibility shims such as version lying and forced UAC elevation prompting.
You get to avoid this ugly world my authoring properly designed MSIs. :)
MSIs can be authored per-user or per-machine. Per-user installs won't ask for elevation by default. Per-machine installs will ask for elevation once they hit the InstallExecuteSequence.
I have a installer created in visual studio 2010 which writes into HKCU of registry. It requires administrative privilege during both installation and running.
Now when I am installing it with administrative privilege, from a standard account the registry entries are written into standard user's HKCU registry part. But when I am running it with administrative privilege,it is reading from administrator's registry HKCU.
After lot of searching I came to the conclusion that when you run a program with elevated privilege, It searches for the elevated user's HKCU. But why same thing is not happening during Installation as I have administrative privilege at that time also.
According to another stack overflow question, opposite thing is happening, i.e. Elevated installation writes to admin's HKCU. Can anyone help me how to achieve that workaround.
[Note: I am aware that changing the code to read and write from HKLM ,rather than using HKCU may be best solution for this ,but not for me .Because recently it was changed from HKLM for another big issue and cannot be reverted.]
Now when I am installing it with administrative privilege,
How do you actually start the installation? Do you have an EXE wrapper over your MSI and launch it with the command "Run as administrator"? Is that wrapper launching the MSI latter on during the installation?
Normally, if an MSI is launched by an elevated process (be it the EXE wrapper or a an elevated cmd.exe) the per-user data (registry and files) are redirected to the locations of the new user (i.e. the admin under which now the installer is running). So your registry entries should be created also under the administrator's HKCU hive and your application should find them when launched as an admin.
As a side discussion, is not really recommended to have an application load entries from HKCU but run it directly elevated, things can get confusing. If you want your app to run as admin, then you should install it per-machine and use the appropriate file and registry locations. What was the bug that made you guys switch to per-user installation? (maybe we can help with a better solution)
I want to execute ExecWait in NSIS with admin privileges, I was unable to find any documentation on this issue.
Generally I would recommend that the whole installer should run elevated in a case like this, it makes it clear to the user up-front that elevation is required.
If you cannot do this then you should make sure that the program you want to run requests administrator rights. For this to work you need to launch the program with ExecShell.
If that program does not requests administrator rights you basically have two options:
Use ExecShell with the "runas" verb and hope for the best (Fails if the user is not a member of the administrators group, UAC is off or on < Vista)
Write a small launcher application that requests administrator rights and then launches the real program.
Firstly I want to emphasize that I'm not trying to do anything "nasty" or "hackerish", nor am I trying to hide anything from user here.
During installations (using InstallShield LE) of my application user is prompted by Windows UAC to allow it to run in Administrator mode; If user accepts it - installation continues (standard behavior) and user again can check the option to add this program to autorun list (by adding a registry key to HKLM/../Run). All is fine and normal. But after every Windows restart, when this application starts, UAC kicks in and asks for user permission. Question is, how to avoid it, since it's a bit annoying (yet my app needs Administrator privileges to run)?
I mean user already granted such permissions on installation, so I cannot see a reason why it needs to be prompted on every startup? Moreover, I believe most antivirus software and such, also require elevated permissions to operate, but UAC doesn't prompt for it at Windows Startup.
Thank you for any advises, information, comments or solutions.
Does your application really need to start elevated? Or will it need to elevated access later when the user uses it to perform an action? If you can, drop the later admin task into a separate exe, allowing the main exe to start with no elevation - when you shellexecute the worker process later it will UAC on demand.
At install time, as you have noted, you have elevated the installer. If you want to run elevated code on subsequent runs, automatically, this is the point to install a service - which is what all those other apps you mentioned do.
You can't get around UAC for a process started in an interactive session. You could use a service running as a privileged user but you would be far better off finding a way to do whatever you do without requiring admin rights.
It's not possible for a program to run elevated without prompting. What you want to do is factor those portions of your application that need elevation into a windows service that runs as system. Then your autostarting application can make remoting calls to the service to delgate those activities that the user can't do without elevating.
Not done it but I found this article Selectively disable UAC for your trusted Vista applications that says use 'Application Compatibility Toolkit' from microsoft.
The Compatibility Administrator allows you to create a database of
compatibility fixes that will allow you to run certain applications
without an accompanying UAC.
Run the Compatibility Administrator as admin
select a new database template
Click the Fix button on the toolbar. When you see the Create New Application Fix wizard ... enter details about your app
Select a Compatibility Level
Select RunAsInvoker as the fix
It seems that the last one
Selecting the RunAsInvoker option will allow the application to launch
without requiring the UAC prompt.
Should do what you want provided that the invoker is admin and I think you can do this at start up using the scheduler : Create Administrator Mode Shortcuts Without UAC Prompts in Windows 7 or Vista
As you can see it runs your app in the compatibility mode which may or may not be acceptable for you.
I'm have written an msi file that offers a choice of "per-user" or "for all" installation in the UI phase, and now find that the installer fails on Vista:
if I just reuse the installer that works for XP, Vista will trigger a UAC prompt even for the "per-user" installation, making that installation pointless
if I turn off UAC in bit 3 of PID_WORDCOUNT, Vista won't invoke UAC at all anymore, so even if the user would have permission to install into the machine registry (say), the privilege raising doesn't happen, so the installation fails.
So: how can I prevent installer from invoking UAC when it isn't really needed? Alternatively, how can I programmatically request UAC even if bit 3 is set?
Unfortunately, the Windows Installer does not provide a way to create a single package that can install per-machine and per-user but only prompt for UAC on the per-machine case. The issue is that the bit that can suppress the UAC prompt is stored in the SummaryInformation stream and is not modifiable while the package is executing.
Try this reference: UAC in MSI Notes: How to Build Packages that work for both Standard User and Per-Machine?
I turned off UAC by setting the bit 3 of PID_WORDCOUNT in my MSI package. I can able to install it for "ALLUSERS" and "PER-USER", and also write in for HKLM in both the modes on VISTA machines.
Is it mandatory for you to get UAC popup for privileged user during installation?