Mozilla Firefox 56.0 (x86 En-us) Download

[Sherman Desrosiers]

Iwas 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.

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.

(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.

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.

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.

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.

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.

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.

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

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 ([x86x64] [locale]) string. If I understand the requirements correctly, I think that should work?

3a8082e126