
Firefox 140.2.0esr "updating" to 141.0.3 "release" channel
Recently we've began installing Firefox 140.2.0esr to our environment via the .msi file that Mozilla provides, however we're running in to a very odd incident.
After approximately 24 hours from installing Firefox esr to devices, it appears that the application is "updating" to 141.0.3 on the "release" channel. As far as I'm aware, this shouldn't be possible to begin with. But we've applied these settings via GPO:
Computer Config > Policies > Admin Templates > Mozilla > Firefox Application Autoupdate = Disabled Pin updates to a specific version = Enabled = Set to 140.2.0 Background updater = Disabled Disable Update = Enabled Manual Update Only = Enabled
After applying the GPO, confirmed this appears within the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\ AppAutoUpdate = 0 AppUpdatePin = 140.2.0 BackgroundAppUpdate = 0 DisableAppUpdate = 1 ManualAppUpdateOnly = 1
At this point, I'm at a loss. We cannot have rapid release be what's installed in our environment. Is there something broken with 140.2.0 or are we doing something wrong here?
Chosen solution
Well, sorry for wasting your day. Turns out our RMM had an automatic task set to convert the application to the 141.0.3 release version on all endpoints. This is likely exactly what's happening.
Should be fixed now.
Read this answer in context 👍 0All Replies (18)
Can you look in the defaults/pref directory where Firefox is installed and post the contents of the channel-prefs.js file?
Also can you go to about:policies and verify the values?
With those values set, there should be no updating at all.
Before and after the "update" that is automatically applying if I go to about:policies I see:
DisableAppUpdate = true BackgroundAppUpdate = false DontCheckDefaultBrowser = true ManualAppUpdateOnly = true AppAutoUpdate = false
channel-prefs.js reads: pref("app.update.channel", "release");
However, when I initially install from the 140.2.0esr .msi file channel-prefs.js reads: pref("app.update.channel", "esr");
Isn't
pref("app.update.channel", "esr");
the before? When you installed 140.2.0?
The update channel should only be release if a release build was explicitly installed...
Yep, that's exactly what my thought is too. I'm installing the 140.2.0esr .msi file from this location: https://www.mozilla.org/en-US/firefox/all/desktop-esr/win64-msi/en-US/
In fact, I had initially started with the 140.1.0esr file - though when I saw this happen the first time and recognized there was now a 140.2.0esr file I just swapped to using that one instead.
As far as I can tell, I shouldn't be anywhere near touching the release build.
I spoke to the release team and there is no technical way that this could happen.
We honor the channel that's in channel-prefs for the update.
So based on your comment, at one point did channel-prefs become release?
I totally understand, that makes complete sense to me as well.
I unfortunately haven't watched it happen. When I leave for the day, my device is sitting on Firefox 140.2.0esr and all configs reflect this. Then when I return in the morning it's sitting on 141.0.3 and everything is showing that's it's now on the release update channel.
When I've attempted to reinstall Firefox, I've completely deleted the entire C:\Program Files\Mozilla Firefox folder as well as the %appdata%\Mozilla folder. Following this and a system restart, everything on the machine once again points to esr being what is installed. Then once again, the next day we're back to release. This is happening to nearly all of the devices in our environment, and they aren't all "updating" at the same time in this fashion either.
The primary issue is that it's "converting" to release rather than sticking to esr. I don't have any interest in managing the updates manually, the GPOs I have been pushing has just been in attempt to stop Firefox from moving over to release; which it sounds as it shouldn't be possible to begin with.
The only thing that seems like it could happen is for a background task to do this (even though you have it turned off)
Can you run TaskScheduler and see if there are any Firefox related tasks scheduled?
It appears there's a task that exists named: "Firefox Default Browser Agent (ID string following)" "The Default Browser Agent task checks when the default changes from Firefox to another browser. If the change happens under suspicious circumstances, it will prompt users to change back to Firefox no more than two times. This task is installed automatically by Firefox, and is reinstalled when Firefox updates. To disable this task, update the “default-browser-agent.enabled” preference on the about:config page or the Firefox enterprise policy setting “DisableDefaultBrowserAgent”."
Which, checking the about:config this is set to 'True'.
This is the only task that exists on the device related to Firefox that I can find.
Yeah, that wouldn't be doing updates. I'm at a total loss. I don't know how Firefox could be doing this.
Maybe a log will tell us. I'm checking with the team.
No worries at all, that's why I ended up finding my way here! Happy to see if there's any kind of logs we can check too, we have about 70 devices to check from for this issue.
Everything about this feels like something else is updating Firefox.
One one of the machines that got updated to release, can you type about:support and then click the "Show Update History" button.
That will show us all the updates that Firefox installed. You'll probably just need to do screenshots.
The update history in about:preferences is a little easier to copy/paste if you want to do it there instead.
No worries, here's what I grabbed from your first request. It doesn't appear to be consistent across all devices.
For the screenshots firefoxcap1 and firefoxcap2, this is two different devices; both had Firefox installed from the exact same .msi file. Both started yesterday on 140.2.0esr.
However, what's also interesting is that in the environment there are still a handful of devices that (this time around) - did NOT update to the release version and are still sitting on 140.2.0esr. Though, it's also not consistent if their update history has anything in it or not. For the screenshot 140.2.0Firefoxcap1 - this is what appears in the update history for a machine that just freshly had 140.2.0esr installed. However on another device still sitting on 140.2.0, this window is blank and shows no update history at all.
I realize after replying, the screenshots do not show your their file name. The two screenshots in light mode are from devices sitting on the release version. The screenshot of the window in dark mode is of a device sitting on 140.2.0esr.
So those screenshots show that Firefox didn't do the update. Some other software is updating Firefox.
Are you using some sort of fleet management or endpoint software? I'm wondering if what is happening is it incorrectly thinks the ESR is downlevel.
Chosen Solution
Well, sorry for wasting your day. Turns out our RMM had an automatic task set to convert the application to the 141.0.3 release version on all endpoints. This is likely exactly what's happening.
Should be fixed now.
Never a waste of time.
We all learned things.
FYI, your AppUpdatePin isn't quite correct.
https://mozilla.github.io/policy-templates/#appupdatepin
You don't pin to a specific version, you pin to a major/minor.
It should be 140. for what you want