I have a need to disable the disk space check on an MSI for deployment. I see where the FileCost options are in the MSI in ORCA, and am able to create a transform, but I constantly receive errors when running the MSI with transform.
How do I properly disable this?
Thank you
Related
My goal:
I want to create a CMD command that will installs a program with adjusted install settings.
If I execute my .exe install file without any parameters, I have to click myself through the installation but I am able to change the install settings, like in which folder the setup will install the program or change the status of a checkbox.
However, I want to run the installation in /silent mode, in which I don't know how to change the install settings.
So the question is:
Is there anyway to give the shell a correct installation settings and then execute the file in silent mode?
I need this because I have to run the installation on multiple computers so it would be very comfortable if I had a script that runs the installation with correct settings.
Someone please guide.
Community: I'll elaborate later, but first let us do the easiest way. You could try to search for your software on sites dedicated to setup information and how to deploy various third party software silently:
https://www.itninja.com/software
Similar, terser answer: Silent run installer (.exe) with parameters on Windows
1) Standard Packaging Formats: If the setup.exe wraps a standard packaging format such as an MSI file, then you generally need to find a way to extract the package inside and customize its silent installation using standardized customization mechanisms involving command lines and MSI transforms.
2) Proprietary Packaging Formats: If the setup.exe is a proprietary format you need to either repackage it in a standard format (MSI) using tools to do so, or you need to run the installer in silent mode. The latter can be unreliable, but is often done for small scale distribution.
Look and Feel: Experience can teach you what tool was used to make the setup.exe by looking at the dialogs at runtime. Sometimes you see a company name or a tool name embedded in them.
So in summary:
Extract standard package if possible.
Customize standard package.
Repackage.
Install silently using original setup.exe.
Let's briefly describe these different tasks:
Extraction of Files:
There is a forest of tools that can create setup.exe files, it is impossible to cover all of them. They might feature all kinds of different command line switches. A setup.exe can even be totally proprietary, meaning no deployment tool was used to make it at all. It might have been compiled using Visual Studio for example.
A description of tools that can be used (non-MSI, MSI, admin-tools, multi-platform, etc...).
Common tools such as Inno Setup seem to make extraction hard (unofficial unpacker, not tried by me, run by virustotal). Whereas NSIS seems to use regular archives that standard archive software such as 7-Zip can open.
I try the following command lines to see if I can do a file extract:
setup.exe /a (Installshield MSI)
setup.exe /stage_only (Installshield Suite)
setup.exe /x (Wise, Advanced Installer)
setup.exe /extract_all (Installshield Installscript)
dark.exe -x outputfolder Setup.exe (WiX Burn Bundles - requires WiX toolkit installed)
Additionally some general tricks exist:
Launch the setup.exe and look in the system's temp folder for extracted files.
Another trick is to use 7-Zip, WinRAR, WinZip or similar archive tools to see if they can read the setup.exe format.
Some claim success by opening the setup.exe in Visual Studio. Not a technique I use.
The general approach for finding switches is to open a command prompt and go setup.exe /? or setup.exe /help or similar.
Also check for vendor online information and sites such as https://www.itninja.com/software.
A sprawling answer on this topic: Extract MSI from EXE.
If you manage to extract (or the file format is viewable as an archive), you can look for PDF, HTML, TXT or CHM files with further deployment info. Samples: ReadMe.txt, LSD.pdf, Large Scale Deployment.pdf, User Guide.chm, Manual.chm etc...
MSI - Customize Standard Package:
So, if the extract works and you extract an MSI file, then you can customize its installation in detail using standardized mechanisms. Make sure to look for the files with deployment information mentioned above - PDFs, CHMs, TXTs, etc... They could feature sample command lines for you to use more or less directly.
And crucially you could have extracted runtimes and prerequisites that also need to be deployed (.NET framework, Crystal Reports, Visual C++ Runtime, etc...). These are all managed and controlled on corporate networks and are not to be deployed with your package, but by their standardized packages.
Standardized customization mechanisms are great for corporate deployment, but require some MSI knowledge:
How to make better use of MSI files - a comprehensive description of MSI installation customization: with some sample command lines and description of the process.
A simplified view of MSI installation customization.
Here you can see that some setup.exe files can be installed directly in silent mode by passing in a command line using the /v parameter. These are Installshield MSI setups.
You can also see how the features in the MSI can be set at the command line.
A couple of concrete samples (extracted from links above):
Command Line Customization
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
ADDLOCAL specifies what features from the MSI to install (see feature sample screenshot here). The uppercase values such as SERIALKEY are PUBLIC properties that can be set on the command line. These vary from setup to setup. Look for documentation from vendor, check the Property table and check the setup dialogs.
Transform
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
The transform approach sets all the values needed inside a little file that is applied at installation time. It is called the transform. It is a little database fragment which is merged with the original MSI database at runtime.
Repackaging:
One way to create an MSI package from older-style, legacy setup.exe installers, is to "capture" the changes done to the system by using an Application Repackaging Tool which monitors changes made to the system whilst a setup.exe is being run.
This task may look easy, but it isn't. In fact it is very hard to clean up the resulting captures so you don't create "loose cannon" MSI files that cause problems on desktops throughout your organization. Corporations have dedicated teams to do this job and excellent MSI files can result that cause no problems when installed silently.
This task is not for the causal user in my opinion. It requires investment in the technology, expertise and time. Besides the tools available are pricey.
Silent Installation:
Most setup.exe files will at least attempt to install silently, though there are no guarantees. It is entirely possible that the setup.exe is impossible to install silently. I have seen it many times. In these cases repackaging is necessary, but even repackaging can fail at times. This is when it is time to push back on the vendor and ask them to get a grip about deployment. In a corporate world the software should be kicked head-first out of the application estate - if things work as they should.
Here is an old site dealing with the overall issue of silent installation of various setup.exe files: http://unattended.sourceforge.net/installers.php.
Here is a piece on silent uninstall which also describes silent running in general: Uninstall and Install App on my Computer silently
The general approach for finding such switches is to go setup.exe /? like you did. Often you can get a setup to install silently by trying something like this:
Visit https://www.itninja.com/software to check for switches from the community.
As stated above look for PDF, HTML, TXT or CHM files with further deployment info. Samples: ReadMe.txt, LSD.pdf, Large Scale Deployment.pdf, User Guide.chm, Manual.chm, etc...
Common: setup.exe /S, setup.exe /Q, setup.exe /quiet, setup.exe /VERYSILENT /NORESTART or similar.
Old-style Installshield setups need to have a response file recorded and then you install on all systems using the recorded dialog responses.
See this document.
Setup.exe /s /f1”c:\temp\my-answer-file.iss” /f2”c:\temp\my-log-file.iss”
Installshield Suites and regular Installshield setup.exe (links to Installshield's own help pages for setup.exe files)
Old Wise setups: https://www.itninja.com/blog/view/wise-setup-exe-switches
Some Links:
Create MSI from extracted setup files
MSI Deployment Tools List
Extract MSI from EXE
https://www.itninja.com/software
Uninstall and Install App on my Computer silently
Combine exe and msi file in one installer
How can I use powershell to run through an installer?
How to Install an NSIS Executable Silently For All Users
I'm testing the compatibility of two products (A) and (B) within a TestAutomation project. The test verifies that product (B), which is actually the product under test, can be installed eventhough (A) is already installed --> to do so, the installer of (B) looks up if the UpgradeCode of (A) is present.
NOTE: I already know the UpgradeCode of (A). What I'm trying to do is to write it into the table that will be looked-up upon installing (B), WITHOUT actually installing the MSI of (A) - this is kind of like a "mock" in integration-testing.
The test is running on a VM where (A) is not already installed by default. My goal would be to write a script which would allow me to skip the "real" installation of (A).
QUESTIONS:
I'm not sure of where it looks the UpgradeCode up. It is NOT looking it up in the registries (I aready tried that hack). I have found the UpgradeCode within the Win32_Property table... is that the right place to look into?
My guess is that I have to emulate the API-call, with which the original MSI from (A) sets its UpgradeCode... any idea of how that works? Possibly with a Powershell script. I have seen online people modifying the WMI properties tables can with calls to gwmi (then using put) or swmi, but all my attempts so far failed.
NOTES:
I do not really know my way around with the Windows Installer nor with PowerShell... this is not at all what I usually do. An answer in Layman terms would be much appreciated.
I know that there are other ways around this (e.g. a dedicated VM or performing a "real" installation of (A)), but I'd like to know how to achieve this programmatically.
Why I need to do that? It's an automated test that only concerns the installer of (B). I do not want the success of my test to be depending from (A)'s successfull download or installation.
The easiest way to do a test without installing the actual A would be to produce a small MSI with the same UpgradeCode and ProductCode and install it. I can't see why you want to "fake" it when you can just do the real thing.
If you want to prevent the install of B when A is already installed you could add A's UpgradeCode to B with OnlyDetect=yes, that will set a property that can be used to prevent B from being installed. It's not clear what the context is for not installing B, whether you have external launchers, a bootstrapper, or which tool is being used to generate the MSI (because some tools will give you help if you want to skip B if A is installed with their built-in detection features).
You can get the UpgradeCode via WMI (Win32_Property WMI table) or via MSI API (Windows Installer Database - registry).
I would not hack the upgrade code in the Windows Installer Database for any reason. Why do you need to fake the UpgradeCode? Is the install of product A very large?
WMI / PowerShell / VBScript:
How can I find the Upgrade Code for an installed MSI file?
WMI is very slow to use, and can cause side effects such as self-repairs and in certain cases spam the event log with error messages. See the Disclaimer section here.
MSI API:
You can use MSI API COM calls (VBScript, Javascript, etc...) or MSI API Win32 calls (C++).
Here is a hacky way of getting the Upgradecode via
a session object using VBScript. I am not sure what side-effects - if any - result from spinning up many session objects: Is MsiOpenProduct the correct way to read properties from an installed product?
I have need to automate (non interactive) installation of RHEV with out PXE. I have gone through the RHEV installation documentation. But did not find any way.
Please suggest if there is any way to achieve this.
-Thank you
if you don't want to use PXE, I think your only option is
prepare an image with all required RPMs already installed
prepare an answer file
On the host you're provisioning for running RHEV:
clone the image on the disk
fix hostname as needed for avoiding duplicates
run engine-setup --config-append=answerfile
I have a program that imports .reg file to registry on button click.
The program imports as well as I run it from code, but when I create an MSI installer and run it, the .reg file does not get imported.
The reason is probably the permissions of the MSI installer.
How can I set full permissions to the installer, so that it could access and import to registry?
Probably best if you make it a deferred Custom Action with Impersonate on No. (This means it will run elevated). But I have to warn you, running a .reg file is really not the way to go. Harvest the keys with Heat.exe for example.
There is a security problem that forbids a program that sits in Program Files, to import files to registry.
Therefore, I create an MSI installer that asks the user where to install the program, and then the import is done without security limits.
I am working on a project where we need to repeat certain steps with powershell to deploy stuff. i would like to create a process/install guidance (steps supported with UI) with WIX but after the msi has finished i have an entry in programs and features. I just need it to execute the powershell and the end without registering in windows. i might be using the wrong tooling or whatever, any suggestions are welcome.
Definitely not recommended unless you want to track the deployment of these scripts on different systems by checking the entries in ARP (Add/Remove Programs), and even then it clogs up the Add/Remove view of your computers. Most system administrators hate this approach, it is better to just write to your own registry key and read it back from every machine.
What are the scripts doing? Are you actually installing files.