This article explains how to evaluate technical issues during the installation of SPS packages. It also includes valid points and considerations to help you work with packages in a simpler way.

Symptoms

You create an SPS package and deploy it via WSUS or SCCM server. The package installs on many machines, but some failed to install the package.

Viewing C:\Windows\SecuniaPackage.log The failing systems show error code 1603 after the SPS package installation was initiated.

Error 0x80070643 displayed in System Center Configuration Manager, or within the WindowsUpdate.log file (if publishing via WSUS).

Causes

The package that fails might be a 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 was installed with the MSI installer, which is no longer present on the system, so it cannot be uninstalled.

• Error code shows on the screen when you try to remove the old version manually. It says the original MSI installer is missing, and it leaves the error window open.
• This can cause SPS packages to install incorrectly because the MSI installer requires input, but that input is hidden behind BITS, and the application has no way to continue.
• The package you deployed cannot take the 'user action' because it installs silently, which prevents the SPS package from proceeding with the removal.
• Eventually, Windows Update will reach timeout deadline and produce an error code 0x80070643

Solution

Remove previous versions by either deliberately placing another Uninstall.exe in the same folder where the old MSI is looking for it, or by removing all versions manually before installing anything new. 

EXE vs MSI incompatibility [Most Frequently Seen]

Several major third-party vendors provide both EXE and MSI installers that do not work well together; Adobe, Oracle, and Google are among them. 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 Software Vulnerability Manager uses MSI-based installers from Adobe to patch your hosts. 

Solution

To successfully install SPS packages in such cases, the previously installed software must have been installed with an MSI-based installer. Use the Clean Install option at step 1 of SPS to clean up the EXE from any system before your SPS update patch triggers installation, thereby avoiding a collision, since the system will be cleaned in advance via 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 when 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 built 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 because it was destined to fail. It will install at the very latest on the next restart. 

• Error 1603, particularly 0x80070643, might sometimes indicate that the version to be patched is locked to the user's Security Identifier (SID).

Solution

Reboot the system gracefully, and the package that failed with a 20/32 error will then perform a graceful installation, since the system will have already logged off the user UID and Windows Update will encounter no issues replacing the program files.