I'm trying to install a IBM WebSphere MQ Client v8.0.0.3 on a Windows 7 SP 1 Enterprise machine, however I fail.
The installation starts, I select the language, splash comes on and after a bit the splash goes away and I'm left with a "Installation Wizard was interrupted", even though I click nothing.
I run it as administrator, and am a member of the local administrators group.
The installation log: https://gist.github.com/anonymous/a1ff7efe58fe7c006297
Edit:
A colleague with the appropriate mqm rights tried to install it, but failed also.
Everyone else here uses Windows server 2008 SP1 enterprise and have no problem with the installation.
Edit2:
It seems that the error is coming because of our directory structure:
Error 1327.Invalid Drive: H:\
We have our local settings, including appsettings on a server, instead of on the local machine, and the installer doesn't like it. JDK gives the same error.
There are many ways for a Windows MQ install to fail. In a Windows environment one of the frequent reasons is that even though the ID performing the install is an administrator, it doesn't have the correct domain rights. These include, for example, to query the SAM on the Domain Controller.
Please see Configure IBM MQ accounts for instructions on how to configure the service account under which MQ will run. Obviously, the account performing the install must have a superset of the same rights. Since the question fails to mention this critical pre-req step, I'm assuming it hasn't been performed.
It is possible that prior installations or a failed install will leave artifacts on the server which interfere with subsequent installations. This is especially true when installing V8.0. Since there is at least one failed install in this case, I would recommend using the IBM provided cleanup tool as described in Spring Cleaning a Windows MQ Installation. This will remove old registry entries and directories that alter the behavior of the installer.
Branching out a bit further, the 1603 error from MSIEXEC is pretty generic. According to the good folks at MSIGEEK, the following are some common causes for that error:
Short file name creation is disabled on the target machine.
An Install Script custom action is prototyped incorrectly.
A file is locked and cannot be overwritten.
The Microsoft Windows Installer Service is not installed correctly.
The Windows Temp folders are full.
The full article on debugging 1603 errors is here.
In this specific case, it appears one or more WMQ product prerequisites is not installed:
MSI (c) (5C:B4) [15:31:48:820]: Doing action: iwiListProductPrereqs
Action 15:31:48: iwiListProductPrereqs. Listing the product prerequisites
Action start 15:31:48: iwiListProductPrereqs.
MSI (c) (5C:84) [15:31:48:826]: Invoking remote custom action. DLL: C:\Users\ga2svit\AppData\Local\Temp\MSI7642.tmp, Entrypoint: iwiListProductPrereqs
1: 15:31:48 MQCA (CaProlog)(CaProlog) info: amqiwicn.dll Built on Jun 15 2015 at 23:18:37; version 8.0.0.3, build p800-003-150615.2
1: 15:31:48 MQCA (CaProlog)(CaProlog) info: Property 'ProductName' value 'IBM WebSphere MQ' from property table
1: 15:31:48 MQCA (CaProlog)(CaProlog) info: Property 'AMQEXTCA60000' not defined in property table
1: 15:31:48 MQCA (CaProlog)(WhatMode) info: User name is 'ga2svit'
1: 15:31:48 MQCA (CaProlog)(WhatMode) info: MSIRUNMODE_ROLLBACKENABLED
1: 15:31:48 MQCA iwiListProductPrereqs(iwiListProductPrereqs) info: Property 'VersionNT' value '601' from property table
CustomAction iwiListProductPrereqs returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 15:31:48: iwiListProductPrereqs. Return value 3.
Everything T-Rob has said is valid and correct, however for this specific case, this feels like one you need to take up with IBM as a defect.
I've been looking through the source of the place you are failing and there is no valid codepath I can see from the last line you have traced before a subsequent line which would say something like "MMC prereq satisfied" (or not satisfied, or querying a property, but it would say something). This implies to me we have hit an unhandled exception in the code and hence aborted straight out. You could try a silent install to see if that helps, but I wouldnt hold out much hope.
So for me the thing it seems to be trying to do is to look in the system directory for mmc.exe - Does that exist on your system and if so look at its properties and what is the version of that file (right mouse in explorer, properties and find the one listing the file properties)
We saw this problem with the V8 MQ installer. I had Offline Files disabled on my Windows 7 box, and a coworker did not. He disabled Offline Files, rebooted, and the installer succeeded.
I have also encountered this error and upon further investigation I realized that (using the MQParms_silent.ini file) I had forgotten to un-comment the AGREETOLICENSE="yes" from the provided default.
Hope that helps.
Related
We made some changes to the installation and updating process of our Windows app recently, and some users are now complaining that Windows sometimes automatically deletes the main application .exe file.
It usually occurs after users update app using built-in web update feature. The feature is implemented using .msi built in Advanced Installer tool.
We are struggling to figure out what is causing this, and haven't found a way to consistently reproduce the issue (though we've seen it happen as well).
Here's what changed with our installation and web updating process:
The main installer for our application is now a standard .msi, which becomes a part of the Windows installation system and is natively manageable by Group Policy and other system features, such as rollback or versions. In previous versions that did not have this problem, our installer was a .exe built with the SetupBuilder tool.
We introduced the redesigned web updater feature inside the app (to update to new versions within the app). It uses the same .msi as the main deliverable as for installation. .msi is downloaded from our server in a form of .exe which is then extracts MSI and starts it. MSI then updates file in our installation. These .exe and .msi is built with Advanced Installer tool which provides such a web update feature to developers. In previous versions that did not have this problem, our web update feature was developed with SetupBuilder tool which provided a custom web update files - .exe web updater that downloads a number of web update files containing patch to our app.
The goal of a transition to the standard .msi installer was to make it easy for our clients to deploy the app in organizations - say, mass deploy using group policies and other similar tools.
Has anyone else experienced a problem like this? Any ideas on how to troubleshoot and try to reproduce?
Theory: Before doing anything else: The first thing I would ask the people who report the problem is if they have re-packaged your older, legacy (non-MSI) setup to be their own MSI file? This can cause a well-known upgrade problem along the lines of what you explain (file missing). Please check first. Tell them to uninstall the existing version and then install the new one - that is the simplest way. Not always enough (some obscure problems possible).
Mismatched component GUIDs could cause missing files after upgrade, as could file version downgrade scenarios and various other technicalities. You could try to install to a new default location on disk to avoid these problems. The reason this can work is very technical and hard to explain tersely. Essentially you de-couple yourself from "the sins of the past". It is generally enough to change the name of the file in question: for example MyApp.exe to MyAppNew.exe or maybe add the major version: MyApp5.exe, but maybe try the folder change first ProgramFiles\MyCompany\MyApp => ProgramFiles\MyCompany\MyApp5.
How do you configure your upgrade? View "Upgrades", what is selected: "Uninstall old version first and then install new version" or "Install new version first and then uninstall old version".
Blog Entry:: Why Windows Installer removes files during a major upgrade if they go backwards in version numbers (might be of help).
Deployment Debugging: For open ended debugging of MSI and deployment problems in general one obviously needs to gather intel and that means logging and system inspection.
Logging: First try to get a proper log file for the systems where this problem occurs. In Advanced Installer you can tick the "Enable verbose logging" in the Install Parameters view to enable verbose logging for all package installations. This adds the MsiLogging property to the compiled MSI and every installation of the MSI will cause a MSI log file with a random name to be created in the TMP folder. View the folder, sort by date and the file should be at the top. Suggest you do this and then tell the users to send you the log files when relevant. Maybe you have this setting enabled already?
Further Logging: There are many ways to enable logging, and you can find a description here: Enable installation logs for MSI installer without any command line arguments. The MsiLogging property is just one possibility.
To log a single MSI setup: http://www.installsite.org/pages/en/msifaq/a/1022.htm.
To enable global logging for all MSI operations on the machine: Please see this FAQ-entry from installsite.org, section "Globally for all setups on a machine" - for the exact procedure.
How to interpret an MSI Log File.
I'm trying to package and deploy a wpf application. I used install shield and I have created the setup file. When I try running the setup file it keeps throwing this error code
1925: it needs admin privileges to run the setup.
How do I configure the setup file to be run by any user? Should I make any changes in the registry during the creation of setup file in install shield? Is there anyway to work around this problem?
Thanks
It sounds like you're trying to create a per-user installation. Since Windows Vista, this requires several steps, but was made simpler with Windows 7. I would check a verbose log in case it highlights any specific problems, and if not, follow this general advice:
If this is always a per-user installation, set General Information > Require Administrative Privileges to No and set the ALLUSERS property to empty.
If this is only conditionally per-user, leave them as Yes and 1 respectively, and use the MSIINSTALLPERUSER property with ALLUSERS=2 to select a per-user installation at run time. Note that this only works on Windows 7 (MSI 5.0) and later.
Ensure that your setup.exe, if you are using one, does not elevate. Set Required Execution Level to Invoker in the setup.exe tab of the Releases view.
If you are not using MSIINSTALLPERUSER, ensure that you are not installing any resources to any machine locations. This includes installation files to the ProgramFilesFolder, registry keys to HKEY_CLASSES_ROOT or HKEY_LOCAL_MACHINE, or other machine-level items such as Windows Services. Note that you may have to exclude services from MSIINSTALLPERUSER scenarios as well.
I have a job defined for a Windows FTA (TWS term). This job calls a bat script.
When thte script is run from the command prompt on the windows box, it runs ok, but when it is scheduled through TWS it comes up with the errors:
Application started at 6/3/2014 10:00:16 PM
There is error in the file Field_Details.csv.Please check with the below error
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.
There is error in converting Field in Excel(Field_Details.csv) to list in program. Please Check with below error message
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.
Application ended at 6/3/2014 10:00:16 PM
This error is stopping the script from continuing. I've seen some other posts about stopping and starting app pools on the windows box, but the box this is running on does not have an IIS Manager, so I don't know whaere to go from here.
ANy help is appriciated.
I work on TWS. I had a very similar error message (MDAC) coming up on one of our FTAs. There wasn't a fix per-se, but what was missing was that the file that TWS calls before the jobs starts, to check if there is a user-specific setup file to call was not checking for that file. We set it to check and ultimately call the setup-file and everything was good.
The file which does the check is in the TWS install dir, named jobmanrc.cmd. The scripting in that file checks to see if the (user-specific) setup file, djobmanrc.cmd exisits, if it does, it sources it to set up variables, etc.
I'd say check to see if your jobmanrc.cmd is checking for djobmanrc.cmd.
I am having a problem installing an msi on to a windows 2008 web server. The exact same msi previously installed successfully. The msi is for a .net 4.0 web application that I have created and being installed in to IIS.
What happens is that the msi seems to be installing correctly, and it reaches 0 seconds remaining on the progress bar, then suddenly it starts rolling back. I checked the event viewer for information on this but none appeared there, to assist with getting to the bottom of what the issue may be.
As the msi previously installed without issue on to the box, I believe the problem may be to do with a change to the server rather than to do with the msi.
Anyone experience this before or have an idea as to where I may be able to find more information as to why the msi installer is rolling back?
Ok, what I have done with the help of Bogdan Mitrache reply was to compare logs from a successfull server and the server causing the problem and this is the section where I found the error to occur:
FAILED: -2147024864
FAILED: -2147024864
Custom Action failed with code: '32'
Custom Action failed with code: '32'
Custom Action completed with return code: '32'
Info 1903. Scheduling reboot operation: Deleting file << root directory >>\TBD2D0E.tmp. Must reboot to complete operation.
Info 1903. Scheduling reboot operation: Deleting file << root directory >>\TBD2ED3.tmp. Must reboot to complete operation.
Info 1903. Scheduling reboot operation: Deleting file << root directory >>\TBD2F41.tmp. Must reboot to complete operation.
And then at the very end of the process:
Return value 3.
I have done searching on the internet but I have found no concrete reason as to why the above may be occuring. Anyone have further information on the above, or where i may look?
The best method to see exactly why the MSI package fails is to create a verbose log, using this command line: msiexec /i "msi path" /L*V "debug.log"
The log should contain more details about the cause of the rollback. As you suspected probably you have a duplicate IIS web site/app that conflicts with the package.
The return code mentioned in the log means this: "The process cannot access the file because it is being used by another process.". The reboot messages are automatically included by Windows Installer when a file that needs to be updated is currently in use.
According to Windows Installer standards, the return code of a custom action must be 0 to be considered it executed successfully. Any return code different from 0 is considered failure.
What you should do is to add another custom action, scheduled in the beginning of the installation, that stops any services/applications that could use resources updated by the package.
You should be using virtual machines with snapshots to rule out changes to the environment vs changes to the installer. And you should certainly be logging and reading your windows installer log.
My problem is this: I am getting a TFS build failure that I have tracked back to what appears to be a missing Registry key under SOFTWARE\Microsoft\VisualStudio\9.0Exp.
This machine had the VS SDK 1.1 installed via a command line: msiexec vsski.msi
So, I am guessing that I need to pass some properties to the msiexec to tell it that it should install some component which isn’t getting installed by default – is this correct? If so, can anyone point me to the correct property?
msiexec vssdk.msi WHATPROPERTY=”I want to control the which components are installed”
Or am I off track here?
Okay, I found the answer and I was a little off track.
More background: The error occurred in the VsTemplatePathsTarget of the Microsoft.VsSDK.targets file while calling the custom task VsTemplatePaths. A little reflector (great tool!) told me that it is trying to find the registry key above.
When I tracked it more closely I discovered that the key was not present under HKLM, but was under HKCU, but reflector and some trace messages said it was using HKCU. More precisely, the key in question is present under my account in HKEY_USERs, but not the account the TFS build runs under.
It turns out, my automated install sequence was such that the build account was created after the VS SDK was installed, thus when it configured the registry settings it only did so for existing users and not the default user.