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.
Related
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 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 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.
I have an installer from a third party. Through trial and error I discovered it was an innosetup installer. When I call it with the /silent flag it installs just fine, until it executes installers for 3 dependencies (direct X is one, for example) which then require user input to cancel. I want to be able to run the installer and have it either install the dependencies silently or not at all. When going through the installer GUI normally it does give me 3 checkboxes at the end on the last page of the wizard (before I would hit the Finish button) that allows me to choose whether or not to install the dependencies. Is there a way of doing this that I don't know about? From my research it seems impossible without knowing the types and components available (and executing the installer with the /help or /? options had no effect) and I will probably need to get a new installer from the third party. The only other option I can think of would be to have some sort of timeout that after a certain period of time of inactivity from the installer I kill the install process (since the files I was interested in had already been installed at that point I think).
Checkboxes on the finish page sound like postinstall [Run] entries. There is no way to influence the selection of these from the command line, except that the original setup author can choose to have a different set of options selected for interactive install vs. silent install. (Or they might have extended the /LOADINF option to work with these, although this is unlikely.)
Given that this is a third-party installer, your best bet is to contact the original vendor and see if you can get them to change the default silent selection, or to add an additional command-line parameter to change the defaults.
Failing that, you could consider using a program such as AutoIt to auto-click the wizard GUI when run non-silently.
(If the things that it's trying to install really are dependencies, though, then you probably should let it install them. And it should be installing those silently too anyway.)
Killing the install process after a specified time seems like an excellent recipe for disaster.
Those are probably [Tasks] within InnoSetup's install, which you may be able to deselect by passing /tasks="" in the command line (along with the /silent). Here is a list of command line options: http://www.jrsoftware.org/ishelp/topic_setupcmdline.htm . Adding /suppressmsgboxes may help also.
It seems it is impossible to do what I wish without knowing more about the structure of their setup. I was however successful in solving my original problem by killing the third party installer after waiting a specified amount of time (which I got from reading this question).