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
Related
I am trying to automate a build process for a C# (vs2008) solution.
The build script is written in a Batch script which I want to change. We use Clearcase as the CM system. I have searched some tools such as MSBUILD, NANT.
Any suggestions which is a better solution like a sample script in MSBUILD and NANT?
I have not seen any sites where MSBUILD and NANT is documented well or any good tutorial about each task description.
Where I can learn MSBUILD or NANT either of them and write script from scratch?
There is a third way which I prefer. You can also use devenv.com. It's faster than NANT, doesn't require NANT bins and works on any machine with VS installed. You also avoid possible errors with MSBUILD (http://support.microsoft.com/kb/964125).
Just use %path_to_devenv.com%\devenv.com "%path_to_sln" /<buildoption> BuildConfig
In my case it's
%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com "C:\Projects\XYZ\xyz.sln" /rebuild Debug
This way it's guaranteed that your project will be build exactly the same way as it's being built in Visual Studio.
EDIT:
Now that we know how how much there is to do, I'll try to give an outline how you can setup the whole system for automated build controll.
Set up your repository (I hope this is already done - tell me if not)
Install and set up Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins) including users, ClearCase-Credentials, plug-ins for ClearCase, MSBuild, etc. (all of them can be found in the Jenkins plug-in interface) - this is the biggest peace of work
Create and set up a new project in the jenkins interface (name, working directory, etc.)
Tell jenkins to use source code management (e.g. subversion module), enter the ClearCase repos to use, set the desired behavior of the source code management
Set a build trigger (I recommend checking the source code management each minute: * * * * *)
Add a build step and select "Build a Visual Studio project or solution using MSBuild" - this option should appear after installation of the MSBuild plugin (https://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin)
Set the path to the .sln file (you have checked it out from your repository)
Add more optional arguments if desired (eg /p:Configuration=Release or Debug or whatever http://msdn.microsoft.com/en-us/library/vstudio/ms164311%28v=vs.110%29.aspx)
Play around untill it works
Btw., I recommend to put all external dlls into your repository.
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.
I used to install Neo4j 2.0.0-M05 as windows service, this worked great. With 2.0.0-RC1 it doesn't any more.
Intro
With 2.0.0-RC1 I can download an installer. Seems that this installer does not have an option to install Neo4j as service. Also it doesn't let you set some directories (I like everything in C:\apache\neo4j); some stuff is being stored in my user directory. And it doesn't remember the location of the database. So that leaves the zip as only real alternative, though the zip file comes in only one version while the installer comes in 32bits and 64bits??
Anyway now trying with the zip package I have to run a .bat file just as before (i'm used to this). But when i try install, i get:
C:\apache\neo4j\bin>Neo4jInstaller.bat install
"WARNING: this installer is deprecated and may not be the optimal way to install Neo4j on your system."
"Please see the Neo4j Manual for up to date information on installing Neo4j."
Press any key to continue
Two things are weird.
It's the only option to install neo4j as service, so how can it be deprecated?
Press any key to continue only response to the enter key.
Problem
Continuing on the the real problem:
Press any key to continue
[SC] CreateService SUCCESS
[SC] StartService FAILED 87:
The parameter is incorrect.
Workaround
I removed the .bat files from 2.0.0-RC1 and copied the 2.0.0-M05 bat files over to the new version. It seems to start the new version without a problem.
Thanks for the feedback. There are open github issues related to much of this, which we'll clean up before going to GA. Even then, your conclusion is correct, that for now installation as a service requires downloading the .zip distribution. We'll make that more clear in the download page.
Generally, installation as a windows service is something we're working to improve. I'd love to chat with you a bit about your particular deployment scenario. Please drop me a line at andreas#neotechnology.com.
Best,
Andreas
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.
I'm currently rebuilding all our setup files (used to be .exe files) into MSI installers so that I can deploy them through Active Directory.
Basically, we have a tool (Windev for those who know it) that generates MSI files, but since our tool is limited, I generate .mst files (using Orca) to fine-tune the setup, and merge the source installer and the transform with msitran.exe. When I manually install the transformed setup file with /qb or /qn, the install works fine.
But when I try to add the setup file in the AD, I get an error message : "Unable to extract deployment information".
I found multiple solutions online, but none of them fit my problem (ie. I have all admin rights, my final MSI validates in Orca (with a couple warnings, but no errors). I get the same issue with the original MSI that our tool generates (but it doesn't validate in ORCA, hence the transform to fix that among other things).
Are there any properties that I need to set to successfully deploy my MSI to AD ?
Never mind, solution is plain stupid, but MS does not mention this anywhere.
Basically, it was an issue with the UNC path. My MSI was located in a path that contained whitespaces, and Windows Server 2003 apparently doesn't like that (wrapping the path in quotes in the open dialog does not change anything). Moving the files to a path without spaces fixed it.
Good day to all