I have a setup program that I want to install to a local folder. I also do not need it to write any settings to the registry. On Vista, and maybe on Windows 7, executables named similar to setup or install require admin privileges, I would like to be able to run it without admin privileges, to make sure that it does not write to the registry. Is there a way to force this type of mode, sort of in a sandbox?
If you are producing the installer and using MSI, set bit 3 of PID_WORDCOUNT in the MSI package (per this question).
The answer to this question is relevant if you are producing the installer but aren't using MSI - see create a manifest that prevents elevation.
Related
We are writing an installer for our Windows tool. As our tool uses an updater (wyUpdate) and we want that users WITHOUT Administator rights can performs updates. Which is the right directory to install the app to? The standard C:\Program Files requires Administrator rights, so we have discarded this option. After reading a bit on the Web, we have chosen AppData, i.e. C:\Users\USERNAME\AppData\Local.
Is this best practice? Or should we use another directory?
If you do not want to allow your users to mess with the installed program, you have to install it to a folder that needs Administrator privileges.
To allow an automatic update of such application, you need to develop/install a service that runs with Administrator privileges, which will update the installation. This is what Windows Update, Mozilla Maintenance Service, Google Chrome Elevation Service, Adobe Acrobat Update Service and similar services do.
If you do not want to implement a service, but you want the application to be used by all users of the machine, you need to install it to a folder that can be accessed by all users, yet does not need Administrator privileges. You can for example use C:\Users\Public. See also Is there a shared folder in Windows to which non-elevated users have write access?. You can use PUBLIC environment variable to resolve that path.
If the application is to be used by one user only, then you are ok with using C:\Users\Username\AppData\Local – {userappdata} in Inno Setup.
Related question: Deploying application with .NET framework without admin privileges
We have legacy desktop native app with custom setup. The setup is signed and must be run as administrator. Current prod setup EXE that was built and signed 5 years ago is automatically elevated and run as admin on Windows 7 or 8. The setup we rebuilt now and is also signed with different cert and has the same name as old one is not automatically elevated to admin and therefore fails.
What makes Windows to run the setup EXE automatically as admin?
Signing is not related to admin privileges, so don't worry about it in that respect.
To expand on Harry Johnson's comment (which is correct), early versions of UAC on Windows used to automatically elevate programs that looked like setup programs. I don't know the exact algorithm used, but programs with setup or install in the names or descriptions were elevated. That doesn't happen any more, and on UAC programs run by admins are not elevated unless they explicitly elevate with a manifest or a run as administrator.
Without knowing where that setup.exe comes from, if you build it. or it comes with a version of a setup tool (Visual Studio?) then it's hard to say how to fix it.
If this happens to be an MSI-based install then the MSI will ask for elevation if it's marked that way. It's not clear from the question which part of the setup requires elevation, but if it's setup.exe that actually does the install, then all of it needs elevation and it needs an elevation manifest.
I have created a Word Add-In setup.exe file with installshield and I'm trying to find out how to install it without needing administrative privileges. Furthermore, I need the installation to be silent(No UI). I was able to get that to work by extracting the msi file from the executable and run it using
msiexec /i setup.exe /passive
This works perfectly on my machine, but it won't work for any other user in the client's system. The client uses a different system, so when I try the same command, I see that the files are added to my program files, but it isn't in my list of installed programs and the registry keys aren't set. I am not able to make any changes to their system, so I'm trying to find a way to bypass this whether it be third party programs or a little cheat I can use in the command prompt.
I have attempted the following:
Turning off UAC prior to running the command above.
I have removed the node from the manifest file.
numerous commands in the command prompt.
Does anybody else have any other suggestions or an idea of how I can fix this?
Thanks!
Admin access is needed if your app is installing into an area of the system where regular user does not have rights. If you want to be able to install it without having admin rights, it should install under their own user folder (think about %appdata%). Google Chrome is an example of that.
I read in this article:
http://technet.microsoft.com/en-us/library/cc709628.aspx
That Windows detects Installers through file names, following this tip, Is it better to include setup in the file name for the installer
I mean ProductSetup.msi is better than Product.msi???
It's hard to think that Windows does this kind of detection :-)
This only applies to EXE files. If you've got an MSI file, it's up to the MSI file to specify which parts of the MSI require elevation or not.
That's news to me, but it does seem like Windows Vista treats files differently when they have "setup" in their name. It will probably just prompt you for administrative rights up front if it detects that it's an installer, which is what you'd want.
Also worth reading is How User Account Control Affects Your Application, to ensure that your setup runs as administrator embed the correct manifest into the setup EXE. This way it doesn't matter (to Vista) what your installation is called.
That said however, if you expect the application to be installed on a terminal server then if your installer is called something like SETUP.EXE or INSTALL.EXE Terminal Server will automatically kick into "install mode". Should save you some headaches from those customers who don't know they should be in install mode first, or choose not to install via Add/Remove Programs (which also kicks install mode in automatically)
When creating a setup/MSI with Visual Studio is it possible to make a setup for a simple application that doesn't require administrator permissions to install? If its not possible under Windows XP is it possible under Vista?
For example a simple image manipulation application that allows you to paste photos on top of backgrounds. I believe installing to the Program Files folder requires administrator permissions? Can we install in the \AppData folder instead?
The objective is to create an application which will install for users who are not members of the administrators group on the local machine and will not show the UAC prompt on Vista.
I believe a limitation this method would be that if it installs under the app data folder for the current user other users couldn't run it.
Update:
Can you package a click once install in a normal setup.exe type installer? You may ask why we want this - the reason is we have an installer that does a prereq check and installs anything required (such as .NET) and we then downloads and executes the MSI. We would like to display a normal installer start screen too even if that's the only thing displayed. We don't mind if the app can only be seen by one user (the user it's installed for).
ClickOnce is a good solution to this problem. If you go to Project Properties > Publish, you can setup settings for this. In particular, "Install Mode and Settings" is good to look at:
The application is available online only -- this is effectively a "run once" application
The application is avaiable offline as well (launchable from Start Menu) -- this installs the app on the PC
You don't actually have to use the ClickOnce web deployment stuff. If you do a Build > Publish, and then zip up the contents of the publish\ folder, you can effectively distribute that as an installer. To make it even smoother, create a self-extracting archive from the folder that automatically runs the setup.exe file.
Even if you install this way, if you opt to use it, the online update will still work for the application. All you have to do is put the ClickOnce files online, and put the URL in the project's Publish properties page.
Vista is more restrictive about this kind of thing, so if you can't do it for XP you can bet Vista won't let you either.
You are right that installing to the program files folder using windows installer requires administrative permissions. In fact, all write access to that folder requires admin permsissions, which is why you should no longer store your data in the same folder as your executable.
Fortunately, if you're using .Net you can use ClickOnce deployment instead of an msi, which should allow you to install to a folder in each user's profile without requiring admin permissions.
The only way that I know of to do this is to build a ClickOnce application in .NET 2.0+
If the user of your application has the correct pre-requsits installed then the application can just be "launched".
Check out:
Microsoft Family.Show
IF UAC is enabled, you couldn't write to Program Files. Installing to \AppData will indeed only install the program for one user.
However, you must note that any configuration changes that require changes to the registry probably(I'd have to double check on that) administrator privilege. Off the top of my head modifications to the desktop background are ultimately stored in HKEY_CURRENT_USER.