Open Bug 1505436 Opened 6 years ago Updated 2 years ago

Uninstall fails when using MSI installer for the task

Categories

(Firefox :: Installer, defect, P3)

Product:
Firefox
Component:
Installer
Version:
65 Branch
Platform:
Desktop
Windows
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 --- affected

People

(Reporter: aflorinescu, Unassigned)

References

Details

(Whiteboard: [iu_tracking])

Attachments

(1 file)

uninstall-failed.log
37.81 KB, application/octet-stream
Details
Attached file uninstall-failed.log — 
[Description:]
Using the MSI to uninstall fails with: "This action is only valid for products that are currently installed"

[Environment:]
Windows 10, 8.1, 7

[STR:]
1. Run the a MSI with: msiexec.exe /i "c:\MSi\test.msi" /lvx "C:\msi\install.log"
2. Run the same MSI as the above with: msiexec.exe /x "c:\MSi\test.msi" /lvx "C:\msi\install.log"

[Actual Result:]
1. Firefox is installed
2. Windows installer shows the following error: "This action is only valid for products that are currently installed" and Firefox is not uninstalled

[Expected Result:]
2. Firefox should be uninstalled.

[Additional Details:]
-adding the msi log.
-one explanation for this behavior would be if the Local grup policy for Windows Installer would be set on Enabled, which is not the case as default or for the env. in which we tested.
This is expected. The installation doesn't actually result in any MSI product registrations being created, so it can't find anything to uninstall.

