This article explains how you should evaluate technical problems with the installation of SPS packages. It also includes valid points and considerations to help you working with packages in a more simple and straightforward fashion.
You create an SPS package and deploy it via WSUS or SCCM server. The package ends up installing on many machines, but some/many failed to install the package.
You looked at the C:\Windows\SecuniaPackage.log on the failing systems and you determined error code 1603 to be returned after installation of the SPS package initiated.
You might have also noticed similar error 0x80070643 displayed in System Center Configuration Manager, or within the WindowsUpdate.log file (if publishing via WSUS).
The package that fails might be different kind - Adobe Flash, Adobe Reader, Adobe Acrobat, Java, Google Chrome, etc. You might have several different packages failing at the same time on some machines.
For example, on machine A you might have Flash and Chrome failing, while on machine B you only get Chrome failing and only Flash failing on machine C. The symptoms may vary on a per-case basis, but as long as you have these error codes you shall focus on finding which of the following causes is the source:
The old-version you are trying to patch had been installed with MSI installer and this installer is no longer present on the system which makes it impossible to uninstall it.
Solution:
You need to remove the previous versions by either purposely placing another Uninstall.exe in the same folder where the old MSI is looking for it, or you should remove all versions manually prior to installing anything new.
Several major third-party vendors provide both EXE and MSI format installers which actually do not work well with each other i.e. Adobe, Oracle, Google is all in that count. When the old version that needs to be patched was installed with an EXE installer (that is the version installed on the Clients), Flexera packages may throw this error because SVM uses MSI-based installers from Adobe to patch your hosts.
Solution:
To install SPS packages successfully in such cases, the previously installed software must originate from an MSI-based installer. You should use the "Clean Install" option at step 1 of SPS to cleanup the EXE from any system before your SPS update patch triggers for installation, thereby avoiding the collision since the system will be cleaned in advance through the registry Uninstall string of the old EXE installer.
The old version that requires patching may be used by a user at the time of applying our patch. Thus, Windows ties the process to the UID and the new package installation fails because it cannot take over the process, stop it, remove it, and update it to a newer version thereafter.
Flexera SPS packages are build to detect if a possible problem will occur and will normally produce additional exit/error code 32. When you see code 32, know that the package was canceled as it was destined to fail otherwise. It will install in the next restart at the very latest on its own.
Solution:
Reboot the system gracefully and the package that failed with 20/32 error will then perform gracefull installation since the user UID will have already been logged-off by the system and Windows Update has no issues to encounter in replacing the program files.
on Feb 27, 2019 11:50 AM - edited on Sep 16, 2019 01:36 PM by RDanailov