I often get a problem with Windows Installer trying to uninstall a package, but it complains that:
The feature you are trying to use is on a network resource that is unavailable.
Is there a known means of uninstalling such packages when the original MSI is simply not available?
Please note that Microsoft has now released an official tool to resolve these issues, without the problems that previously existed with MSIZAP.
Microsoft Fixit: Fix problems with programs that can't be installed or uninstalled
Take a look at a tool called MSIZap released by Microsoft.
UPDATE:
MsiZap.exe has been deprecated for quite some time. Its use is unsupported on all recent versions of Windows, and it is considered a very unsafe tool to use.
I added a link to a newer Microsoft support tool designed to clean out installations, but this tool also appears deprecated at this point. I have removed the link from the comments section.
Perhaps try the tool linked to in saschabeaumont's answer below.
FYI, this post explains the root problem https://superuser.com/q/293542/245923
You can uninstall it using the product code:
msiexec.exe /x {your-product-code-guid}
You would obtain this code from the MSI itself, or whatever tool you are using to build the MSI.
Note that when you uninstall a product, it uses a cached MSI, since only the original MSI knows how to uninstall itself. When you use the product code, it uses the cached MSI from C:\WINDOWS\Installer.
Update, Stein Åsmul: There is a whole list of cleanup approaches here (recommended).
UPDATE:
This newer support tool can be tried on recent Windows versions if you have defunct MSI packages needing uninstall. This new tool appears to have been deprecated as well.
Perhaps try the tool linked to in saschabeaumont's answer.
It is not normal or standard MSI behavior to ask for the original source media - it indicates a badly designed MSI package. If you experience this with a vendor MSI it is highly recommended that you report the problem to their support team. Here is a more comprehensive explanation of the problem: Why does MSI require the original .msi file to proceed with an uninstall?
In most cases MSI packages can be uninstalled from add/remove programs from the control panel even if you don't have the original installation database for the MSI - the uninstall is run from a cached copy of the original MSI in the system folder %SystemRoot%\Windows\Installer (in some cases this cached MSI could be missing, see section 12 here for potential causes).
Earlier versions of MSI tended to trigger this problem (asking for the original installation media) more often (Office back in the day), and legacy MSI files can still cause uninstall problems that can only be solved using the msizap.exe tool (this tool is deprecated, outdated and no longer supported). This command line tool (msizap.exe) also had a GUI available (MSICUU2.exe), both tools are deprectated (try the link to the new cleanup tool listed above).
Just for the record: If you have access to the original MSI that was actually used to install the product, you can use this to run the uninstall. It must be the exact MSI that was used, and not just a similar one. There is a unique package guid assigned to each MSI file, so Windows will know if it is the right one.
Related answers:
wix - custom action dialogbox on silent uninstall of application
Uninstalling an MSI file from the command line without using msiexec
You didn't do something crazy like go to C:\Windows\Installer\ and delete the files in there did you?
One drawback of MSI files is you need the complete MSI file in order to uninstall or repair the application. Windows loves to store a copy of the MSI. It also renames the MSI file from a common name to a GUID with no table (that I can find) to map original names (example: Office2010.msi) to the new GUID so you have a PC with many GBs of wasted space that you can't delete. A machine that's not even 1 year old can easily hit 8 GB (example: mine).
There is an MSI cleanup utility from Microsoft, Windows Installer Cleanup Utility (deprecated tool, unsupported and unsafe to use - perhaps try this answer instead: Uninstall without an MSI file).
Or CCleaner can usually do this
Control Panel --> Add/Remove programs?
EDIT:
Your post mentions nothing about using add remove programs to uninstall the app, you said the "Windows Installer" (MSIEXEC - see the link below), which is not the same thing.
http://msdn.microsoft.com/en-us/library/aa367988(VS.85).aspx
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.
When i try to start one application (for instance application A.exe) error was throwing from already installed msi file (for Ex: B.msi) as "The feature you are trying to use is on a network resource that is unavailable or enter an alternate path to a folder containing the installation package 'B.msi'"
I have read some articles related to this error but all of them explaining if installer have any issues (if file have been damaged, deleted, moved, or quarantined by an anti-virus application) this error will occur but here when I try to launch one application then it is showing above mentioned error with another package name (B.msi) which I already installed.
Please let me know the cause of this issue it would be helpful to trace out this issue.
Note: For older version of our application don't have this issue (For creating installer earlier we have used Wise tool now using WIX tool. Is there any issue with WIX installer?).
Self-Repair Problems: This is generally a self-repair issue. I have written more times about this than I care to count, I'll see if I can send you here: MSI self-repair - the scourge of society.
Explanation: What is actually happening is that your installation goes through an integrity check when launced via an advertised shortcut, and a resource is found to be missing. The MSI will then try to repair itself (self-repair), but it is unable to find the required source files to retrieve the file it needs to reinstall - since the source files are no longer available at the location where you installed from. It is a good idea to install from a permanently available network location using administrative installations - especially for corporations.
Missing Source Files Resolution: In your case - to sort out the missing source files - you can either uninstall and reinstall (uninstall should not need source access in normal cases), and then preserve the installation files at a permanently available location (solving the problem for the future), or you can browse to the installation source when you are prompted to do so for your current installation (and there are some ways to automate setting new source paths). The installation source must be the one used to install the software originally (unless you know how to hack it, which is very involved).
Self-Repair Resolution: To sort out the actual self-repair conflict, you essentially need to find the culprit component causing the repair in the event viewer and then find some way to resolve the situation. All linked or explained in the above answer (repeated here). Proposed "real-world solutions" can be found in section 5 here: What do I do when launching an application triggers repeating, endless Windows Installer self-repair? As a workaround, you might want to try to launch the EXE files in question directly, to verify that the self-repair does not happen (generally this will prevent the self-repair, but it can still happen if there is a COM conflict or some other advanced conflict).
You can see a list of "Primary Cause of Self-Repair" some way down in this answer: How can I determine what causes repeated Windows Installer self-repair? (bad MSI packages with conflicting resources - COM conflicts?, security software quarantining files unexpectedly, cleanup scripts wrecking havoc, etc...). I would recommend you skim this list for ideas.
Uninstall Problems: This "installation source not found" problem can also occur so it prevents uninstall in special cases. Here is an answer which tries to summarize aspects of this problem: Powershell Silent Uninstall "Microsoft Report Viewer Runtime 2012" (somewhat too elaborate, but worth skimming I think).
Some Links (for reference and easy retrieval):
Installshield 2013 Installscript MSI: Wrong .msi location during Repair
Wix / MSI : Unable to uninstall
Uninstall without an MSI file
We have an installer solution written in Visual Studio 2005 Installer; that calls a C# custom action and we have hit a known issue, regarding the fact that on an upgrade - the old install code is run and not the new code, because Windows is running a cached version of the custom action dll. We know this and although not over the moon about it - we have moved on.
When we release a new version of the installer and a user runs it, we now want it to check to see if an ealier version is installed - if there is one; we want to display a message telling them that they have to remove the old version via Add/Remove Programs. We know if they do a manual uninstall followed by an install, then all is fine and dandy - BUT it doesn't matter how many times we tell our users, via documentation; that this is what they have to do - they will still try and just run the new installer, without removing the old version first.
Therefore, we would like to put up a message and thus force them to to what they are told !! I've seen some installers do this ( though of course not sure what installer package was used to create these ). We only have VS 2005 and of course orca !!
Cheers,
Chris.
This can be done through a custom launch condition:
create a search which determines if the old version is installed (you can search for a component, registry entry or file)
use the search property as a custom launch condition
For example, if the search property is OLD_VERSION, the launch condition can look like this:
Condition: NOT OLD_VERSION
Description: An older version was found. Please uninstall it using "Programs and Features" in Control Panel.
When OLD_VERSION property is set to a value (an older version is found), this launch condition will show the message and stop the install process.
This doesn't quite make sense. Have you remembered to change the package GUID in your new setup? The package GUID identifies a specific setup file, and if two MSI files have identical GUID they will be treated as the same file regardless of whether they are or not. This could trigger a cached version of the MSI to be invoked and all sorts of hell breaks loose.
I would recommend reading up on "major upgrades" which will allow automatic uninstall of the existing version before the new version is installed. You also need to make sure you understand the basics of the technology before deploying to the wild. You must NEVER use identical package GUIDs for any MSI files. It's practically always wrong, and will lead to very mysterious problems.
I can't write up the whole major upgrade solution here, but basically it involves authoring the "Upgrade" table of your MSI to detect versions to uninstall. You need to change the package code, product code and version number (only 3 digits matter) and keep the same upgrade code (two MSI files with the same upgrade code "know" they are related - i.e they are from the same product family). Check MSDN for samples of major upgrades.
NB! If you have deployed MSI files with duplicate package GUIDs to your developer machine, it could have stray installs that must be cleaned up with MSIZap or similar. Use caution, or better yet test your new installer on a clean test system. Developer systems are full of junk and not generally good for MSI testing.
We are installing several web sites using msi's as part of continuos integration tests.
For each build we want to uninstall the old msi and install a new one.
Problem is we do not have the old msi after the build server has done a get latest and rebuilt the system.
Is there a way in which we can uninstall the msi without having access to the orginal msi?
Yes you can, if you know the product code. Just type
msiexec /x [ProductCode]
on the command line. Or you could do it through the Add/Remove programs applet.
If you want to find the physical file, Windows actually stores a copy of the msi when it runs it - you will find it somewhere in your %WINDOWS%\Installer folder, but it will have been given a random name so could be quite hard to find :)
Alternatively if you don't know the product code (which you should) then try searching for your app name under the HKEY_CURRENT_USER\Software\Microsoft\Installer and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData registry keys, you will find the product code there. (quick hint: you can also search for UninstallString values in the registry).
Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.