Adrian has pointed out that because our MSI is, well, let's call it "unconventional", it isn't clear which msiexec options are expected to work. I'm going to work on preparing a list of those to use for testing and probably also user documentation.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
(In reply to Matt Howell (he/him) [:mhowell] from comment #1)
> This is expected. The installation doesn't actually result in any MSI
> product registrations being created, so it can't find anything to uninstall.
> 
> Adrian has pointed out that because our MSI is, well, let's call it
> "unconventional", it isn't clear which msiexec options are expected to work.
> I'm going to work on preparing a list of those to use for testing and
> probably also user documentation.

Matt, since MSI is made available to make it easier for sys admins to manage Firefox deployments with Active Directory, I am concerned that not being able to uninstall using the same method could be problematic for these users.
What's involved in creating a MSI product registration?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
The only ways to achieve that would be either:
 - Creating a full-function MSI (that is, not a wrapper but a real MSI installation package). We've already turned down that idea for multiple reasons.
 - Hacking something together that makes the MSI uninstall process just run our current uninstaller. I'm not really certain how this would work, it might pull in too many of the problems associated with the first option, but it also might not.

I'm not sure whether this is necessary though, because there's a standard interface for all Windows uninstallers, which we are registered with, that works not quite but almost the same whether you're using MSI or not. I'd prefer to know whether this is something that admins do need before I start spending time on it.
Thanks Matt.
I think the only way to know is start gathering feedback from users and since the MSI is now on the FTP we're probably in a position to do that now. In any case I feel this should not block us from getting on Beta or release since (1) we can add details about how to handle uninstalls in the docs and (2) this will only apply to users of the MSI installer who would be using it knowing its benefits and potential limitations.
If we find-out that system administrators see no value in the MSI installer unless there is a proper MSI uninstall feature (through user feedback) we can decide to not advertise the MSI installer (bug 1493205) until this bug resolved.

I was trying the new msi for firefox for deployment through SCCM. The application does install correctly but does not detect properly. SCCM uses the msi GUID to verify the application installed but fails to see it. I checked the Identifying Number through PowerShell on the machine using: get-wmiobject Win32_Product | Format-Table IdentifyingNumber, name

But no result is shown for Firefox. When Firefox is imported into SCCM it does generate a GUID to detect {1294A4C5-9977-480F-9497-C0EA1E630130} but it can't be found after install. Even when installing directly from the msi without SCCM. Like mentioned here it's not a conventional msi, seems to be more of a package exe? I've gotten SCCM to detect but changing the detection method. I've been trying to find a way for sccm to properly launch the helper.exe to remove the application but haven't had success yet.

Hopefully some of this is of any help.

Component: Installer → Enterprise Policies
Component: Enterprise Policies → Installer
Priority: -- → P3

I think the quickest route to a solution for this (that doesn't involve rearchitecting all of both install and update from scratch and building a conventional MSI) would be something like this:

  1. Remove the hack that prevents the MSI from registering an installed product.
  2. Add a custom uninstall action that finds and runs the helper.exe uninstaller. This is the part that I'm least sure about; it's not immediately clear to me how to implement that action. I'm also just making an assumption that custom uninstall actions are even a thing, I haven't looked into how to do that.
  3. Have the regular installer skip writing its normal uninstall registration when run from an MSI. This change also needs to affect updates, which means we need to add something (I'm thinking a registry value) that PostUpdate can use to know whether it is updating an MSI installation or not.
  4. Figure out some way to update the MSI uninstall registration with the correct display version when the installation is updated. This might be impossible, but it might also not be a problem, I'm not sure.

Obviously a lot of unknowns in there. And there's probably something else that needs to be done that I'm not thinking of right now. It's a surprisingly deep problem.

So with that said what do you recommended using as the install verification given that currently your MSI does not actually work like an expected MSI. Most automated systems like SCCM, PDQdeploy, ect need to check something, MSI Guid registration is normally preferred for MSI type installers, but file location, version, file build date/time can be set up manually to prove the install succeeded.

What is your recommended way to check?

(In reply to wildtyphoon87 from comment #9)
With Firefox MSI not being a true MSI, just a hacked wrapper, my recommendation and what we will do from now on, is wrapping the exe installer with Win32 (Intune MDM), with custom detection rule to check install success and firefox.exe existence and version inside %ProgramFiles%.

Just checking by executable name does not really do much if there is a build over build upgrade happening because it would already exist, you would also need to check for file details, I am wondering what the FF dev team is recomendingas the best solution since as of now MSI guid is not an option. I know i could just start picking pieces of metadata at random but I would prefer to have something from the team as the next best option.

(In reply to wildtyphoon87 from comment #11)

Just checking by executable name does not really do much if there is a build over build upgrade happening because it would already exist, you would also need to check for file details, I am wondering what the FF dev team is recomendingas the best solution since as of now MSI guid is not an option. I know i could just start picking pieces of metadata at random but I would prefer to have something from the team as the next best option.

Yes, the most reliable indicator is the version info on the firefox.exe file at your installation path; it will always be correct and up to date and reflect the version of the product that is actually installed. If file version info isn't easy to check, the application.ini file also contains the version number, so that would be a good first alternate. As a second alternate, the uninstall registry key that we do create contains the install path and also the version number. I don't recommend using the application registry keys (the ones in SOFTWARE\Mozilla) because I can't guarantee the structure of those keys won't change.

To have a full MSI installer would be very helpful.
Intune has a switch called "Ignore App version" but only for the MSI Method and not for Win32, so that Firefox could be up to date without always deploying a fixed version.
It is really annoying to have Firefox updating itself and then Intune is installing the older version over and over again. This results in Firefox Profiles marked as not compatible. But we would like to have Firefox updating itself.

Hello,
It's not understandable why Firefox is the only important software out there in the world without a working MSI package. Its bit embarrassing. Each little Tool has a working installer, so its not a big deal.

I work as admin in a small company with about 50 Workstations. We and a lot others companies using SCCM as solution to keep our environment up to date. In the future Microsoft will even push more the use of SCCM because of the product cycle philosophy of Win10.
By the way, allow autoupdate a software is never an option. Some business critical procedures will be affected and we need a careful rollout and deep testing before. So there is no way around SCCM deployments.

It's great Firefox does finally support gpo's. Now its just a small step ahead for a true and real integration for Firefox in Business enviroments.
Lets do it !

If i can help, i will.
I checked some internet sites and found a dozen of tools to build an msi package. Also widely used and long existing opensource tool.

who i can contact to offer my help to work in this issue?

greetings,

harald

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Bugbug is incorrect.

Keywords: regression

Hi, Harald. Thanks for offering to help! If you think you can do something to improve this situation, please feel free to start working on it. I'll try to provide some more context about the current situation.

The tool we're using to generate our MSI is WiX, which I'm sure is one of the tools you've found in your searches. It can be a bit tricky to use, but it's doing the job. We're using this XML file that I wrote. Currently that file is generating the thin wrapper that's discussed in bug 1475510, and that route was chosen because it allowed us to get something shipped quickly that would help in at least some situations and that we could start collecting feedback on. The feedback that I've seen has contained a surprising (to me) amount of complaints about this particular bug, so even though I was initially dismissive, I now think that was the wrong attitude and I'd like to get this addressed somehow.

The reasons why we have the problems this bug is about are complicated, but they boil down to the surprising level of difficulty in migrating existing installations and being compatible with our existing update system (which the majority of our users do need). Above in comment 8 I laid out an idea I have about a way to kind of weave around those problems by still using our current uninstaller and having MSI launch it for us. But there were some questions that I had and I haven't had a chance to look into this since then, so I'd appreciate any help with any of those matters. Again, a lot of the complexity comes from the fact that anything we do needs to work both for new installations and for updating existing installations.

I don't have a ton of time available to work on this right now, but I'll try to respond to specific questions (either here or you can contact me directly).

(In reply to Molly Howell (she/her) [:mhowell] from comment #12)

Yes, the most reliable indicator is the version info on the firefox.exe file at your installation path; it will always be correct and up to date and reflect the version of the product that is actually installed. If file version info isn't easy to check, the application.ini file also contains the version number, so that would be a good first alternate. As a second alternate, the uninstall registry key that we do create contains the install path and also the version number. I don't recommend using the application registry keys (the ones in SOFTWARE\Mozilla) because I can't guarantee the structure of those keys won't change.

For detection method I use "greater equals" version check, because otherwise after Firefox autoupdates, SCCM will overwrite it with an earlier version leading to profile incompatibility. This leads to another problem: Using only the .exe version for detection does not check if FF registered correctly. I had succeeded updates without registry entrys, so it was impossible to add it as a standard browser.

Your suggested registry path cannot be used for that method, because the folder name in \Uninstall itself contains the version number and so won't be detected after an autoupdate - leading to a forced rollback to the previous version.

I'm having this issue too. I historically used the FrontMotion version of FF to get a deployable MSI. I was elated to find an official version of an MSI. Sadly with it not being a true MSI it is causing issues for us.

It seems like the best way would be to rewrite the install to be native MSI and use an EXE wrapper for non-enterprise users. Only one install system would have to be maintained. It would be standard instead of a hacked/wrapper approach.

I believe WIX would be the proper tool to use build the MSI.

I understand more would have to be changed to facilitate this. The updater, etc.

If I wanted to start looking into doing this myself where would I start looking. I've never coded on FF before. Though I have other projects.

I'd be interested to know what issues there would be with developing a MSI centric installer over the current solution aside from the time it would take to refactor and develop.

@Molly Howell

To create a proper MSI I highly recommend using Advanced Installer, it is a professional MSI creation tool to create it from the ground up with all the parameters possibly needed by us system admins. I've been using it for many years to re-package apps into MSI when needed, however it does have the full capability to create advanced proper MSI.

Check out their free trial: https://www.advancedinstaller.com/

(In reply to eric.s.periard from comment #20)

@Molly Howell

To create a proper MSI I highly recommend using Advanced Installer, it is a professional MSI creation tool to create it from the ground up with all the parameters possibly needed by us system admins. I've been using it for many years to re-package apps into MSI when needed, however it does have the full capability to create advanced proper MSI.

Check out their free trial: https://www.advancedinstaller.com/

Oh and they have a fully featured 30 days trial to mess with it ;)

Sorry to sound like an Ad, but this is really the solution to making a proper msi.... You can even define your registry AppID and stuff when creating the MSI, it's really cool.

Check it out, highly recommended.

I think scripting a deployment is the best solution we sysadmins have atm.

  • You can easily get the latest version at script runtime thanks to Mozilla providing a URL for that, which makes the config set and forget, no need to update packages later.
  • You can package the script with Win32 if using Intune, that way you can create advanced detection rules, but also use the uninstaller from the EXE installer.
    • Don't know with SCCM though, I'm Intune MDM only.

(In reply to Olav Birkeland from comment #22)

I think scripting a deployment is the best solution we sysadmins have atm.

  • You can easily get the latest version at script runtime thanks to Mozilla providing a URL for that, which makes the config set and forget, no need to update packages later.
  • You can package the script with Win32 if using Intune, that way you can create advanced detection rules, but also use the uninstaller from the EXE installer.
    • Don't know with SCCM though, I'm Intune MDM only.

With SCCM you can easily use the EXE's version and set detection to GreaterOrEqual or simply detect the EXE and let the updater do it's job when new versions are out.... Typically use the former so when major versions are out I can supersede the original package.

(In reply to eric.s.periard from comment #20)

Thanks for the suggestion. I'm already aware of Advanced Installer, and I've seen some commercial software products using it. It's not an option that we're considering, for two reasons.

  1. It's a closed-source proprietary product. I am aware that they offer free (as in zero-cost) licenses to open-source projects, but unless I'm mistaken those appear to be one-off deals that would allow us to use the product in our own CI pipeline, but wouldn't allow individual developers and contributors to use the product to build installers on their own machines without them doing extra work to acquire the license, which isn't acceptable for us.
  2. It wouldn't do anything to help solve our update and migration problems that I mentioned in comment 17 above and in bug 1629281. Generating MSI files isn't the problem, we can make WiX do that just fine. The problem is that, since we can't maintain both our existing installation and update system and also new MSI-based ones (we just don't have the resources), we would have to switch entirely to MSI installer and MSP-based updates, which means migrating existing installations into MSI without just completely reinstalling them, which I don't know how to do and kind of doubt is possible. And even then that would still mean we have one updater for Windows using MSI and a different one (our current one) for other platforms, which... honestly, keeping the one update system going is about all we can do right now anyway.
Whiteboard: [iu_tracking]

Came here from the same issue others have run into SCCM failing to detect the MSI GUID.

I have a suggestion maybe a little more of a skirting around the issue that would eventually be great if it was fixed, but in the mean time how about

  1. Change the Registry Key Generated in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
    A. Instead of "Mozilla Firefox 68.6.0[ ESR] ([x86|x64] en-US)" (where ESR is optionally there if using that install) have it be "Mozilla Firefox[ ESR] ([x86|x64] en-US)"
    B. And keep the internal Registry Values the Same

That way I can tell my SCCM Detection method (in this example a 64 bit ESR install)

  1. Look for this Registry Key "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox ESR (x64 en-US)
  2. AND Value = DisplayVersion With Data Type Version
  3. AND This registry setting must satisfy the following rule to indicate the presence of this application
    A. Operator - Greater than or equal to
    B. 68.6.0

In that scenario i'm telling it If you've already got a newer version of ESR installed call it good otherwise install

This would free us SCCM Administrators up to have WAY more flexibility in how we detect the app.

Right now if I want it to skip over any newer versions i'd have to put additional detection rules for EACH version.

And before everyone dog piles me for not going to the latest and greatest I work for a government agency which is why we use ESR and even then we have strict rules in upgrading from one version to the next

Additional thought; The Firefox.exe is not a viable option because its file metadata doesn't indicate if its ESR or regular firefox and that's absolutely critical to using File based detection method for this. Yes you could use application.ini or platform.ini but those would require a custom vb or powershell script detection method which adds needless complication to what should be a simple matter. So I guess in the same vein as the registry suggestion if the Firefox.exe was updated to have metadata that reflected ESR vs normal that would also be a viable option for more robust detection methods.

TL/DR: Remove Version specific information from Uninstall Registry Key name and Add ESR identifying metadata to Firefox.exe to facilitate the use of more flexible SCCM Detection methods

I'm not sure we can really remove the version number from the uninstall key name, because those names need to be unique in case there's multiple installs.

But, let me suggest an alternative that already exists: the ESR installer also creates HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox ESR, with the default value containing just the version number and a second value CurrentVersion also including the ESR ([x86|x64] [locale]) string. If I understand the requirements correctly, I think that should work?

(In reply to Molly Howell (she/her) [:mhowell] from comment #26)

I'm not sure we can really remove the version number from the uninstall key name, because those names need to be unique in case there's multiple installs.

But, let me suggest an alternative that already exists: the ESR installer also creates HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox ESR, with the default value containing just the version number and a second value CurrentVersion also including the ESR ([x86|x64] [locale]) string. If I understand the requirements correctly, I think that should work?

Ok that's something I'll check out but your response raises some interesting questions.

  1. When would there EVER be multiple versions of firefox installed under the identical architecture?
    1. It's not typical AT ALL for an msi install to allow multiple versions at the same time. I'm not expert but i've created enough msi installers with Wix over the years I know enough that enforcing versioning over upgrades with msi is a core tenant of how it works.
    2. Now I can see you having on a 64 Bit Systems 8 total valid Firefox installs (System Firefox (X86/X64), User FireFox (X86/X64), System ESR (X86/X64), and User ESR (X86/X64) But if I run the newest X86 ESR installer as a user I'd expect the User's X86 uninstall key's values to be updated accordingly as the Guid for the product should not have changed at all just the versioning details
  2. Why couldn't you remove the version information from the Key name? If you look at a typical uninstall key almost EVERYONE else has the simple named Key for their product name and all the versioning is done in the values under said key you guys are literally the odd man out on this on the windows side.
    1. How much harder is it REALLY to check the value of the uninstall reg key to see what version you're working with when your already grabbing the key name?
    2. Plus it would go a LONG way towards your stuff actually working as an MSI since you wouldn't be actively working against how the system is designed to operated
  3. You yourself said

As a second alternate, the uninstall registry key that we do create contains the install path and also the version number. I don't recommend using the application registry keys (the ones in SOFTWARE\Mozilla) because I can't guarantee the structure of those keys won't change.

So what is the story there? I'm not looking to use something that's subject to change. I'm looking for consistency with just about everything else that installs on windows using MSI.

I'm sorry to harp but its decisions like the ones that led you down the road to create your own custom installation instead of adopting a standardized installation mechanism like MSI that has probably lead to more frustrated forehead to keyboard application for us Application deployment automators. This kind of "it kind of works if the moon is aligned with Saturn and its raining" is almost as bad as some of IBM's AS400 Emulator installs that immediately spawn new processes for the actual install then quit returning nothing to your Application process

(In reply to tofubug from comment #27)

  1. When would there EVER be multiple versions of firefox installed under the identical architecture?
    1. It's not typical AT ALL for an msi install to allow multiple versions at the same time. I'm not expert but i've created enough msi installers with Wix over the years I know enough that enforcing versioning over upgrades with msi is a core tenant of how it works.

The MSI is unlikely to create a situation like that itself under default conditions, but that's not the only (or even the primary) installer that we support, so it has to work with other copies that weren't created via MSI.

2. Now I can see you having on a 64 Bit Systems 8 total valid Firefox installs (System Firefox (X86/X64), User FireFox (X86/X64), System ESR (X86/X64), and User ESR (X86/X64) But if I run the newest X86 ESR installer as a user I'd expect the User's X86 uninstall key's values to be updated accordingly as the Guid for the product should not have changed at all just the versioning details

There are many many more possibilities than just those eight, because other channels (beta, Developer Edition, and Nightly) as well as any number of different localized versions can all be installed at once also, not to mention the possibility of just having multiple versions of the same channel for testing purposes. All of these are supported scenarios, and the uninstall keys (as well as our other registry keys) have to respect them.

  1. Why couldn't you remove the version information from the Key name? If you look at a typical uninstall key almost EVERYONE else has the simple named Key for their product name and all the versioning is done in the values under said key you guys are literally the odd man out on this on the windows side.

As you've already pointed out, other applications almost never support multiple installations (and in fact MSI itself doesn't really support it). We do.

  1. You yourself said

As a second alternate, the uninstall registry key that we do create contains the install path and also the version number. I don't recommend using the application registry keys (the ones in SOFTWARE\Mozilla) because I can't guarantee the structure of those keys won't change.

So what is the story there? I'm not looking to use something that's subject to change. I'm looking for consistency with just about everything else that installs on windows using MSI.

The ESR key in particular is an exception and (in my capacity as installer module owner) I'm willing to call it stable (which means it ought to have documentation and it currently does not; I'll file a bug to create that). That key exists only to support this kind of use case and isn't used within Firefox or the install/uninstall logic at all. That probably explains how I forgot about it when I wrote comment 12; that was my mistake and I apologize for it.

I'm sorry to harp but its decisions like the ones that led you down the road to create your own custom installation instead of adopting a standardized installation mechanism like MSI that has probably lead to more frustrated forehead to keyboard application for us Application deployment automators. This kind of "it kind of works if the moon is aligned with Saturn and its raining" is almost as bad as some of IBM's AS400 Emulator installs that immediately spawn new processes for the actual install then quit returning nothing to your Application process

The decisions that led us here come down very simply to limited resources (even my time is quite divided). To create the kind of thing that I think you're asking for would mean rebuilding our entire installation and updater architecture, including much of the server side, while also still supporting the current systems for platforms other than Windows, and we just do not have the resources to dedicate to that kind of project or the ongoing support for it. It's not the sort of thing where I can just decide one day to do things differently.

Inability to autodetect the mozilla msi installation It is very frustrating!!!!

Deployment through Microsoft Endpoint Configuration Manager (Aka SCCM 2107)
of the mozilla msi files to multiple domain computer fails to get automatically detected with error 0x87D00324 (-2016410844) :
Mozilla Firefox 94.0 x64 en-US Deployment failed 0x87D00324 (-2016410844),The application was not detected after installation completed
Let me note that the program installs successfully but it does not report correct results due to the detection problem
It creates chaos with versioning in large installations

The error is persistent in the last 10 versions of Mozilla Firefox.
Solution is to use additional detection methods with file and registry but it creates extra labor and is pointless since an msi is supposed to work out of the box.
Please review your msi!!!!!!

Failing to abide by industry ordinary / best practice and standards is not a sign of perfection but idiosyncracy.

I want to point out https://firefox-source-docs.mozilla.org/browser/installer/windows/installer/MSIX.html.
in most scenario's you can use this, but I unfortunately still have server 2008r2 in the mix for the moment, I have to wait until I can upgrade those to server 2019 , as those currently don't support MSIX.
If you are on Windows 10 , the MSIX is your solution.

still reproducible on firefox release 94.0.1 , i used windows 10

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

I'm suspicious that now that we support MSIX, this might be able to just be closed. But I'm not entirely sure, so I'll leave it open for now.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: