cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Users often require additional help for the logical process workflow when it comes to integrating the Software Vulnerability Manager 2019 software to their internal WSUS or SCCM servers for patching.

In most, users need additional elaboration on what is the right sequence of steps to integrate SVM and what actions will be needed to troubleshoot expected errors that come in their way as part of the deployment process. 

Flexera has made a logic flow map that provides essential knowledge of the steps involved to integrate the SVM to your internal server infrastructure and the steps to troubleshoot basic errors or exceptions that might come in your way while you're performing this process. We also provided an extensive amount of additional information that can help you investigate package errors in the different phases of the deployment process of a package made with SVM and handled for deployment in WSUS/SCCM/CCM.

Customers are highly encouraged to follow this diagram at their best effort, before reporting support cases to Flexera Support, as they would also receive a greater knowledge in learning each step of the integration while following the diagram. 

Patching Process.PNG

You can download the attached PDF document under this KB for a better resolution of the logic map. 

Customers are highly advised to include the relevant log files that enable visibility when they send their cases to the Flexera Support team. Depending on where the problem occurred (in which phase), the following log files can be relevant:

1. Patch Creation phase: 

If there was a technical problem not covered by the logic flow map, the first course of action should always be to search the error you see inside this Flexera Community site, as Flexera Support issues KBs for each new error that is detected with customers. The chance of finding a solution here is very high. 

If that did not help you solve the issue or move further in the mapping process, find the "%userprofile%\My Documents\csi_pluginlog.txt" file on the system where you tried creating a patch and submit that to our Support team adding as much as information about your case as possible. 

2. Patch Deployment phase: 

The patch was published successfully, but there is an issue with your WSUS server not sending the update to the recipients you approved it for. This may be expected if the recipients did not have the same software already installed (hence, the patch is not applicable, that's why it is not showing up). This is where you have to check the patch applicability rule configured in the SPS wizard -> steps 3 and 4 and verify all enabled requirements of the patch against the clients not receiving it. 

If the patch was published to SCCM, you should first and foremost ensure that your SCCM/WSUS (SUP) configuration is intact. If it is and you're successfully publishing Microsoft patches that way, then you can troubleshoot the wsynclog.log file for errors that might shed more light on what is causing a problem with the synchronization of the patch between the WSUS DB and the SCCM's own database. 

3. Patch Download/Installation phase: 

If the patch has shown up and you've deployed it to hosts, but the hosts failed to install it, you can look into the respective client logs for the CCM Client service, Windows Update, or the Secunia Logs as well:

a) Check C:\Windows\SecuniaPackage.log for any traces of installation - did package ran to install?

- If it ran - patch applicability rules are fine - there's an execution error, however. 
- If it did not run at all and there are no traces of that - there are most likely patch applicability issues or management point download issues. Such problems can be diagnosed in the log files (to name a few):

C:\Windows\CCM\Logs\UpdatesDeployment.log
C:\Windows\CCM\Logs\UpdatesHandler.log

b) If the patch ran and there's an obvious error in the SecuniaPackage.log file - check the "C:\Windows\WindowsUpdate.log" file next. You can also find more information on the CCM->WUA patch passing in the C:\Windows\CCM\Logs\WUAHandler.log file.

Windows Update is the last service to touch the patch upon execution and the first one to handle the incoming errors - disregarding if you use SCCM or WSUS - that's the case for both scenarios. This log file will contain many lines of error description that you can check against MS Technet first.  

c) If you deploy patch via SCCM and your WUA service, CCM service, and SecuniaPackage.log all indicate that the package was installed correctly (hence, exit code = 0), but your SCCM is showing wrong compliance of the patch, then you are likely to be looking at a known bug in the CCM "state message" handling of the CCM service that transmits the wrong execution status to its server (for which you can only talk to Microsoft about as Flexera cannot be helpful to solve known CCM-related bugs).

This issue can be identified using some of the following logs:

C:\Windows\CCM\Logs\StateMessage.log
C:\Windows\CCM\Logs\SCNotify_<domain>@>WindowsUsername>
C:\Windows\CCM\Logs\SCClient_<domain>@>WindowsUsername>

as well as the following local WMI classes where CCM stores the incorrectly handled package execution status, and the incorrect state messages being sent to the SCCM server database (to name a few):

root\ccm\SoftwareUpdates\UpdatesStore -Class CCM_UpdateStatus
root\ccm\SoftwareUpdates\DeploymentAgent -Class CCM_TargetedUpdateEx1
root\ccm\SoftwareUpdates\DeploymentAgent -Class CCM_AssignmentCompliance
root\ccm\ClientSDK -Class CCM_SoftwareUpdate
root\ccm\SoftwareUpdates\WUAHandler

Was this article helpful? Yes No
100% helpful (1/1)
Version history
Last update:
‎Dec 27, 2019 07:38 AM
Updated by: