I'm trying to package and deploy a wpf application. I used install shield and I have created the setup file. When I try running the setup file it keeps throwing this error code
1925: it needs admin privileges to run the setup.
How do I configure the setup file to be run by any user? Should I make any changes in the registry during the creation of setup file in install shield? Is there anyway to work around this problem?
Thanks
It sounds like you're trying to create a per-user installation. Since Windows Vista, this requires several steps, but was made simpler with Windows 7. I would check a verbose log in case it highlights any specific problems, and if not, follow this general advice:
If this is always a per-user installation, set General Information > Require Administrative Privileges to No and set the ALLUSERS property to empty.
If this is only conditionally per-user, leave them as Yes and 1 respectively, and use the MSIINSTALLPERUSER property with ALLUSERS=2 to select a per-user installation at run time. Note that this only works on Windows 7 (MSI 5.0) and later.
Ensure that your setup.exe, if you are using one, does not elevate. Set Required Execution Level to Invoker in the setup.exe tab of the Releases view.
If you are not using MSIINSTALLPERUSER, ensure that you are not installing any resources to any machine locations. This includes installation files to the ProgramFilesFolder, registry keys to HKEY_CLASSES_ROOT or HKEY_LOCAL_MACHINE, or other machine-level items such as Windows Services. Note that you may have to exclude services from MSIINSTALLPERUSER scenarios as well.
Related
We made some changes to the installation and updating process of our Windows app recently, and some users are now complaining that Windows sometimes automatically deletes the main application .exe file.
It usually occurs after users update app using built-in web update feature. The feature is implemented using .msi built in Advanced Installer tool.
We are struggling to figure out what is causing this, and haven't found a way to consistently reproduce the issue (though we've seen it happen as well).
Here's what changed with our installation and web updating process:
The main installer for our application is now a standard .msi, which becomes a part of the Windows installation system and is natively manageable by Group Policy and other system features, such as rollback or versions. In previous versions that did not have this problem, our installer was a .exe built with the SetupBuilder tool.
We introduced the redesigned web updater feature inside the app (to update to new versions within the app). It uses the same .msi as the main deliverable as for installation. .msi is downloaded from our server in a form of .exe which is then extracts MSI and starts it. MSI then updates file in our installation. These .exe and .msi is built with Advanced Installer tool which provides such a web update feature to developers. In previous versions that did not have this problem, our web update feature was developed with SetupBuilder tool which provided a custom web update files - .exe web updater that downloads a number of web update files containing patch to our app.
The goal of a transition to the standard .msi installer was to make it easy for our clients to deploy the app in organizations - say, mass deploy using group policies and other similar tools.
Has anyone else experienced a problem like this? Any ideas on how to troubleshoot and try to reproduce?
Theory: Before doing anything else: The first thing I would ask the people who report the problem is if they have re-packaged your older, legacy (non-MSI) setup to be their own MSI file? This can cause a well-known upgrade problem along the lines of what you explain (file missing). Please check first. Tell them to uninstall the existing version and then install the new one - that is the simplest way. Not always enough (some obscure problems possible).
Mismatched component GUIDs could cause missing files after upgrade, as could file version downgrade scenarios and various other technicalities. You could try to install to a new default location on disk to avoid these problems. The reason this can work is very technical and hard to explain tersely. Essentially you de-couple yourself from "the sins of the past". It is generally enough to change the name of the file in question: for example MyApp.exe to MyAppNew.exe or maybe add the major version: MyApp5.exe, but maybe try the folder change first ProgramFiles\MyCompany\MyApp => ProgramFiles\MyCompany\MyApp5.
How do you configure your upgrade? View "Upgrades", what is selected: "Uninstall old version first and then install new version" or "Install new version first and then uninstall old version".
Blog Entry:: Why Windows Installer removes files during a major upgrade if they go backwards in version numbers (might be of help).
Deployment Debugging: For open ended debugging of MSI and deployment problems in general one obviously needs to gather intel and that means logging and system inspection.
Logging: First try to get a proper log file for the systems where this problem occurs. In Advanced Installer you can tick the "Enable verbose logging" in the Install Parameters view to enable verbose logging for all package installations. This adds the MsiLogging property to the compiled MSI and every installation of the MSI will cause a MSI log file with a random name to be created in the TMP folder. View the folder, sort by date and the file should be at the top. Suggest you do this and then tell the users to send you the log files when relevant. Maybe you have this setting enabled already?
Further Logging: There are many ways to enable logging, and you can find a description here: Enable installation logs for MSI installer without any command line arguments. The MsiLogging property is just one possibility.
To log a single MSI setup: http://www.installsite.org/pages/en/msifaq/a/1022.htm.
To enable global logging for all MSI operations on the machine: Please see this FAQ-entry from installsite.org, section "Globally for all setups on a machine" - for the exact procedure.
How to interpret an MSI Log File.
When a non-admin user tries to install setup.exe it should throw the below error message as per our Installshield condition.
"You did not log on as Administrator or have required permissions to install "
But recently when we tried to install setup as non-admin it didn't throw any error. When Setup.exe is executed, nothing happens.
Condition:
AdminUser AND Privileged : message -> You did not log on as Administrator or have required permissions to install
Initially we thought some windows update could have caused the issue. But when I created a sample setup.exe it throws the error. How to identify why my setup.exe stopped to throw the error message.
Note : No file generated in %temp% folder when running setup.exe. If we double click or, giving Run as Admin nothing happens. Also Requires Administrative Privileges is given Yes.
While the AdminUser and Privileged properties used to tell you what you're asking for, they were altered for the introduction of UAC. The theory is that in most cases a Windows Installer package would elevate in the InstallExecute phase, while its UI would be run as a limited user. Since this wasn't typically done before UAC (though it was possible with advertisement), Microsoft altered the behavior of these properties for better backwards compatibility.
There is a way to request the original meaning of these properties: set MSIUSEREALADMINDETECTION to 1.
However, if you rely on this to prevent installation, you're not doing things the way Microsoft expects you to do them. You should instead fix whatever's broken when your installation is not launched with full admin privileges, and then you can remove your check. If there's already nothing broken, then just remove the check. Windows Installer will only install as a limited user if you specifically enable it by your authoring. (See ALLUSERS, MSIINSTALLPERUSER, and the rest of Single Package Authoring for the more recent approach, or, before that, bit 3 of the Word Count Summary property, which when set to the typical 0 requires elevation.)
As far as logging goes, setup.exe and Windows Installer will only log if requested, either by command line, authoring, or policy. Use the command line (elevated or otherwise, depending on which scenario you want to test), and run something like this: setup.exe /debuglog /v"/l*v c:\users\me\desktop\setup.log"
I have setup created with InstallShield 2015 Basic MSI.
Let’s say in this setup user can choose if he want to install Client or Server,
for each setup type ( Client or Server ) there are several features he can choose to install.
Now user choose to install Client setup and included 2 features under it,
If he run the setup again with UI he will enter the maintenance mode enable him to add more feature belong to Client.
My problem is that he can also run same setup again from command line (msiexec /I) and try to install the Server setup type, currently setup doesn’t block or prevent it and this may cause corruption of Client setup he already have installed.
So, I guess I should write a CA that will check if current setup is installed and check what action user is trying to run from command line and if it’s not uninstall block it ( still need to support running uninstall from command line ).
Is this logic correct? How can I know what is the command user run from command line? meaning that he run msiexec /I and not trying to uninstall from command line.
I wonder if there an InstallShield\MSI build in way \ property to prevent installing same MSI twice from command line ?
I'm having a hard time understanding you. I hope my answer is aligned with your needs.
When you first run the MSI it's in installation mode. When you run it again it's a maintenance mode. Depending on how you authored your installer, you should get a dialog with Repair, Change or Remove buttons. The Change button can be used to allow the user to add additional features or remove features. This can all be done from the command line as well using the ADDLOCAL and REMOVE properties. There properties take a , delimited list of feature names.
One place people make a mistake is using the conditions Not Installed | REMOVE="ALL" on their custom actions. This doesn't take into consideration the fact that you might have multiple features and come back during maintenance mode and reconfigure the application. MSI has feature and component installation and action state evaluators that can be used in conditions that are better suited for this job.
Update:
I would write a Type 19 error custom action that blocks the installation if the user is requesting a two conflicting features to be installed or the user is requesting one feature to be installed that conflicts with another feature that is installed. Use the feature request and installed state operators in your conditional expressions and schedule it after CostFinalize.
I am using windows installer to create setup project.
How I can remove/delete application files from AppData\Roaming folder when application uninstalled.
I tried added a special folder and set DefaultLocaltion to [AppDataFolder] but it didn't working.
Do I need to do anything else?
I'd need to understand what you are trying to do to give you specific advice. In general what you are trying to do would be OK removing files from CommonAppDataFolder but not AppDataFolder as trying to clanup user data from multiple user profiles is not a best practice. Additionally trying to cleanup Roaming Profile User data is outright impossible because the other users aren't logged on.
You'll want to read:
Managing Roaming User Data Deployment Guide
Assuming you are trying to do what I think you are, you'll need a cleanup script / exe that you leave behind on uninstall and a custom action to write to the registry during uninstall ( MSI can't do this natively ) to call that script/EXE. You'll want to leverage the Active Setup trick as described here:
Using Active Setup to Repair User Settings
The way it'll work is your uninstall leaves the EXE and registry entry behind so that when a user logs on it's roaming data gets pulled down from the server to local and Active Setup realizes it hasn't run the script yet. The script runs (once) and the data is deleted. When the user logs off the data is replicated / deleted on the server. Then they log on again it doesn't run again.
By default Windows Installer does not remove the files created by your application, after the installation. To do that you need to either write your own custom action, that will run upon uninstall, or depending on the tool used for authoring the MSI, you can use built-in options for cleaning the application locations, as some tools have this support.
I have a problem which I guessed would be really simple to solve... but duh.
I'm deploying a .NET application with VS2010. I have a C# Windows Forms project and a Deployment Project. I need the installer to run with admin privileges because the app is installed for all users and an entry to the registry is made.
When starting the setup.exe I'm not prompted for privilege elevation. The installer will just start and suggest to install to Program Files (x86) which is good. After clicking next the installer runs and finished with a success message. Which is basically a lie because it did not successfully install. Instead it puts the apps exe directly to C:\.
How can I make the installer ask for admin privileges. Or do I have to rely on my customer to right click the setup and select "Run as Admin" which is very error prone?
Clarifications about my setup:
In the File System view of the setup project I added (among other things) "Primary Output from project01 (Active)" and "Build Outputs from project01 (Active) to "Application Folder". I also added a shortcut to "Primary Output" into "User's Programs Menu\CompanyName\ProgramName".
In the Registry View I added an entry to HKEY_CLASSES_ROOT because I need to register an url handler.
I also modified the setup's settings: I set InstallAllUsers to True because it is supposed to do so.
When I build and start the setup.exe by double clicking (or by selecting Install from the project's context menu) I always get the same result: The installer runs without asking for admin privileges, ask for an install location (which I leave at the default C:\Program Files(x86)\Company\ProgramName) and then procedes after clicking Next. As a result, the exe is put directly in C:\ and the shortcut created of course points into Nirvana.
If I run the setup.exe manually as Administrator things work fine. But this cannot seriously be the way to go.
So how can I tell the setup to always run as Admin?
I think this is a perfectly valid question, is a real problem, and has an actual explanation.
I recently ran across this problem. In my case, the cause is that the AlwaysInstallElevated policy was set on the computer through GPO. The policy was set to 1 in the per-machine policy and 0 in the per-user policy. These policies can be manually set to reproduce the effect it has on MSI installers
Using msexec /log install.log /i Deploy.msi, I had a setup log and there were strings in it like this:
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property TARGETDIR
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETURLMSG
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETMSG
It seems that Visual Studio does not set the SecureCustomProperties in the MSI correctly and post processing of some sort is needed. I think that moving to WiX may be a better long term solution instead.
A blog post on MSDN is what I found that helped me find the root cause to this problem.
I've come across the same issue as you, and have found a good enough solution for it. So it might work for you too. The solution is documented here:
VS2010 Setup Project - Run As Administrator
I will re-iterate the solution briefly here. Basically, you need to manually edit the setup project file (.vdproj) and the following property to TRUE:
"MsiBootstrapper"
{
...
"RequiresElevation" = "11:TRUE"
}
When starting the setup.exe I'm not prompted for privilege elevation.
This is the normal behavior. The boostrapper doesn't need elevation.
Which is basically a lie because it did not successfully install.
Instead it puts the apps exe directly to C:.
So it did install your application, but in the wrong location. This is not related to elevation. In the File System editor in your setup project where did you add your application files? Did you add them in "Application Folder"?
How can I make the installer ask for admin privileges.
A MSI package installed for all users automatically prompts for elevation when clicking Install button. If it doesn't elevate automatically and installs in a per-machine location (like C:), the installation fails and nothing is copied on the target machine.