Troubleshooting Failing SPS Package on a Target

[#1]

Summary

This article describes the general steps that can be taken to troubleshoot a package that was published by the Software Vulnerability Manager and its Flexera Package System where the package was provided as silently installable out-of-the-box through the default installation configuration enabled by Flexera. 

SPS packages as they are known are advanced installers which [1] contain the vendor installer that the vendor intended and delivered to the public [2] while also containing  improvements in the package installation handling procedures that create a bridge between the WUA functionality and all the supported for silent installation third-party software vendors together with their disadvantages. 

Customers using SVM or SVR solutions are welcome to contact support if they want to achieve specific scenarios with their Flexera products and that extends to patching where Support can be helpful. 

Synopsis

A Secunia package (sps.exe) contains a minimum of two files.

One file is the script that executes the installer that comes at index 1 (2) as the second file in the package execution flow. The script sets package execution logging to occur at C:\Windows\SecuniaPackage.log. This file contains all relevant installation information regarding the SPS package and it is heavily used for detecting problems and error codes that need solving.

You should always try your luck looking at C:\Windows\WindowsUpdate.log too. Windows Update Agent handles the execution of packages for both WSUS and SCCM, and it represents the parent executory process of the SPS.exe installer threads that start underneath WUA's PID. That's where data comes first. 

Discussion

Troubleshooting package deployment:

1. Open C:\Windows\SecuniaPackage.log on the system where the package was deployed.

At this point:

If the package has started installing, it would have written anything, error or success.
If the package did not write anything, then the package never started running.

Next steps: If Error

If you have an error for that same package, try finding more about it in the current KB article. 
If the error is not listed here, try finding another KB article in the community as there are few others.
No success should leave you with a good choice to send it to Support and we'll help with our best.

Next steps: If no Error

When the package is executed it will have the type of reference as shown next:

[08/18 10:59:38.257 00000fa8] Running package Deployment package for Secunia CSI Agent, version 7.1.0.3, created Tue Aug 18 2015 10:58:56 GMT+0200 (Romance Daylight Time)[08/18 10:59:38.267 00000fa8] GUID : 7f72ff70-1530-420a-8280-983588115663

When the Windows Update Agent runs the downloaded patch successfully, you will see return code 0.

[08/18 11:00:00.873 000003b0] Finished running package Deployment package for Secunia CSI Agent, version 7.1.0.3, created Tue Aug 18 2015 10:58:56 GMT+0200 (Romance Daylight Time)
[08/18 11:00:00.885 000003b0] Returning 0

If you don't see a reference to the package, this could be caused by the deployment script not being run.
You should look in WindowsUpdate.log to get an insight on what did WUA report back as a result too.

Often this log file will contain the root cause of the failure. Does it say anything about the package you are expecting?  Are you able to find the package when you use Ctrl+F and the name of the package? If the answer is no, this means that your package is not applicable to that system.

Briefly explained, each package contains applicability stamped on it just like a post letter has stamps. It can and will be delivered only when the recipient of the patch, that is every client in the domain, indeed matches all required rules. Briefly, these are patch applicability, version applicability, and approval. 

Finally, some particular reasons for a package failure can be:

- Internal Installer Error

- WUA executes through LocalSystem and this account doesn't have access there, where the system requires authentication with password requirements.

For instance, the LocalSystem account cannot anything that has a requirement for password exchange and authentication packages trying to install in C:\Users will fail via WUA installation because that requires a UAC permission bypass and LocalSystem can't handle the password part. 

Error Codes and Useful References:

These are Windows system error codes that can be compared against:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx

Common System error codes are :

ERROR_SUCCESS

0 (0x0)
Description: The operation completed successfully.

ERROR_SHARING_VIOLATION

32 (0x20)

Description: The process cannot access the file because it is being used by another process.
(This could be the case while updating Adobe Flash or Oracle Java, where Java/flash is at that moment actively running in the browser or as a process and the uninstaller can not access the locked file.

ERROR_INSTALL_FAILURE

1603 (0x643)

Description: Fatal error during installation.

Find more about this error in the hyperlinked KB article. 

ERROR_INSTALL_SUSPEND

1604 (0x644)

Description: Installation suspended, incomplete.

ERROR_UNKNOWN_PRODUCT

1605 (0x645)

Description: This action is only valid for products that are currently installed.

ERROR_PRODUCT_VERSION

1638 (0x666)

Description: Find more about this error in the hyperlinked KB Article. 

Another version of this product is already installed. The installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs in the Control Panel. This could be the case while updating Adobe Reader, where Adobe Reader installer fetches some old registry setting that point to a previous Adobe Reader update location/path/MSI file.

Detecting and removing this path from the registry resolves the issue. To do so, download the Adobe reader update installer from adobe and run it via the GUI, the installation should stop requesting an MSI file at a specific location/path. If this event occurs, you will have reversed the problem and allocated it. 

Packages in which failure is associated with an MSI installer may be failing to obtain the source MSI file to proceed with software removal before update or an upgrade. Sometimes the MSI installer will be missing on the system. Then, in the middle of a BITS-orchestrated operation, the installation is blocked and no message can be returned to the user. The installer waits for a little and it times out, errors out.