Created attachment 162148 [details]
Log generated with "MsiExec.exe /Package LibreOfficeDev_7.0.0.0.beta1_Win_x64.msi /l*vx D:\LibreOffice7beta1.log"

I don't think that packaging our MSI (that btw hadn't changed between 6.4 and 7.0) could affect the process that is not performed by LibreOffice, but by Windows Installer service, which itself decides if and how should it copy the MSI it operates right now.

I rather suspect some intermediate Windows Update that could had changed the Windows Installer operation. Could you please check if trying to install LibreOffice 6.4.4.2, which you know could be installed, succeeds after uninstalling it from system, and making sure that its MSI is not in Windows\Installer cache before the install attempt?

(In reply to Mike Kaganski from comment #2)
> I don't think that packaging our MSI (that btw hadn't changed between 6.4
> and 7.0) could affect the process that is not performed by LibreOffice, but
> by Windows Installer service, which itself decides if and how should it copy
> the MSI it operates right now.
> 
> I rather suspect some intermediate Windows Update that could had changed the
> Windows Installer operation. Could you please check if trying to install
> LibreOffice 6.4.4.2, which you know could be installed, succeeds after
> uninstalling it from system, and making sure that its MSI is not in
> Windows\Installer cache before the install attempt?

Hi, Mike!  Sorry for the late reply.

I did try installation using the following products and environment:

* LibreOffice 6.4.4.2, 7.0.0.0 Beta 1 and 7.0.0.0 Beta 2, all of them 64 bits;
* Windows 10, version 1909, 64 bits (AMD64);
* Volume C: is on a SSD;
* Volume D: is on a HDD;
* Volume Z: is on an external HDD;
* C:\Windows\Installer is a symbolic link to D:\Windows\Installer, a folder path with exactly the same security permissions on each folder level as the original C:\Windows\Installer folder path (even the D:\ folder has the same security permissions as the C:\ folder);
* The environment variable %USERPROFILE% is "D:\Users\Administrator" (without quotes);
* Anything else is not modified as the system was reset (opened Settings, Update and Security, Recovery, Restore this PC) and, on the first login on the machine, pressed CTRL+SHIFT+F3 to enter Windows Audit Mode (a special mode so all software can be installed before anything else on the system is installed after the first user first login);
* I put the arguments [/Passive /NoRestart] inside brackets to make clear that they are to be used normally on my install scripts, but I did not use them and just selected Next, Next, Install as if they were used so the error message would be shown.

