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).
How the failure looks like through SCCM deployments
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:
Missing old MSI Installer
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.
Error code shows on the screen when you try to remove the old version manually. It says that the original MSI installer is missing and it leaves the error window pending.
This can fail the SPS packages to install correctly because the MSI installer requires input, but the input is hidden behind BITS, and the application has no way of getting to continue.
The package you deployed cannot take the 'user action' because it installs silently, which leads to the SPS package being blocked to proceed with the removal.
Eventually, Windows Update will reach timeout deadline and produce error code 0x80070643
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.
EXE vs MSI incompatibility [Most Frequently Seen]
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.
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.
3. Another SID/UID is using the process
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.
Error 1603 and particularly 0x80070643 might sometimes be an indication that the version that is to be patched was locked to the user Security Identified (SID).
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, 201911:50 AM - edited on Sep 16, 201901:36 PM by RDanailov