Ok, I'm out of my element but here goes anyway.
I need to do a silent install of a vendor supplied windows program. The vendor supplied an MSI file to use with the install. I created a bat file to run msiexec that contains the following line:
msiexec /i "C:\archibussilent\afm\ARCHIBUS 19.msi" /L*V C:\archibussilent\log\msi_SETUP.log
When I execute the bat file an error dialog pops up that says:
"This installation cannot be run by directly launching the MSI package. You must run setup.exe"
and the msiexe error log says:
MSI (c) (80:B0) [15:48:02:588]: Note: 1: 1729
MSI (c) (80:B0) [15:48:02:589]: Product: ARCHIBUS 19 -- Configuration failed.
MSI (c) (80:B0) [15:48:02:590]: Windows Installer reconfigured the product. Product Name: ARCHIBUS 19. Product Version: 19.3.30032.003. Product Language: 1033. Manufacturer: ARCHIBUS, Inc.. Reconfiguration success or error status: 1603.
The error # is 1603 which implies a permissions problem but I've checked the access privileges and don't see any problem.
Is it true that I can't run msiexe without running Setup.exe?
Any help is appreciated - Thanks.
The "you must run setup.exe" is a vendor authored requirement not specific to MSI in general. They may have had a good reason for it or they may have just authored it as a gate check to not have to test other scenarios.
You'll have to edit the MSI with ORCA and look at the LaunchCondition and InstallExecuteSequence tables to figure out how they implemented. Then you can create a transform to bypass the check or possible pass a property in such as SETUPEXEDRIVEN=1 to simulate being called from setup.exe. (One particularly large and well known installer development product passes this into their MSI when you create a setup.exe with it.)
The setup.exe may be serving a purpose. For example it might be authored with a manifest requiring elevation or it might be downloading and installing prerequisites or possible making sure the MSI is cached in a given location for future installation transactions.
Also I assume you want to add a /QB or /QN to make the install go silent. You'll like also need to have already elevated the cmd session prior to calling since MSI doesn't support UAC prompts when installing silently.
This is most likely an Installscript MSI file made using Installshield. This is a non-standard MSI file featuring more advanced GUI and a few other advantages. In my opinion this is a particularly problematic type of setup due to a few serious bugs without suitable workarounds. I consistently recommend this project type to never be used. It is especially problematic for corporate deployment.
These setups feature a number of command line parameters for the setup.exe file. As Chris states you can probably run it via a transform and set the property SETUPEXEDRIVEN=1 and you may try to use setup.exe /a to run an admin install (More info: purpose of an admin install). This will extract all cab files (if any) from the MSI and put the files on a "network installation location" for use in corporate networks - essentially a smaller MSI with the setup files next to it. I have seen setups that then will allow to be run directly from the MSI - just give that a shot too.
As to the reason why these setups require setup.exe to launch:
In prior editions of Installshield the Installscript language runtime had to be installed prior to launching an Installscript based MSI. This appears to no longer be the case since Installscript is now run without a runtime.
The setup.exe is there to install any updates to the Windows Installer Engine (msiexec.exe), and for that to be possible a setup.exe launcher is needed. Such an update is rarely required, and should today be done via Windows Update.
A number of legacy features, such as being able to access the Internet (!) via the setup.exe (highly undesirable for corporate use), download runtimes and components and extract temporary files are also done via the setup.exe.
And there are other features too, most of which are undesirable for corporate deployment.
Here is a previous answer from me on a similar issue featuring a link to a PDF with actual sample command lines.
Related
On WPF installer project build generates setup.exe and it is being signed using Signtool on PostBuldEvent. It does show Publisher as unknown on UAC popup at the very last step of setup.exe.
Can someone help me to fix this ?
MSI vs Setup.exe: You should sign the MSI file as well as the Setup.exe file.
Certificate Type: What kind of certificate are you using? I believe you need a digital code-signing certificate from a recognized issuing authority (DigiCert, Thawte, etc...).
EV-code signing certificate (please visit this link).
Why do I still see publisher unknown with the UAC prompt?
Get a code signing certificate
Signtool.exe: If you have a valid certificate, are you using the /d option to the command line of signtool.exe when signing your MSI?:
signtool.exe /d "Your Software Name"
How to add publisher in Installshield 2018
Trust Yet Verify: When you have signed the file, right click it and select "Properties" to make sure the file is actually successfully signed. Look for the tab "Digital Signatures" (or equivalent in your own language):
Administrative Installation: Sometimes people forget that they have run an MSI through an administrative installation. This is essentially a file extract from the MSI resulting in a new MSI without the embedded CABs in the output location (more). This extracted MSI will not be signed - even if the original MSI was signed. This extracted source is used in many companies to keep the installation files on a networks share available for repair and inspection (and during application packaging to inspect the package content - and other purposes).
Post-Processing MSI: This is actually a very common issue: you must never touch a file that has been digitally signed. If you edit it after the signature has been applied this invalidates the signature. The whole point of digital signatures is to verify that the file you look at is the one that was signed by the vendor. In other words that the file has not been changed in transit to you (tampering, malware infection, etc...). More on this important issue here (attempted humor in there). Note that the tampering might happen via automation scripts and not by manual editing, hence one must always check for this cause.
Other Issues: There are also some other possibilities. The signed file could be corrupted during download or from malware attack and such things. Far beyond the question, but just mentioned for whoever might find this.
Links:
Is it possible to define a Windows Installer-uninstaller filename?
Installshield Custom Dialogue Installer
How can i generate windows certificate so my msi doesn't shows warning to users
Further Links:
Windows printscreen not working on Software Installation
WIX-Installer MSI Publisher Unknown
Everything you need to know about Authenticode Code Signing
I have some setup.exe based on NSIS. It setup.exe installs plugin. Setup.exe does some simple actions: allow user to choose application folder then registry and some files on filesystem then copy plugin file in some user folder. My problem: virustotal shows some warnings but plugin is good. Plugin file upload to virustotal doesn't show any warnings.
So I want to replace NSIS with something else. Currently I think to write own setup.exe on WinAPI without any extra tools/libraries. But doesn't know how to mix setup.exe with actual data files which must copied? Or maybe there is another way to make setup.exe good for Virustotal?
There are multiple options available for creating installers and outlined by Microsoft in their application deployment guide. You can use ClickOnce, InstallShield, MSI or MSIX.
If the false positives don't go away and 1-2 false positives are unacceptable to you, then you should get a code signing certificate and sign your installer. If the false positives don't go away you need to contact the antivirus vendors and report the false positive.
I am trying to install DB2 ibm data server client(version 11.1), silent install in my windows server. i am using response file for the installation. I gave the path in response file to install in D drive, but still it is installing in C drive only. the command i was using is: msiexec /i "MSI path" /q /l*v "log file path" RSP_FILE_PATH="response file path".
Check the following:
Installing Db2 products and features using a response
Some notes on MSI customization in general below.
And a link to the most commonly used library of packaging tips contributed by packagers:
https://www.itninja.com/software-library/company/ibm
Different Designs: The exact mechanism used to redirect a folder like that depends on the design of the application and the setup from the vendor, they often do something very non-standard so reverse engineering their solution fully or slightly is usually neccessary.
Itninja.com: Maybe have a look if you can find the software here in the itninja.com "software tips" section: https://www.itninja.com/software-library/company/ibm - this is a collection of comments people have made who have packaged and deployed the software in question - either unsuccessfully or successfully. I can't really tell what the exact product name is, please check.
Download: If you have a download link that is publicly accessible I can have a quick look at the MSI to determine how it is set up. Please be aware that it is much better to install an MSI directly via normal configuration mechanisms (setting public properties and / or creating a transform - sample here) than to run a setup.exe with response file (which sometimes is the only possibility depending on the overall deployment design).
How to make better use of MSI files
A couple of quick overviews:
How to parameterize msi file from electron builder
MSI Repackaging - free tool
And some further links for reference:
Change the value of a MSI property loaded from a DLL using a MSI transform
How to run an installation in /silent mode with adjusted settings
I have a simple Windows Form application(WPF) with entity framework. After compiled, only a few files generated:
EntityFramework.dll
EntityFramework.xml
MyApp.exe
MyApp.application
MyApp.exe.config
...
Then I just copy following files to a network shared folder:
EntityFramework.dll
MyApp.exe
MyApp.exe.config
Then I can double click on MyApp.exe from developer computer the launch the app, but can not launch from another end user computer.
How to resolve this problem?
When you double click, app is not launching means certainly it is crashing so type the command eventvwr in run or cmd it'll open the Event viewer in that go to Windows Logs and Click on Application, you can see different levels of logs in that just find the last error log view the details it might help you
Have a look in the event log on the target computer and look at the error that is actually being reported.
It could be a missing installation of the correct version of the DotNet framework as suggested in the comments above, or it could also be that the execution policy of the target computer is preventing the user from running from a network drive (As a developer you probably have admin rights on your local pc allowing you to do this).
Whatever the actual cause you are always better to use some form of installer, rather than this form of putting files on the network (commonly known as xcopy deployment).
Probably the best solution is to use Visual studio to generate you a click once installer and publish it to your network drive. This will then copy the application locally on the users pc and run it from there.
For Linux packages, specifically RPMs with stored checksums, we always can check two things: the contents of package is ok and the installation from this package is ok. When someone modifies parts of the installation he shouldn't, we can see it by running rpm -Vp my-precious-package. In our busyness it is not only recommended, but obligatory to provide our packages with tools for this purpose and for Linux these are just simple bash scripts.
Now I have to do something similar for Windows. Basically what I want is to provide some batch file by running which one can get assured, the installation is the same as it meant to be in the package. I'm using InstallShield for packaging, and yet it has some great visual tools, I still haven't found a way to verify package checksums in the command line.
Is it even possible, or should I reinvent the wheel writing my own checking utils?
Take a look at MakeCat and SignTool from Microsoft, both in SDK
http://msdn.microsoft.com/en-us/library/windows/desktop/aa386967%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx
Windows Installer has a feature called resiliency that supports auto repair of products and there are ways to call it for self checks only. (This is assuming by InstallShield you mean Windows Installer based projects.)
Here's a couple links to read to get you started:
INFO: Description of Resiliency in Windows Installer
Resiliency
Application Resiliency: Unlock the Hidden Features of Windows Installer
MsiProvideComponent function (See dwInstallMode flags)
This also assumes all files are key files. Companion files are not managed by the installer. Also changes performed by custom actions outside of the installer aren't managed.