- Settings
- Product Licensing
- Registry Keys
- Gathering information for Ivanti Support
- Tips and Tricks
- Ivanti Patch and Compliance (vulnerability) Scan Process Flow
- Step 1 - Contact the Ivanti Core Server
- Step 2 - Core downloads and applies various agent settings
- Step 3 - Vulscan loads and caches local MSI information
- Step 4 - Client requests vulnerability data information from core
- Step 5 - Vulnerability scanning results are sent to the core server
- Step 6 - Vulnerability scanner checks for autofix patches
This document illustrates the files, registry, settings and other information necessary to effectively troubleshoot a vulnerability scan.
In addition, this document walks through the steps that a basic Patch and Compliance scan (otherwise known as a vulnerability scan) takes.
This article will not describe every single step that the Vulnerability Scanner takes, but those steps where a failure can occur.
For the purposes of this document a simple scan is performed by running the following at the client command line:
vulscan /scan=0 /showui
This command tells the vulnerability scanner to scan Windows vulnerabilities (type 0) and to show a user interface.
More information about vulscan command line switches.
The name "LDMS2016" and "LDMS2016_v###" will be seen throughout this document. This refers to the Core Server name of "LDMS2016" which is the name of the core server that the author had when creating the document.
Settings
The settings that control how the vulnerability scanner will behave are stored in the Distribution and Patch Settings within the Agent Settings tool.
These settings control behaviors such as user input options, Cloud Services Appliances patch options, scanner CPU utilization, etc.
These settings are stored in the Ivanti EPM Database in the AgentSettings table and physically on the core server in the
\Program Files\LANDESK\ManagementSuite\ldlogon\AgentBehaviors folder. The Distribution and Patch Settings are stored in the AgentBehavior_(Corename)_v###.xml file within this folder.
Example
Product Licensing
The categories available to scan and repair are controlled by the Product license that has been purchased and activated on the core server.
The following graphic shows the categories available within the Download Updates function within the Patch and Compliance tool for those with a license for all categories.
Click for full size
For Product Licensing support Contact Ivanti supportand select the Product Licensing option.
Registry Keys
Core
HLKM\Software\LANDESK\ManagementSuite\PatchManagement\WebServiceMaxThreads
This key does not exist by default and should only be created with an understanding of how this key works and the full ramifications of creating this key and changing the default value. This changes the number of default threads
This key is documented here: https://community.landesk.com/docs/DOC-36027#jive_content_id_Increasing_the_Number_of_Web_Process_to_Database_Threads
Client
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\WinClient\Vulscan
This registry key contains the following information:
| Name | Type | Data | Description |
|---|---|---|---|
| AgentBehavior | REG_SZ | LDMS2016_v495 | The agent behavior that vulscan will use when operating |
| AlternateRebootBehavior | /rebootIfNeeded is called from 3 possible locations during a client configuration. It is hard for the task-handler version of the caller to know that a one-time-only (client-config-only) reboot override has been specified. So all installers just call vulscan with the /UseAlternateRebootBehavior. If vulscan can find the string value of "AlternateRebootBehavior" in the vulscanreg key, it'll act as if the behavior was passed by the command line. | ||
| CommandLine | REG_SZ | The command line that was used to launch vulscan | |
| ComputerIdn.LDMS2016 | REG_DWORD | 0x00000006 | When running in a /showui mode the ComputerIDN is accessed locally from the registry rather than needing a separate GetSystemIDN for the UI through a second web service call to the core. This value matches the ComputerIDN identifier in the Ivanti Endpoint Manager database. |
| KLBehavior | REG_SZ | LDMS2016_v517 | This refers to the Ivanti Antivirus behavior. This will exist even if Ivanti Antivirus is not installed on the client. |
| LastReportedReboot.LDMS2016 | REG_DWORD | 0x00000001 | |
| trustedfilelist | REG_SZ | LDMS2016_v861 | Trusted file list used for Ivanti Endpoint Security. This will be present even if EPS is not installed or trusted file lists are not configured for this client. |
Note: The populated "Data' entries are provided as an example. Yours will differ.
The VulscanReboot key should NOT be modified, deleted or created. This is a volatile registry key used by the vulnerability scanner. Creating this key manually will create a persistent registry key that does not go away and will cause reboot loops and/or other undesirable behavior.
Gathering information for Ivanti Support
The vulnerability scan log files are located in the C:\ProgramData\LANDESK\log folder.
When in doubt just .ZIP up the entire folder and send it.
Otherwise, the following logs should be gathered:
- vulscan*.log
- statusdlg*.log
It is very useful to turn on Xtrace with the following enabled from the registry key prior to duplicating the problem and gathering logs:
From HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\LogOptions:
How To: Enable XTrace Diagnostic Logging for the Ivanti Core and Clients
Tips and Tricks
Vulscan can be used as a shortcut to open various folders. The following should be run on the client command line:
Vulscan e - Open the folder where Vulscan resides
Vulscan c - Open the LDClient folder,
Vulscan log - Open the ProgramData\LANDESK\Log folder
Issue: Cannot open vulscan logs folder from the command line using "vulscan e"
Ivanti Patch and Compliance (vulnerability) Scan Process Flow
It is important to note that the following must all be able to take place: Client contact to core through IIS and several web services. Core contact to Database Server Core Contact to client Correct permissions on core ManagementSuite\Incoming directory and \ManagementSuite\LDLOGON\VulnerabilityData and VulscanResults folders.
Note that issues can come and go during a vulscan. This would indicate intermittent issues. Most of the time this occurs when the server or database has connectivity issues or are too overwhelmed to respond to requests.
Step 1 - Contact the Ivanti Core Server |
|---|
The vulscan engine attempts to contact the core server by checking the HKLM\SOFTWARE\Intel\LANDESK\LDWM registry key. The client tries to contact vulcore.asmx through the WSVulnerabilityCore web service. Thus the client needs to be able to contact the core, IIS needs to be available, the app pool needs to be running, and the database needs to be able to contact the core.
Good Vulscan.log entry
|
What could go wrong? Certificate-Based Authentication - New Secure Client information
Ivanti Endpoint Manager Enhanced Security Mode
If core has been upgraded and you have copied the .CRT, .KEY and Client unable to connect to the core server
Error: "Host not found. Retrying" Bad vulscan.log entry:
The client makes a SOAP request to the core server webservice and gets HTTP error 503 - Service Unavailable
Note: The default timeout for Vulscan to connect to the core is 10 minutes. Connection will fail after this time.
Useful ArticlesIIS Troubleshooting and Ivanti Endpoint Manager: 101 How to troubleshoot IIS using Log Parser Studio from Microsoft
Core server unable to talk to the database
This error shows that something is wrong with the core to database communication or web service to database communication. This can be a simple connectivity issue, database too busy, IIS/ASP.NET, etc.
Error: "Server busy"
Bad Vulscan.log entry:
The client does a SOAP request to the core web service to resolve it's device ID and gets HTTP Error 500 - Internal Server Error
|
Step 2 - Core downloads and applies various agent settings |
|---|
At this step the core server downloads and applies various agent settings. If a setting does not apply to the computer the file will be downloaded anyway. (For example, if you have Endpoint Security in your
Good Vulscan.log entry
The client checks it's file hash for the behavior file and compares it through a SOAP request to the core web service function "GetHashForFile". It then applies the behavior to the client. |
What could go wrong? Client cannot access the AgentBehaviors folder on the core server
The client needs to be able to access the \LDLOGON\Agentbehaviors folder on the core server. It then downloads the agent behavior .XML files and applies them if they pertain to the computer, otherwise the settings come down, but they are not applied.
Error: " 'Applying XXX settings failed" Bad vulscan entry:
Useful ArticlesIssue: Vulscan is not applying agent setting changes or is using an incorrect agent setting Error "Unable to get the setting from core" when running security scan (Vulscan.exe) Error: "Core could not find a file" when running vulscan on clients Error: "Failed to apply compliance settings" during vulnerability scan return code 451 |
Step 3 - Vulscan loads and caches local MSI information | ||
|---|---|---|
In order for the vulnerability scanner to scan MSI information, the vulnerability scanner reads and caches the MSI information from the local computer's registry. This calls the MsiEnumProducts and MsiEnumPatches functions. This depends on the existence of MSI.DLL in the C:\Windows\System32 directory.
Vulscan.log entry:
| ||
|
Step 5 - Vulnerability scanning results are sent to the core server |
|---|
After scanning the results are sent to the core server through http://<corename>:443/WSVulnerabilityCore/vulcore.asmx. At this point the Web services processes the results and creates a scan result file (in this case ScanResults_{A25894AD-E7E7-C042-86AB-5F8BBD866601}_0.vrz) that goes into the \Program Files\LANDESK\ManagementSuite\VulscanResults folder on the core. This gets processed into the database and will show up in the Security and Compliance information for the client in the inventory.
Good vulscan.log entry
What can go wrong? Failures to send the results can come from some of the following issues:
Failure in vulscan.log
In this case the postcgi.exe was missing in the incomingdata folder. The service responded with an HTTP 404 error "File or directory not found".
Additional articles: |
Step 6 - Vulnerability scanner checks for autofix patches |
|---|
The vulnerability scanner then checks with the core server to see if there are any patches that should be auto fixed at this time. This is done through the http://localhost/wsvulnerabilitycore/vulcore.asmx web service using the GetAllPatches function. If patches are found that need to be auto fixed one of the following methods is called:
The core then builds a list of the repair logic that vulscan will follow and it gets sent to the client through the web service, the client then writes an .XML file to follow as it repairs patches. This information is all of the repair logic from the definition. |