The commands I used when testing, on exact order, are (remove the asterisks and don't use the lines starting with hyphens):

* On the first boot of Windows, I pressed CTRL+SHIFT+F3, then executed cmd.exe and proceeded doing the following commands:
* RoboCopy.exe "%SystemRoot%" "D:\Windows" /Copy:ATSOU /R:0
* RoboCopy.exe "%SystemRoot%" "D:\Windows" /Copy:ATSOU /SecFix /R:0
* RoboCopy.exe "%SystemRoot%\Installer" "D:\Windows\Installer" /Copy:ATSOU /Mir /MovE
-- These three commands creates an empty "D:\Windows" folder with the same permissions as the "C:\Windows" folder, then moves the C:\Windows\Installer folder, its contents, and copy the security permissions to its new location.  It is important to run them all as RoboCopy does not copy the security permissions from \Windows if it is not run again with the /SecFix argument, but it works for the \Windows\Installer folder without using /SecFix.
* MkLink /j "%SystemRoot%\Installer" "D:\Windows\Installer"
-- This command creates a junction point from C:\Windows\Installer to D:\Windows\Installer / to create a symbolic link, use "/d" instead of "/j".




For LibreOffice 6.4.4.2 64 bits installation, I run the following commands:

* MsiExec.exe /Package Z:\Compartilhada\Torrents\LibreOffice_6.4.4_Win_x64.msi /Passive /NoRestart
-- This command completed correctly and installed LibreOffice 6.4.4.2.  For some unknown reason, Windows Installer (msiserver) service kept running.

* MsiExec.exe /Uninstall Z:\Compartilhada\Torrents\LibreOffice_6.4.4_Win_x64.msi /Passive /NoRestart
-- This command completely uninstalled LibreOffice 6.4.4.2.  Windows Installer (msiserver) service still kept running.

* MsiExec.exe /A Z:\Compartilhada\Torrents\LibreOffice_6.4.4_Win_x64.msi TARGETDIR="D:\LO644" [/Passive /NoRestart -- this is the same as selecting Next, Next, Next, Install]
-- This command is intended to extract the .msi contents to D:\LO644 folder, which results in a smaller .msi package that will be cached at C:\Windows\Installer folder (the drawback is it will ask for the source files or the original full .msi package when doing repairs or installing extra components -- which is rare after install).  Sometimes this command completes as expected and sometimes it does not.  When it does not work, Windows Installer throws the following error message "Error 1314. Specified path C:\Windows\Installer\Config.Msi is unavailable" (translated from PT-BR to EN-US).  After erasing the folder C:\Windows\Installer\Config.Msi **and** C:\Config.Msi (running "rd /s /q C:\Windows\Installer\Config.Msi C:\Config.Msi", without quotes), then the command completed correctly.  Maybe erasing those two folders before trying to run this command will make it always work.

* MsiExec.exe /Package "D:\LO644\LibreOffice_6.4.4_Win_x64.msi" [/Passive /NoRestart -- this is the same as selecting Next, Next, Next, Install]
-- This command was supposed to install LibreOffice from the extracted sources from the previous command, but it always did not complete and throw the same error as the previous command may show.  After running "rd /s /q C:\Windows\Installer\Config.Msi C:\Config.Msi", the .msi package was installed correctly.

* MsiExec.exe /Uninstall Z:\Compartilhada\Torrents\LibreOffice_6.4.4_Win_x64.msi /Passive /NoRestart
-- This command uninstalls LibreOffice 6.4.4.2 so I could test the installation of LibreOffice 7.0.0.0 Beta 1.





For LibreOffice 7.0.0.1 Beta 1 64 bits installation, I run the following commands:

* MsiExec.exe /Package Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta1_Win_x64.msi /Passive /NoRestart
-- This command completed correctly and installed LibreOffice 7.0.0.0 Beta 1.  For some unknown reason, Windows Installer (msiserver) service kept running.

* MsiExec.exe /Uninstall Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta1_Win_x64.msi /Passive /NoRestart
-- This command completely uninstalled LibreOffice 7.0.0.0 Beta 1.  Windows Installer (msiserver) service still kept running.

* MsiExec.exe /A Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta1_Win_x64.msi TARGETDIR="D:\LO7B1" [/Passive /NoRestart -- this is the same as selecting Next, Next, Next, Install]
-- This command is intended to extract the .msi contents to D:\LO7B1 folder (the same reasoning as the equivalent command I did for version 6.4.4.2).  Sometimes this command completes as expected and sometimes it does not.  When it does not work, Windows Installer throws the following error message "Error 1314. Specified path C:\Windows\Installer\Config.Msi is unavailable" (translated from PT-BR to EN-US).  After erasing the folder C:\Windows\Installer\Config.Msi **and** C:\Config.Msi (running "rd /s /q C:\Windows\Installer\Config.Msi C:\Config.Msi", without quotes), then the command completed correctly.  Maybe erasing those two folders before trying to run this command will make it always work.

* MsiExec.exe /Package D:\LO7B1\LibreOfficeDev_7.0.0.0.beta1_Win_x64.msi [/Passive /NoRestart -- this is the same as selecting Next, Next, Next, Install]
-- This command was supposed to install LibreOffice from the extracted sources from the previous command, but it always did not complete and throw the same error as the previous command may show.  After running "rd /s /q C:\Windows\Installer\Config.Msi C:\Config.Msi", the .msi package was installed correctly.

* MsiExec.exe /Uninstall Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta1_Win_x64.msi /Passive /NoRestart
-- This command uninstalls LibreOffice 6.4.4.2 so I could test the installation of LibreOffice 7.0.0.0 Beta 2.





For LibreOffice 7.0.0.1 Beta 2 64 bits installation, I run the following commands:

* MsiExec.exe /Package Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta2_Win_x64.msi /Passive /NoRestart
-- This command completed correctly and installed LibreOffice 7.0.0.0 Beta 2.  For some unknown reason, Windows Installer (msiserver) service kept running.

* MsiExec.exe /Uninstall Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta2_Win_x64.msi /Passive /NoRestart
-- This command completely uninstalled LibreOffice 7.0.0.0 Beta 2.  Windows Installer (msiserver) service still kept running.

* MsiExec.exe /A Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta2_Win_x64.msi TARGETDIR="D:\LO7B2" [/Passive /NoRestart -- this is the same as selecting Next, Next, Next, Install]
-- This command is intended to extract the .msi contents to D:\LO7B2 folder (the same reasoning as the equivalent command I did for the other versions).  Sometimes this command completes as expected and sometimes it does not.  When it does not work, Windows Installer throws the following error message "Error 1314. Specified path C:\Windows\Installer\Config.Msi is unavailable" (translated from PT-BR to EN-US).  After erasing the folder C:\Windows\Installer\Config.Msi **and** C:\Config.Msi (running "rd /s /q C:\Windows\Installer\Config.Msi C:\Config.Msi", without quotes), then the command completed correctly.  Maybe erasing those two folders before trying to run this command will make it always work.

* MsiExec.exe /Package D:\LO7B2\LibreOfficeDev_7.0.0.0.beta2_Win_x64.msi [/Passive /NoRestart -- this is the same as selecting Next, Next, Next, Install]
-- This command was supposed to install LibreOffice from the extracted sources from the previous command, but it always did not complete and throw the same error as the previous command may show.  After running "rd /s /q C:\Windows\Installer\Config.Msi C:\Config.Msi", the .msi package was installed correctly.

* MsiExec.exe /Uninstall Z:\Compartilhada\Torrents\LibreOfficeDev_7.0.0.0.beta2_Win_x64.msi /Passive /NoRestart
-- I uninstalled LibreOffice 7.0.0.0 Beta 2 just for testing completeness.





After these testings, I suspect with you that it is not a bug on LibreOffice side (there are, though, some .msi packages that don't accept \Windows\Installer being a symbolic link to another folder), but some update to Windows 10 that broke Windows Installers.  There is an easy workaround that is erasing any Config.Msi folders on the system, be them located at the root of the lettered volumes ([C|D|E|F|G|...]:\Config.Msi) or at C:\Windows\Installer.

However, as not all users that download and install LibreOffice knows how to fix it, until Microsoft does not fix this bug (I will send them these findings), I suggest considering to create a custom action into LibreOffice MSI package to delete %SYSTEMDRIVE%\Config.Msi and %SYSTEMROOT%\Installer\Config.Msi before and after doing any actual installation steps.  What do you think?

Thank you very much for this extensive testing!

(In reply to João Paulo from comment #3)
> After these testings, I suspect with you that it is not a bug on LibreOffice
> side (there are, though, some .msi packages that don't accept
> \Windows\Installer being a symbolic link to another folder), but some update
> to Windows 10 that broke Windows Installers.  There is an easy workaround
> that is erasing any Config.Msi folders on the system, be them located at the
> root of the lettered volumes ([C|D|E|F|G|...]:\Config.Msi) or at
> C:\Windows\Installer.

I close it then as NOTOURBUG.

> However, as not all users that download and install LibreOffice knows how to
> fix it, until Microsoft does not fix this bug (I will send them these
> findings), I suggest considering to create a custom action into LibreOffice
> MSI package to delete %SYSTEMDRIVE%\Config.Msi and
> %SYSTEMROOT%\Installer\Config.Msi before and after doing any actual
> installation steps.  What do you think?

I don't think we can do that. The directories may contain information still used by Windows Installer: either from including nested MSIs (a deprecated, but yet existing feature if MSI), or from installation already finished, but waiting for reboot (or even it could affect our installation: these directories are managed by Windows Installer; and I don't have enough knowledge that any existing or *future* version of the service dos not use the directories prior to run the custom action for some technical reason). Removal of that information could harm those installations, and put the system into inconsistent state to the extent of requiring to repair/reinstall OS. So no, we can't consider that workaround.

However, the scenario you describe is not something any user is likely to encounter: we are dealing with redirecting system paths - and you know, it's up to advanced users to do that. I suppose that if you post a blogpost with your findings and the workaround (so that users know that they are not running an installation, and no installation is pending a reboot, and are safe to remove the directories outside of these conditions), it would be a reasonable means to workaround. Possibly even publishing this thing on our FAQ page [1] as a thing to try in case of general failure.

[1] https://wiki.documentfoundation.org/Faq/General/General_Installation_Issues_(Windows)

(In reply to Mike Kaganski from comment #4)
>
> However, the scenario you describe is not something any user is likely to
> encounter: we are dealing with redirecting system paths - and you know, it's
> up to advanced users to do that. I suppose that if you post a blogpost with
> your findings and the workaround (so that users know that they are not
> running an installation, and no installation is pending a reboot, and are
> safe to remove the directories outside of these conditions), it would be a
> reasonable means to workaround. Possibly even publishing this thing on our
> FAQ page [1] as a thing to try in case of general failure.
> 
> [1]
> https://wiki.documentfoundation.org/Faq/General/
> General_Installation_Issues_(Windows)

Hi Mike!

Thanks for answer!  I agree with you my workaround should be published at your FAQ, but I couldn't find a way to write it at the FAQ myself.  I tried to recover my old account (https://user.documentfoundation.org/passwd), but the system keeps saying that "The client does not have sufficient access to perform the requested operation".

Maybe the wiki is for developers only?

(In reply to João Paulo from comment #5)
> Maybe the wiki is for developers only?

No it isn't - but something with your account might need manual fix by infra team. Could you please talk to #tdf-infra IRC channel (on European work hours) so that they help you with that? Thanks!