I have windows InstallShield Executable (.exe) without source files. This installer works in an interactive (GUI) manner. After installation, I can see the registry entry and entry in services.msc. Now there is a requirement to change it to silent installation for automation.
I have converted that InstallShield exe to msi using some extract options.
When I tried to install this MSI in silent manner using msiexec.exe, installation went fine but it was not adding those registry entry and services.msc entry,
This is the command I have used with admin user login via cmd prompt,
msiexec.exe /i app.msi /qn
Am I missing some thing here ?
NOTE - The problem here is I don't have the source for the InstallShield build just the executable alone.
I have seen additional properties like ALLUSERS and INSTALLLEVEL. Are there something else I need to add on this ?
I am trying this on Windows Server 2012 R2.
Sometimes an MSI performs custom actions after InstallFinalize in the InstallExecuteSequence. This is an error in design and can cause a silent install to fail since it never reaches these custom actions (installation ends at InstallFinalize). This is unlike an interactive run which will execute the custom actions after InstallFinalize before passing control back to the GUI sequence. It is also possible that custom actions are defined only in the GUI sequence causing them to never be run during a silent install - another error in design which isn't that uncommon.
Can you check with Orca or another tool whether there are custom actions after InstallFinalize in the InstallExecuteSequence? The bad news is that there is no good fix for this error, but you can try to run the installation by only showing a progress bar and see if this causes the custom action to be run:
msiexec.exe /i app.msi /qb-
This runs basic UI with no modal dialog boxes. Effectively a semi-silent setup. If this fails to try to run /qb instead of /qb-. The idea is to see if this executes the missing custom action by running with a minimal GUI so that the GUI sequence is run.
Finally, as Bogdan points out it is possible for the wrapper exe that you extracted the MSI from to contain additional installation logic that fails to run when you run the MSI alone.
Related
I have a visual studio setup project creating a setup.msi. I have some custom actions running during and after an installation.
When I execute the command msiexec.exe /a setup.msi /qn to upgrade an existing installation, the custom actions are not firing. It seems that the option /a (administrative execution) is bypassing the custom actions.
Any idea ?
Thank you in advance.
Administative installation runs in its own sequence inside the MSI. Hence you can actually insert custom actions there (though I would not recommend it), and they will run only during administrative installations.
You would need to insert these custom action in the normal installation sequence (as well) for them to ever run during normal installation (InstallExecuteSequence and / or InstallUISequence).
Normal Install:
InstallExecuteSequence
InstallUISequence
Administrative Install:
AdminExecuteSequence
AdminUISequence
Advertisement: There is also the advertisement sequence. This sequence uses the: AdvtUISequence and AdvtExecuteSequence tables. Advertisement is when you register the MSI package for installation later. Installation can be triggered by the user or via Add / Remove programs or via an application. Install-on-demand. Rarely used these days it seems (the main reason is probably the technical glitches and operational problems people face when trying to use it).
File Extraction: Administrative installation is essentially a glorified file extraction (equivalent to an unzip). It extracts all files, adjusts the media table to use external files and a few other things. It is basically intended to create an installation media to put on a networks share and also to allow the content of the MSI to be inspected. There is also the ability of MSI to "run feature from source" - which I have honestly never seen used successfully.
Note!: Though rather trivial, administrative installations are crucial for corporate packaging and the "transparency" of the MSI installation technology. This transparency is one of the key benefits of the MSI technology (list slightly down the page). Make sure that your MSI works properly during administrative installations. I think there is a bug in some WiX GUI-sets for example. There is a trick to make them work still by suppressing the GUI. Something like this: msiexec.exe /a MySetup.msi TARGETDIR=D:\ExtractHere /qn
What do you need the custom action to do during administrative installation?
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.
How can I sync the command line to the setup project installer that it will not proceed until the task of the command line is done?
The installer needs to run BATCH scripts and it needs to log on to the database credentials. But even before logging on to the database, the installer still proceeds and finish the installation process.
You could give a bit more context, but in general the answer is don't use bat files. You could have a custom action VB script that runs the external executeables (if that's what they are) and waits for them to finish. In general, whenever bat files show up during an install it's a red flag that something isn't right in the design. Usernames can be entered in UI dialogs at the front, for example, and passed to custom action programs; also many clients like silent installs where property values (like a username) can be passed on the msiexec command line and again get passed into a custom action, and it all just works - I suspect your install cannot be run silently because you are collecting a user name at the end of the install in a custom action.
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.