As mentioned in https://ask.libreoffice.org/t/msi-installers-issue/91672, it is important to attach installation logs.

Hi there. From what I can see the installation never begins so this is the reason I cannot provide logs for the process. The issue seems to affect all recent installers so I think there may be a significant issue with these...

(In reply to Adam Clarke from comment #2)

Did you try to create logs, as explained in the FAQ [1]? No matter if the installation completes; the log is being written from the first stage, and may contain important details.

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

Hi, yes I have followed the link you provided and unfortunately it does not work as it also does not recognise the commands for logging appears to ignore any command used.

(In reply to Adam Clarke from comment #4)
> it also does not recognise the commands for logging appears to
> ignore any command used.

This is highly strange. The command line arguments are handled by *msiexec* executable, which is a Microsoft Windows component, part of Windows Installer service. It starts logging even before it reads anything from the MSI that is passed to it as an argument (in this case, a LibreOffice MSI).

So given all that, I'd suggest you to check integrity of your Windows, possibly starting with a MS troubleshooting tool, also linked from the FAQ referenced in comment 3.

FTR: just now, I uninstalled LibreOffice from my Windows 10 box, opened cmd.exe as Administrator, and run this exact command line:

> msiexec /i D:\Downloads\LibreOffice_7.5.3_Win_x86-64.msi /quiet

and it worked fine, installed LibreOffice with the default settings without any interaction / UI.

Ok thankyou for your help. I am finding it bizzare that the old 7.2.6 installer works fine but same commands on the recent ones are not recognised. I have tried on multiple different standalone machines but interestingly all are Windows 10 22H2 so it could possibly be a bug in the latest OS version maybe? Something if definitely not right though.

(In reply to Adam Clarke from comment #7)
> interestingly all are Windows 10 22H2

Mine too: Version 22H2 (OS Build 19045.2846).

Ok I think I am getting somewhere. It appears to be an elevation issue. The old msi 7.2.6 seems to work fine without elevation as do all other MSI's I use for other software however the new MSI's for the latest versions do not seem to work without elevation which causes the installation to fail and this is an issue when deploying using SCCM. I am now looking to see if there is a way I can force it to elevate the MSI when running to resolve my issue. Not sure why your latest installers are working differently though. If there is nothing you can do then please close this as a bug. Thankyou for your time...

(In reply to Adam Clarke from comment #9)
> It appears to be an elevation issue.

You do not describe the exact scenario you use, it seems to be a huge obstacle. Are you trying to install/advertize per-user?

Anyway, LibreOffice MSI installer has *always* required a per-machine installation, and had never provided a per-user installation option (which is the only way a non-elevated installation could succeed). The intended operation in this case is explained at https://learn.microsoft.com/en-us/windows/win32/msi/installing-a-package-with-elevated-privileges-for-a-non-admin. No idea how that relates to SCCM.

Also: is there a way to test your failure *on a standalone system*, not connected to a domain, not managed by SCCM? E.g., as I said in comment 6, I used an elevated command prompt to call msiexec. When I used a normal, unelevated cmd.exe, it obviously silently failed (and Windows Event Viewer registered an error 10005, telling that current user has no rights to continue installation). Has this scenario (or some other, that can be reproduced) worked for 7.2.6?

(In reply to Mike Kaganski from comment #10)
> When I used a normal,
> unelevated cmd.exe, it obviously silently failed (and Windows Event Viewer
> registered an error 10005, telling that current user has no rights to
> continue installation). Has this scenario (or some other, that can be
> reproduced) worked for 7.2.6?

FTR: I tested this scenario ('msiexec /i D:\Downloads\LibreOffice_7.5.3_Win_x86-64.msi /quiet' command line using a non-elevated command prompt) with 7.2.6, and it (expectedly) failed, with the same error 10005 in event log.

(In reply to Mike Kaganski from comment #11)
> FTR: I tested this scenario ('msiexec /i
> D:\Downloads\LibreOffice_7.5.3_Win_x86-64.msi /quiet' command line

Oh, of course, the command line was a bit different :)

> msiexec /i D:\Downloads\LibreOffice_7.2.6.2_Win_x64.msi /quiet

Hi Mike

Sorry, poor choice of words. It is definitely the same issue as pmaynard I am having. When running in an SCCM task sequence it just hangs forever but if I add /norestart it fails and does not complete the task sequence. I’m really stumped on this one. Have there been any changes to the installers you know of since 7.2.6?

I can however now confirm that when I run it on a standalone machine when using elevated command prompt it does in fact work though...

I do appreciate your time looking at this for me though...

Jussi, I seem to remember you helped some recent changes to MSI installer - do you have an idea what could be the reason of this SCCM change between 7.2 and 7.4?

FTR: the changes mentioning "msi" after 7.2 branch-off are

https://gerrit.libreoffice.org/q/msi+branch:master+after:2021-06-07

I wonder if it could be the changes made to the WiX toolset? That would be my guess?

> do you have an idea what could be the reason of this SCCM change between 7.2 and 7.4?

Sadly no. All the changes I have been a part of have dealt with the new WiX installer and not the old Perl monstrosity. I have no idea how that works internally.

> I wonder if it could be the changes made to the WiX toolset?

None of the existing production installers use WiX to build. So no, that is very unlikely to be the case. You can only obtain the WiX-based installer if you build the code from scratch yourself and explicitly enable the WiX installer. And even that is not possible until this MR gets merged:

https://gerrit.libreoffice.org/c/core/+/151738

Hi Mike

As per your forum request I am slowly going through the archive and testing versions to see what works and what does not so I will let you know ASAP.

Thanks again...

Hi there

We're there any changes after 7.2.6 as I have tried 7.2.7.2 and this also fails so it looks like the very next release is the issue

(In reply to Adam Clarke from comment #20)
> I have tried 7.2.7.2 and this also fails

Really great.

Could you please also test version 7.3.1, 7.3.2 and 7.3.3 (if you haven't tested them yet)? These versions were released in parallel to 7.2.6 and 7.2.7, and I have some suspicion for a change in C runtime that happened between 7.2.6 and 7.2.7, and it also happened between 7.3.1 and 7.3.3.

If 7.3.1 would fail, it would be an evidence that it's not the C runtime, will dig further.

Hi Mike

I have just tried 7.3.0.1 and it works. Does this mean it is a C runtime issue then?

(In reply to Adam Clarke from comment #23)

And likely, 7.3.3 will fail?

Hi Mike

Have just tried 7.3.0.3 and this also works

(In reply to Adam Clarke from comment #25)
> Have just tried 7.3.0.3 and this also works

7.3.3.1 or 7.3.3.2 are interesting, I suspect that these would fail, while 7.3.2.* would still work.

This *looks* related to the change from Microsoft Visual C++ Redistributable for Visual Studio 2015-2019 version 14.28 to version 14.29, which happened between the last working and first affected versions, likely because at that time, a compiler update was applied on the builder system (so it was not a code change, but rather a compiler version change).

I can only speculate, that *if* this guess is correct, then *something* in SCCM does not allow to upgrade this *system component* - maybe this upgrade wasn't necessary using the "good" LibreOffice versions, because the managed systems already had that version, but when LibreOffice started to bundle the newer version, the system component upgrade requirement created the problem.

Can you now try to install a newer C++ Redistributable from MS (https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170, https://aka.ms/vs/17/release/vc_redist.x64.exe, current version is 14.36) on a managed system (either manually, or using SCCM - I have no idea how to do that), and then try if the problematic LibreOffice versions maybe start installing normally?

(In reply to Mike Kaganski from comment #26)
> change from Microsoft Visual C++ Redistributable
> for Visual Studio 2015-2019 version 14.28 to version 14.29

And this looks suspicious, reading the Configuration Manager Client prerequisites [1], which include a mention of "Microsoft Visual C++ 2015-2019 Redistributable version 14.28.29914.0".

*Possibly* it makes sense to open a ticket at MS at this stage; even if they find out that there's something to change in LibreOffice installer, at least they would be able to diagnose what was that. FTR, LibreOffice uses the redist MSMs (merge modules) included in MS Visual Studio.

[1] https://learn.microsoft.com/en-us/mem/configmgr/core/clients/deploy/prerequisites-for-deploying-clients-to-windows-computers#components-automatically-downloaded-during-installation

Hi Mike

I am currently wrestling with trying to get the 2015-2022 redist installed in a task sequence and it just fails constantly with an error code so I will let you know where I get with this ASAP...

Hi Mike

We don't have the ability to open a ticket with Microsoft with our schools agreement type so this is not an option for us im afraid. I have imported the latest VcRedist into SCCM using vcredist.com but it just fails to install in the task sequence with an unspecified error. I think I am going to have to deploy an older version this year 7.3.0.3 as I know that works which is a shame but I am in a position where I need to deploy my new image pretty urgently now so although I am keen to get a resolution the need to deploy the image is greater for me. I really appreciate all your help on this but I realise you cannot simply roll back the change either. Unfortunately it just means that deployment for the time being with Microsoft Endpoint Configuration Manager or the Microsoft Deployment Toolkit will not be possible with the latest versions.

(In reply to Adam Clarke from comment #29)

Thanks for the update.

> We don't have the ability to open a ticket with Microsoft with our schools
> agreement type so this is not an option for us im afraid.

Too bad...

> I have imported
> the latest VcRedist into SCCM using vcredist.com but it just fails to
> install in the task sequence with an unspecified error.

It looks very pathetic on the SCCM side, and suspiciously related to the issue here - note how SCCM struggles to deploy the suspected MS system component update, packaged by MS themselves... Honestly, *for now* it truly looks like a bug (or some misconfiguration) in SCCM.

> I think I am going
> to have to deploy an older version this year 7.3.0.3 as I know that works
> which is a shame but I am in a position where I need to deploy my new image
> pretty urgently now so although I am keen to get a resolution the need to
> deploy the image is greater for me. I really appreciate all your help on
> this but I realise you cannot simply roll back the change either.

You are right: the change between the versions happened because MS (again MS! :D) released an update to their Visual Studio; and many (most) of their updates include security fixes - which means, that not updating not only puts our builder in danger, but -more importantly - may put the users in danger, if they use programs compiled using unfixed compiler. We need some clear resolution here.

> Unfortunately it just means that deployment for the time being with
> Microsoft Endpoint Configuration Manager or the Microsoft Deployment Toolkit
> will not be possible with the latest versions.

Sorry for that; let me close it as NOTOURBUG - but feel free to reopen, if you happen to get a new bit of useful information.