MSI GPO loop
Categories
(Firefox :: Installer, defect)
Tracking
()
People
(Reporter: Bodo.Schulz, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
I have Firefox ESR on every station Windows 10 [Windows 7]. We generated an GPO with the lastest MSI package.
Actual results:
Whe station starts, i can see, that the MSI Installer is started but will never end. The only way to stop these is hard stop the station. After this Windows did not try again to install this package.
I'm not shure, if the new version is installed, because i did not know what was installed before.
When we setup a new station, installion of firefox runs without endless loop.
Expected results:
There is one possibility, we disallow executing files in temp directories to block troyans like locky. With a real MSI installation, this is no problem, but firefox is an wrapped exe, which will extract itself.
Is there a way to set the extraction directory as an MSI parameter (MST)?
Could it be, that updates for the next start of firefox would block the new installation?
|
||
Updated•6 years ago
|
|
||
Comment 1•6 years ago
|
||
The priority flag is not set for this bug.
:mhowell, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 2•6 years ago
|
||
Thanks for making this report, and I apologize for missing it for two weeks, I'm not sure how that happened.
I'm also sorry that I don't have great news. You can tell the MSI to just extract the FIrefox files and the installer without trying to run the installer (by setting the EXTRACT_DIR property), and then you can manually run the setup.exe file that it extracts. But that will still extract some DLL's into a temp folder and load them from there (that behavior can't be prevented), and it's possible your blocking would be unhappy about that as well.
It would also be interesting to know whether the .exe installer hangs in the same way or does something different, so if you're able to try running one of those and see what happens that would be great.
Could it be, that updates for the next start of firefox would block the new installation?
A normal upgrade wouldn't cause that situation; it would only happen if you had previously run an installer to do an upgrade while the copy of Firefox you're upgrading was still running. In that case, the problem should go away after a reboot.
Dear Team,
it should be possible, that updates for the next start would block the new installation. Because all Stations have already an older Version of ESR installed and Firefox is the favorit browser.
But this should not block the installer, he should ignore it or stop his own process.
The EXTRACT_DIR Property is one possibility, but it would block the process, as i remember. So it's no solution for our Locky Blocks.
The best solution should be an real MSI installation, but microsoft himself is notable to do this in all products :-(
For the next three week i'm not able to answer.
With kind regards,
Bodo
|
|
||
Comment 4•6 years ago
|
||
Thanks for responding.
(In reply to MEBSware from comment #3)
it should be possible, that updates for the next start would block the new installation. Because all Stations have already an older Version of ESR installed and Firefox is the favorit browser.
But this should not block the installer, he should ignore it or stop his own process.
We don't have the installer automatically close any processes because it's easy to forget that you have an instance running so you might lose something you were working on.
The EXTRACT_DIR Property is one possibility, but it would block the process, as i remember. So it's no solution for our Locky Blocks.
Oh, do you mean that running the installer .exe that's extracted from the MSI is being blocked? In that case anything that can extract the contents of MSI files could get that, but then there's no reason to use the MSI anyway.
I'm going to close this bug because I think I've done all I can; please feel free to reopen it if I'm wrong about something.
Dear Matt,
installing MSI with GPO is running, when no user is active (at system startup), so there is no firefox process running!
So the installer should handle nearly all situations in the file structure of firefox and never hang in an endless loop. One way is to stop with an error event.
Usualy MSI file are used in small environments to normalize all stations with the same version of a software. In the time where are two ESR versions available we tried to switch to the new version sytem wide. This is one reason, why we use these kind of distribution.
And any new station in the environment get most of the needed software automaticly.
The new possibilities of MSI and GPO allow us to make firefox as default browser to more people in firms.
Thanks,
Bodo
Description
•