The new Firefox 60 fixlet provided by IBM has released several days ago and it seems an awfully low number of machines are being patched with it than I’m used to seeing when a browser update releases. Is anybody else in a similar situation? I’m still working through it, but it just seems like the relevance might be off or people are just rushing to update to 60 before Bigfix can hit them.
Looking at this relevance line:
exists key whose (name of it as lowercase starts with “mozilla” AND exists key whose (name of it = “Mozilla Firefox”) of it) of key “HKLM\SOFTWARE” of registry
This doesn’t seem to exist on some machines. Not sure what would cause this, but there was certainly machines that were not version 60 yet. Any idea why that registry wouldn’t exist? The structure on one of the machines that showed not relevant was hklm\software\Mozilla\Firefox
A few versions back Mozilla went to a 64-bit version of Firefox as the default download.
Is it possible you have auto-update enabled in your environment, and people are being automatically upgraded to the 64-bit version?
As far as I know, IBM does not currently supply fixlets for the 64-bit version of Firefox.
I would have to double check, but we patch through bigfix and the IBM supplied fixlets are 32bit according to the download URL. Last time I pushed a browser patch it was several hundreds machines. I got maybe 50 out of firefox 60, and depending on how I change the relevance, I get more machines showing relevant that are indeed not version 60 yet. I still need to do some digging, but I don’t see that many people going out of their way to update manually.
I can obviously only speak from my experience, but with roughly 25k Firefox installs in my environment roughly 3-4k are 64-bit (i.e. people downloading it from the Internet instead of installing it through the approved software portal).
1 Like
I did look at 64 bit installs, that is indeed part of the problem. But why doesn’t IBM put out a 64bit fixlet?
1 Like
Good job figuring it out. As to why IBM doesn’t provide a 64-bit fixlet… No idea.
1 Like
To be clear, that was just part of the problem. The IBM relevance was still not capturing everything. The relevance change I made to the IBM provided fixlet found far more machines that still had an out of date 32bit version. I then added more relevance/action script to remove 64bit versions and install the 32bit version to keep all machines on the same page for future releases since there’s no 64 bit fixlet provided in bigfix.
1 Like
Interesting.
Care to share your relevance changes in a before and after format? I can inspect my own estate to compare.
We pretty much ditched the entirety of the IBM provided relevance and simply went with checking the registry uninstall string:
(windows of operating system) AND (exists keys whose (value “DisplayName” of it as string as lowercase contains “firefox” of it AND value “DisplayVersion” of it as string as version < “60.0”) of keys “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall” of (x64 registries; x32 registries))
The actionscript doesn’t account for a situation that exists where someone has both a 64bit and 32bit installation and fails in testing, but I decided to deal with that on a case by case basis since it should largely be non-existent (assumptions I know, but so far so good).
A lot of machines were returning not-relevant due to
exists key whose (name of it as lowercase starts with “mozilla” AND exists key whose (name of it = “Mozilla Firefox”) of it) of key “HKLM\SOFTWARE” of registry
Which was included in the IBM fixlet.
1 Like
Interesting!
Yeah, I no longer have the HKLM\Software\Mozilla Firefox registry key.
I do have an HKLM\Software\Mozilla\Firefox key…
Yep, that was the biggest culprit (other than 64bit installs). I don’t know why some did and some didn’t have it and why/when the registry path changed, but the uninstall string appears to be most consistent at getting all machines with firefox installed.
Good catch. Hopefully we can get an IBM response on this one.