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"
Related
I am trying to install a installer developed using InstallShield 2008. While installing after selecting the destination path i am aborting the installation.
When i try to install again by default it is taking the destination path as previously given path which was provided before aborting the installation.
And also it is not allowing me to install in different path.
For Example:
*Step1 : Installation starts
Step2: Destination path as C:\Installer
Step3: Click next and abort installation
Step4: Start the installation again
Step5: Provide Different destination path as C:\Installer1*
Here installation is failed. Because destination is still pointing to Step2
My question is from where Installer is taking the old path.?
Persisted Path: The technicalities appear to be relatively straightforward: the old path is read back either from the registry or from disk each time the setup is launched, and a custom action in the setup's GUI sequence must have persisted the path "somewhere" during the first run (this is erroneous design, see technical comment below). Reading back the value can be done by using AppSearch (built-in MSI feature) or by means of a custom action.
Registry / Disk: As to finding where the value is read from. The easiest would be to just search the registry first for the literal path. Just open regedit.exe and search for the path there. You can also look for the custom action that does the persisting (or the AppSearch or custom action that does the retrieval) and see if it is a script with code you can see - then you should be able to see where it has persisted the path. Use Orca or a similar tool to view the Custom Action table. The custom action can also be compiled and undecipherable. Do you have the setup source? The path can also be persisted to disk, but the registry is most commonly used. Remember to search both HKCU and HKLM.
Involved Debugging: I can't see why you would, but it is also possible to use ProcMon.exe to monitor what registry locations your MSI reads and / or writes to. This is involved debugging and should never be needed for something this simple. Just mentioning it as a technical option. Generally the last resort we have to figure out the strangest problems.
Technical Comment: MSI setups are not supposed to write anything to the registry or disk from the setup's user interface sequence (setup dialogs). All changes should be made from the installation sequence (InstallExecuteSequence) which also generally runs with elevated rights - the user interface normally runs with user rights. This InstallExecuteSequence sequence is kicked off from the last dialog in the GUI sequence, and runs the file copy and system change operations. Control then returns to the GUI sequence to show the setup complete dialogs. It is also possible to run the setup silently, in which case the InstallUISequence never runs and all custom actions inserted there fail to run. Accordingly custom actions should be present in the InstallExecuteSequence as well as the InstallUISequence if they are to run in silent mode. This potential design flaw is a very common silent deployment error which occurs when setups are not designed properly for silent running. Remember that all corporate deployment runs silently. Setup GUI is highly overrated (in my opinion - a "fact" that could change in the future).
It is still possible for an MSI setup to write to the registry or disk from the InstallUISequence by using a custom action to do so. Such a custom action would normally not have access to write to HKLM or to protected parts of the disk - unless the whole setup runs elevated because it was launched from an elevated command prompt (for example), or launched by an admin who elevates it via the UAC prompt.
In other words: this setup is badly designed, but I guess that is clear already.
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'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.
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.
Suppose you have an MSI that's trying to add or replace file Foo.bar, and that operation fails. If Foo.bar is marked as vital (with msidbFileAttributesVital) in the File table of the MSI, then the installation will roll back. If the file is not vital, then the user is prompted and allowed to decide if the error should be ignored or if the installation should be rolled back.
What if the operation fails and the installer is running in silent mode (/qn)? The user cannot be prompted.
It appears (from an MSI log I have) that the installation rolls back, even though the file is not vital. Is there some way to have a silent install proceed in this case?
From my knowledge silent installations always rollback if an error is encountered, no matter what flags and settings you use. This prevents broken installations (for example missing files).
In your case a solution is to use basic UI to prompt the user. Another solution is to use a non-MSI installer which can ignore installation errors.