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)
Related
We have an ancient win32 product that some customers still want to run in Windows 10, but in some cases several of its components (win32 executables) produce said message when run, while installing and after installing :
"Do you want to allow this app/program to make changes in your PC".
Is there any documentation of what Windows checks to emit the message ?
The message you're seeing is the UAC prompt, and it appears because Windows thinks the program wants admin privileges.
Ancient programs don't have manifests. Modern versions of Windows guess at whether really old programs require admin privileges. If the name of the program sounds like it would be an installer (e.g., setupfoo.exe), it will assume the program needs admin.
But many really old programs, even if they're not installers, often want admin privileges because they often try to do things like save files in the program's installation directory or change machine-wide registry values. If Windows detects a program attempting this and failing because it doesn't have admin privs, it might adjust the program's compatibility options so that next time it runs as an administrator. To check this, right-click on the executable file, choose Properties, and select the Compatibility tab. There you'll find a checkbox named "Run this program as an administrator."
To check if your program has a manifest, open the .EXE in Visual Studio (with just the regular open file command), or other resource viewer/editor tool, and look in the resources to see if it has an RT_MANIFEST resource.
If there is no manifest and the program is well-behaved, you can add one that sets the <requestedExecutionLevel> node to asInvoker.
If it has a manifest, look at the <requestedExecutionLevel> node in the XML. If it's there and it says requiresAdministrator, then there's probably nothing you can do. If it already says asInvoker, then something else is going wrong.
To provide or replace the manifest you have two options. You can create an external manifest file and place it in the same folder with the executable (for some versions of Windows, you also have to tell Windows to rely on the external manifest by changing a registry value).
Alternatively, you can use the manifest tool (mt.exe, which comes with Visual Studio) to embed an appropriate manifest in the executable itself (make a backup of the executable first!). In either case, you want to set the <requestedExecutionLevel> node to asInvoker to avoid the UAC prompt.
Note that, if the program really does need admin privileges, then providing a manifest that says it doesn't will cause the program to fail certain operations. The program might crash, or it might appear to work but silently fail to do something important (like saving your work).
Also note that manifests control other important things that you may have to get right, like marking whether the application is DPI-aware or what Windows versions it supports. So, if you try to add a manifest just to add asInvoker, you might also have to add some other important values. MSDN has lots of documentation on manifests and the manifest tool.
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 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 have created a small exe and associated ini file that we use for diagnostics on customers sites. Customers can go to our website, run a configuration program which downloads the diagnostic exe and ini and sets the exe running.
We do not want to go through a full Windows installation for this as this is overkill for the customers who just want something that will load and start running in 10-15 seconds.
Where should we download this exe to and run according to Windows philosophy and where it is guaranteed to work? The following conditions are essential:
A customer doing this may be an administrator on the machine but may also be a basic user.
UAC may be switched on.
Also during the course of the procedure the user might change.
The exe also needs to be able to write to its ini when it first starts.
The OS could be XP, Vista, Win7 32-bit, Win7 64-bit
If there is one folder that covers all of the above then fantastic but I'd also be happy to use an appropriate different folder for each of the OS's named.
In the folder pointed by %APPDATA% environment variable which is inside the user profile directory (%USERPROFILE%), if it is supposed to be used by any user then %ALLUSERSAPPDATA% which is inside %ALLUSERSPROFILE%
Take a look at Recognized Environment Variables
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.