We have a legacy software installation that we're trying to remove from our organisation. We have different versions and are trying to create a universal uninstaller for all versions. We've come across a particular release that doesn't seem to be able to be uninstalled via command line though. And it's proving difficult to create a workaround.
I've found the GUID of the application in the registry via
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
And the command I run is:
msiexec /x {080FDF44-6D15-4D2E-977E-74D5168198E7}
I get an application prompt asking me if I want to uninstall the product, so I click 'Yes'. And then it looks like it's starting but never actually does anything. So I dug round the registry and found another GUID in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Userdata\S-1-5-18\Products\44FDF08051D6E2D479E7475D6118897E
If I run the same command as above with the different GUID, I get the application confirmation box asking for uninstall then after clicking OK, I get an error saying:
The installation package could not be opened. Verify the package exists and you can access it.......
I've been into C:\Windows\Installer into the folder with the above GUID and all that is in there is an icon and an *.mst file. In the root of C:\Windows\Installer, there is an *.msi called the same product in the details but with another version ID of:
8A2C4F93-4B31-4474-B9F2-2E51BF5D71A8
If I run the msiexec against that ID then I get a confirmation box again then another error which says
The action is only valid for products that are currently installed.
If I run the uninstaller, it uninstalls fine from the programs and features and uses the generated *.msi for the uninstalled (e.g. C:\Windows\Installer\241a6.msi and matches the product ID of 8A2C4F93-4B31-4474-B9F2-2E51BF5D71A8). This will change form machine to machine. Any other ideas on how to get this off in a neat and managed way?
You can't dredge the registry for ProductCode guids because they are obfuscated. If you don't really know the ProductCode, then look at ways of enumerating installed products. For example, the direct C++ way is MsiEnumerateProducts, and C# pinvoke equivalents, something like this:
MSI Interop using MSIEnumRelatedProducts and MSIGetProductInfo
Then you will get the actual ProductCode and can get other info with it.
If sometimes it doesn't work when you are absolutely sure of the ProductCode, then it was perhaps installed in a per user context that's different from the one you're running the program with.
Also, for MSI-installed products Windows doesn't use the uninstall string, it just uses the ProductCode directly. Again, registry dredging is not the right thing when there are actual APIs specifically to enumerate installed MSI products.
If an uninstall requires access to the original MSI that it was installed from, then there are at least two reasons:
The MSI has an unconditional ResolveSource action that forces it to ask for the oroginal MSI file.
The cached version of the MSI file has been removed from C:\windows\installer.
Related
I am attempting to make sure certain software does not exist before installing the newer version. Long story short, vendor requires me to do so, and although they recommend me to repair after install, that causes other issues such as undesirable restart (trust me I tried /norestart and I have even tried to modify the stored msi package to make sure it does not restart) but over all it just gives us soo much headache without the result we want.
So I tried to simply uninstall this software ahead of installing their newer one since that seem to have higher success rate without unnecessary issues.
Now I am accomplishing this by running batch file via ExePackage (with WiX toolset) with Vital="no". I have to do Vital="no" because when the older installer does not exist and if I call msiexec /x, it returns the error stating
this action is only valid for products that are currently installed
When the older installation exists, it works fine, but when it does not it errors out.
Now Vital="no" works fine, but I would prefer to suppress the error with msiexec /x if I can.
Is there any known way to solve this?
In order to solve this problem, I checked the uninstall keys and only called msiexec /x on products that were listed. Though in my own case, we were switching installer tech (too many MSI bugs...) and were uninstalling older versions of our own.
Installation State: You can use VBScript to check for the installation state of a product if you know its product GUID (replace the sample GUID here):
Dim installer : Set installer = CreateObject("WindowsInstaller.Installer")
MsgBox installer.ProductState("{6C961B30-A670-8A05-3BFE-3947E84DD4E4}")
There are a number of possible installation states. Here is a more comprehensive script to check product installation state. Check section 7 here.
Major Upgrades: I assume you are aware of how major upgrades work? (uninstall of existing installation and install of newer version with options for what order this happens in). They can in reality uninstall any other MSI package on installation via settings in its Upgrade table. This includes even competitive products (a bit mad one would have to say). You can - however - not install them again easily from within MSI for a number of technical issues. You could install them via a Burn setup.exe bootstrapper (which I think you use).
I created an msi that that installs my application. Now i want to do an update the msi. I used
msiexec /fvomus "application.msi"
This showed no error. But when when i try to update an application in remote machine it shows the below error
The installation package couldn't be opened. Contact the Application
vendor to verify this is a valid Windows installer
I used the below command for remote installation
msiexec /fvomus "//server/c$/Program Files/path_to_my_application/1.msi"
Assuming you want to update a product you've installed from an MSI package:
msiexec /f... does not update anything. The /f means that it's a repair, and that means to check that the currently installed product is correct. If you're using WiX and you want to upgrade an installed product then the MajorUpgrade element is the simplest and most reliable approach.
That error message is too generic to provide a simple answer. It may be that the MSI file is already open in another app, or you don't have the privilege to access that file (IMO the most likely explanation).
I created a setup for my product targeting Windows XP and later, to be installed using windows installer (WI). The resulting .msi file has a product code, let's say PC1 (actually a guid), and an upgrade code UC1 (also a guid). After some time, I created a new setup for a newer version of my product. The new .msi file has a new product code PC2 and the same upgrade code UC1 (also called a major upgrade). My company wants to install the .msi file with our own installer. For that, we basically use MsiInstallProduct to install the .msi file, while the entire UI is in our own install program (and we use MsiSetExternalUI to ask WI to send us notifications). The problem that I am having is the following:
if the two builds of the product are installed on the same machine using "msiexec /i myapp.msi" then there will only be one entry in the "Add/Remove Programs" of "Programs and Features" control panel applet. or in other words, during the installation of the new build, the old one is uninstalled.
if the two builds are installed on the same machine programatically using MsiInstallProduct, there will be two different entries in control panel.
Once again, only if I try to install it programatically (using either MsiOpenPackage+MsiDoAction or MsiInstallProduct), the upgrade does not happen and I end up with two entries in the control panel. I also found that if I do not set an external UI callback using MsiSetExternalUI, before calling MsiInstallProduct or MsiDoAction, then the upgrading part of a new installation also works as expected, no duplicate entries in the CP.
The callback that I use for MsiSetExternalUI is basically the same as the one in this MSDN article:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368786(v=vs.85).aspx
What can I do (or what I need to handle in my callback) to avoid having duplicate/multiple entries in control panel?
Thanks and best regards,
Levente
Re our comments above, I did a google search for CLIENTUILEVEL and the first several hits indicate to me that CLIENTUILEVEL having a null value is normal and that REMOVE=ALL is working. The comments indicate to go a little furthor down the log and find out why the uninstall (Remove existing products) is failing. If you could email me a complete log file ( chrpai#iswix.com ) I could look through it for you.
RemoveExistingProduct standard action
Link to article describing how to interpret Windows Installer log files (see comments)
RemoveExistingProducts running but not uninstalling Options
I ran into the same behavior with my ManagedMsiExec sample project: http://blogs.msdn.com/b/delay/archive/2012/01/09/make-things-as-simple-as-possible-but-not-simpler-managedmsiexec-sample-app-shows-how-to-use-the-windows-installer-api-from-managed-code.aspx
Changing the logging behavior of my app didn't help in my case. But after (independently) noticing the same "CLIENTUILEVEL= REMOVE=ALL" strangeness in the logs, I found a workaround which was to explicitly call MsiSetProperty and set CLIENTUILEVEL to 0 before calling MsiDoAction.
This appears to me to be a bug with Windows Installer itself (incorrectly setting CLIENTUILEVEL during RemoveExistingProducts), but perhaps there's something else going on I don't understand. At any rate, I've had success with this change and maybe others can, too. :)
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).