How to Effectively Troubleshoot Patching Related Issues in EPM

Introduction

When facing a Patch Manager issue while using Endpoint Manager there are a few tips you can follow to make it as effective as possible and reduce the amount of time it takes to resolve a support ticket. Providing accurate and detailed information can help your support engineer identify and resolve a patching issue quickly and efficiently. This document will outline best practices on how get all the necessary information to fixing patch related issues. Also, the hope it can provide some information to our customers to identify issues on their own.

Quick reference for support tickets:

Log.zip - Support will request the full 'Log' folder located on the client C:\Programdata\Landesk. For more effective logging and information see the Logging section

Vulnerability ID(s) - If we are dealing with a specific patch, having the Vulnerability ID(s) will help support identify the problem patch faster without the need to inquire for that information. When dealing with 10+ vulnerabilities provide 2-3 examples.

The behavior of the patch when manually run outside the Ivanti product - This is important to know the behavior outside the product to know the expected behavior the OS takes. You'll want to inform the engineer of this behavior.

Logging

Logs are the most important information you can sent your support engineer when opening a ticket. This gives detailed information of the patch process so you or the support engineer can identify the cause of the issue. There are a few things to keep in mind when raising a ticket with support.

Vulscan.log - Make sure that the issue resides in your vulcan.log(s). You'll want to make sure the issue resides in those logs in order for support to follow the process flow leading up to the failure and completion. It is important that, if possible, the vulscan process completes this provides a return code support can use to identify the general issue. For more information on return codes take a look at About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes. It is always a good idea to send logs from a client that has very recently been able to replicate the issue.

STDeployerCore.log - Since the introduction of our Next Gen patches this log has been added to identify the results of the patch installation attempt. One of the most important pieces of information contained in this log is the windows return codes that the client returned when attempting to install the patch. If a patch is failing this is an excellent place to start in determining what reason for failure is. Here is an example of a unsuccessful patch install

2018-07-16T10:41:08.0014620Z 044c V UnScriptedInstallation.cpp:30 Executing (C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows10.0-kb4343669-x64-1803_tw15004-40546.msu /quiet /norestart), nShow: true.
2018-07-16T10:41:11.2981195Z 044c V ChildProcess.cpp:140 Process handle 00000730 returned '2149842967'.
2018-07-16T10:41:11.2981195Z 044c W DeployerImpl.cpp:106 Patch state is 'Failed'. Registry bread crumb patch state not updated.

Here you can see '2149842967' this is the windows return that the patch returned. A quick web search will assist you in determining what that return means and how to handle it. In this example it is a return of 'Not applicable for this machine' this is a detection logic issue from Ivanti and should be brought to the attention of support. It is helpful to run the patch manually to see if you get a similar result, support will want to know this.

Your Support engineer may request other logging if they find it applicable.

Helpful Links:

About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes

System Error Codes | Microsoft Docs