Hi folks,
It looks like there’s some disruptive behavior on older operating systems when upgrading LibreOffice to the latest available versions if the upgrade is run via a custom SCCM package.
Upgrades on Windows 10 machines act normally, but earlier operating systems can run into issues if the local box’s Windows update processes are already in use. (This can happen when users install an update, if a recently installed update is still pending a restart, or if the deployment happens as a custom package through SCCM.)
That last one runs into issues when the recent Libre installers attempt to install the CRT update - essentially, SCCM is already busy with wusa.exe when it’s instructed to install KB2999226.
Behavior for 6.2 Branch : The installation fails silently when the KB attempts to install, and any existing LibreOffice is removed. I simulated this scenario to get the info below, if there’s anything more helpful to include please let me know.
Event Viewer : returns Error 2147944018 from wusa.exe (“Another installation is already in progress. Complete that installation before proceeding with this install.”).
Logs : See hosted “log-6.2.7.1-x64.txt” and “log-6.2.7.1-x86.txt”.
Behavior for 6.3 Branch : The installation fails if deployed as part of a SCUP package / custom SCCM update. It will reach the point where it shows Error 2500, then fail with the same event ID from wusa.exe.
Question - is it possible to update the new installers to be compatible with SCCM-based deployments?
It already seems to handle similar scenarios smoothly, so I’m hoping this could be as simple as adding a return code. As it stands, anyone using SCUP / SCCM to update Libre 6.2 will only be able to push out updates that remove the software.
(Backup question - failing the above, is there a way to force the installer to run without attempting to install that KB?)