#289 v19.00 x64 MSI install over v18.06 issues

[Olav R. Birkeland]

I tried installing 7-Zip v19.00 x64 MSI over existing install of v18.06 x64, which caused Windows Explorer to restart and behave ape shit until I restarted my whole computer. It also forced closed Firefox and corrupted my Firefox profile.

I pushed the new 7-Zip installer with Intune, so several of my collueges experienced the same. This has never happened before when installing previous versions over old versions.

All these update steps went fine, without uninstalling the old version first.
17.01 -> 18.01
18.01 -> 18.05
* 18.05 -> 18.06

I cancelled the rollout, and hope you can take a look into this.

Intune only uses the standard MSI switches for a silent install. Heres an example from a different MSI I once installed:
msiexec.exe" /quiet /lv "C:\Windows\system32\config\systemprofile\AppData\Local\mdm{AC76BA86-7AD7-1044-7B44-AB0000000001}.log" /qn /i "C:\Windows\system32\config\systemprofile\AppData\Local\mdm{6B80C5DA-ACE7-4462-8CE1-B6455CAF48A9}.msi

[Olav R. Birkeland]

Windows OS: Windows 10 Enterprise 1809 x64 17763.316
Sorry for the bad formatting, I'm used to GitHub markdown.

[Igor Pavlov]

There are no changes in msi installer of 7-Zip.
But that magic with msi can depend from Windows/Explorer that can lock dll.
I can suggest you to use exe installer instead of msi.

[Olav R. Birkeland]

Roger that. As I said, all previous upgrades went totally fine, no problems at all.

EXE installer over MSI is not really a solution for us. Intune only handles MSI, unless we package the EXE to a Win32 Intune Package (.intunewin), which will create more manual labour for us.

You are absolutely sure nothing changed in regards to the install process from v18.06 to v19.00? We pushed v18.06 over v18.05 to several houndred clients without problems, with v19.00 it went bad for every single person who got it pushed before I removed it.

[Igor Pavlov]

It's msi magic.
Explorer can lock 7-zip.dll in some cases.
When msi installs 7-zip.dll, it wants to close explorer, if 7-zip dll is loaded in explorer.
Maybe Windows didn't lock 7-zip.dll in past, and locks now after some update of windows?

Also 7-Zip since version 18.02 uses:

    <Property Id="MSIRMSHUTDOWN" Value="2"/>

from MSDN description:
"2 - Processes or services that are currently using files affected by the update are shut down only if they have all been registered for a restart. If any process or service has not been registered for a restart, then no processes or services are shut down".

As I wrote, it's some msi "magic". It's difficult to control it. At least I don't know good solution now.
If someone understands all these msi/wix things, please write me some hints.

But I can control all things in exe installer.

[Olav R. Birkeland]

Ok, thanks for detailed answer.
I might have to look into repackaging the EXE file then.

[feeks]

I have seen this happen in the past with explorer holding files open particularly when an application, (not only 7-zip) has been in use prior to an update with explorer not closing the file handles to that application baulking the upgrade because of the application having open file handles. LibreOffice used to be notorious for this to the point that I would manually uninstall before performing a full install rather than strike the application upgrade failing because the app was still in memory. I have performed the upgrade on both 32 and 64 bit windows machines including 3 x W10, albeit all manual updates. This may be as simple as throwing a full restart before the update or forcing the application closed manually before the upgrade on the local machine or performing and uninstall/new install. Obviously with a roll out this can be a pain. Just my 2 cents worth!

[Olav R. Birkeland]

Just tested with repackage of EXE installer to .intunewin, worked wonders.
Are there any more switches than "/S"? I can't find any documentation on this.
Would like the option to exclude language files, andmaybe "/noreboot" to be sure to prevent reboot.

[Igor Pavlov]

For exe installer: Use the /S parameter to do a silent installation and the "/D=dir" parameter to specify the "output directory". These options are case-sensitive.

It will not reboot for /S silent installation.

[Tobias Keller]

Should the /q switch prevent reboot for the MSI installer? I'm facing a reboot with using this switch on some computers.

Are the switches /qn (quiet no GUI) and /norestart valid? The FAQ only mentions /q.