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.
Related
Hi it's been few days having different Google Video Support Pluggin Installer tasks running
It happens the same this folk described here:
v78 of Chrome, Win 10, Every few hours a new instance of the video plugin installer exe kicks off and runs in parallel with the other(s) in place. Each instance takes ~ half a core and there is also always one MsiExec that terminates (similar usage) when the process is manually killed in task manager. The processes originate from \users\\appdata\local\google\update\install{GUID} - deleting the directories / files does no good, the updater downloads it after a few hours and tries again.
Video plugin installer is v 19.9.2600.0, 10,692,592 bytes
I'd like a way to stop this automated install or have it succeed. It seems I can do neither right now.
Any solutions to this in place?
Thank you in advance!
Quick Questions: 1) Are you behind an internet proxy server? 2) What is your security tool / malware suite / anti-virus? Can you
temporarily disable it whilst the installation finishes? 3) Have a look
in the "Deployment Mnemonic" section here? (for various causes of
deployment failure). 4) You can try to log in as another user and install fresh - see if that works. If it does, then you need a Chrome profile cleanup? 5) There is always the reboot. Always try that first to get it out of the way as the "one-size-doesn't-fit-anyone-at-all-really fix".
Technical: If I were to guess the problem is a custom action in the MSI that gets stuck "somehow". How many msiexec.exe entries are in the tast list and what context are they in? (user, system). There can be many msiexec.exe processes. Below is information on how to debug custom action failures (and other failures) by log analysis.
Logging: If this really is an MSI installer (Windows Installer), then you can try to enable MSI logging policy to create a log file for all MSI installations that run by following the instructions in the section "Globally for all setups on a machine" here. You will then find a log file in the TEMP folder after the installer has run (whenever that might be). Look for *.log files with a random name. Just sort the folder by change date to see the most recent files.
Open Temp folder: Windows Key > Tap R > Type: %TEMP% > Press: Enter.
Debugging: You can search the log for "value 3" first to find errors (see Rob Mensching's explanation in that link). You can find more information on interpreting MSI log files in the section "Interpreting MSI Log Files" here: Enable installation logs for MSI installer without any command line arguments
anybody an idea why this might fail? VS2017 installation stops with that error in the log. I had similar issue with VS2017 RC builds.
Package 'Microsoft.DiagnosticsHub.KB2882822.Win7,version=15.0.25904.2,chip=x64' failed to install. Return code: 0, Details: Invalid source and/or destination paths
One possible reason this could occur is that antivirus programs are being configured to be more aggressive at blocking executable files running from a temp directory. The installation of this component executes DISM.EXE which in turn executes DISMHOST.EXE from the user APPDATA\LOCAL\TEMP folder.
The quickest way to confirm this is to temporarily disable your antivirus program. The safer way to confirm this would be to review your antivirus program configuration and corresponding log files.
The issue is most likely that the windows username has a space in it and when one portion of the installer wants access to a temp folder under the user profile directory it throws an error due to a bug because it can't handle the space in the username. (Shout out to Wong Man Wei who identified the root cause!)
A work around, is to create a new user on the machine that does not have a space in the name. Then run the installer again and repair the existing install that was done from the other user and the repair will work successfully since it has access to a temp directory under this user that has no space in the name.
Now once the repair is successful you can delete this user account and go back to using the one with the space in it.
We have a msi package which installs a Windows Service. At end-of-day, the windows service downloads a new msi package from a public blob location and kick off reinstalls.
The reinstall command =
msiexec /i GatewayService.msi /qn REINSTALL=ALL REINSTALLMODE=vamus /L*V msi.log
What we want is as follows:
This should reinstall the whole msi package again w/o any check on
any conditions
Whatever files are in the new msi should be copied to installed dir and files not in the new msi should be trashed.
So essentially what we want is like UNINSTALL old msi and RE-INSTALL new MSI in one command.
We were wondering
if the REINSTALL/REINSTALLMODE flags value are correct ?
Sometimes we see an orphaned Windows Service in TaskManager. Any idea why the re-install command resulted in 2 instance of Window Service?
Suggestions would be grateful!
You produced a log - take a look and see if there are any mesasges about removal of components being unsupported. Also set MSIENFORCEUPGRADECOMPONENTRULES=1 on the command line and the install will fail if you broke a minor update rule. If it does fail, then the author of that MSI is breaking update rules and Chris' advice to do a major upgrade is required and not optional!
The services may not have ServiceControl actions to stop and start them, so they'll just keep running over the update because nothing is telling them to stop. This can be complicated by in-use files requiring updates because your silent install has no file-in-use dialog to prompt to shut down processes.
You can get an apparently orphaned service process if the service shuts down (the process ceases to be a service) but the containing process is still running. That might be normal if the service responds to the shutdown but continues afterwards for some time, that depends on the code in the service.
Your commandline indicates that you are doing a minor upgrade. Your requirements indicate a major upgrade would be more suitable for you.
How To: Implement a Major Upgrade In Your Installer
Minor upgrades are very picky and breaking rules are likely causing your duplicate service problems. See:
Changing the Product Code
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.
I created a MSI package with visual studio. It works fine for 80% of the users (some have errors with privileges and the like), but for two users the installation fails with the error message:
The feature you are trying to use is on a network resource that is unavailable
Which I find very odd because all the MSI does is set some registry values and put an OCX control into the system. Nothing with any network devices or anything else.
It also refers to a install[1].msi (when the actual MSI is called install.msi) which it supposedly can't find, which is obvious, because such a file never existed and is neither required for the installation nor even referenced in it in any way.
The package tries to locate this non-existent other package under C:\Documents and Settings\XYZ\Local Settings\Temporary Internet Files\Content.IE5\M84S9GA4\, even though I started the MSI out of the local drive D:.
How can I resolve this / get closer the underlying cause?
A verbose log file should show you the exact error causing the issue. If it doesn't happen consistently, you'll probably be best served turning on the logging policy to get a log file all the time and when it repros, grab the log file really quick.
Alternatively, if you have a repro situation you can get a log file immediately by doing:
msiexec /i path\to\your.msi /l*v install.txt
As for the root cause, the fact that that the name is install[1].msi makes it sound like the MSI was downloaded using a web browser and launched out of the browser cache. The Windows Installer is very particular about the name of the MSI, you can read about that in an old blog entry of mine. The end result is that shipping a 'naked' MSI on the internet is never a good idea. Maybe you're seeing these errors when shipping a newer MSI? If so, that would make a lot of sense.
A verbose log file will show you for sure.