Issue

Gather Historical Information crashes the LANDESK Console.

Gather Historical Information task is failing to run.

Following is in the GatherHistory.Details.Log file in the Managmentsuite\Log folder on the Core Server:

09/18/2014 15:12:18 INFO  13352:SaveTrendInfoForVulnerabilitiesAsync : Critical Exception: System.Data.OleDb.OleDbException (0x80040E31): Query timeout expired   at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)   at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQueryP(String sql, Int32 timeoutSeconds, Object[] parameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql, Int32 timeoutSeconds, ArrayList oleDbParameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql)   at LANDesk.ManagementSuite.PatchBiz.PatchTrend.SaveTrendInfoForVulnerabilities(Int32 removeOldDataDays)   at LANDesk.ManagementSuite.PatchManagement.ProgressForm. € ()   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)   at System.Threading.ThreadHelper.ThreadStart() Stack Trace:    at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)   at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQueryP(String sql, Int32 timeoutSeconds, Object[] parameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql, Int32 timeoutSeconds, ArrayList oleDbParameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql)   at LANDesk.ManagementSuite.PatchBiz.PatchTrend.SaveTrendInfoForVulnerabilities(Int32 removeOldDataDays)   at LANDesk.ManagementSuite.PatchManagement.ProgressForm. € ()   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)   at System.Threading.ThreadHelper.ThreadStart()   

Solution

1. Close the Ivanti EPM Console.
2. Create the "Query Timeout" registry value as a 32-bit DWORD in the following registry key on the Core Server:
   
   

9.6 or 2016 Core Server:

HKLM\SOFTWARE\LANDesk\ManagementSuite\WinConsole

Create any registry keys that are missing. Set the value to 10000 decimal.

• • Purpose
  • How to use Manually Downloaded Patches
  • What if the patch still shows Not Downloaded?
  • Submit a Support Ticket
  • Clone Definition for Use
  • Patch Properties That are Checked
    • File Name
    • Sha1
    • MD5
    • How to manually check hash values
      • Using the Ivanti Endpoint Manager Database
      • Using 3rd Party Utility

Purpose

This article covers how patches are validated within the Patch Repository, and how to make use of manually downloaded patches.

Related: Why certain vulnerability definitions require the patch to be manually downloaded?

How to use Manually Downloaded Patches

• Download the patch desired
  • If the definition lists the patch as _Manual, it is not available for download from Ivanti Endpoint Manager. You will need to find a download source for the patch manually.
• Copy the downloaded patch, into the patch repository
  • Patch repository is defined under Tools | Security and Compliance | Patch and Compliance
  • In the Patch and Compliance window click Download Updates

• In the Download updates window, click Patch Location
• UNC path where patches are stored represents the Patch Repository share

• Rename the file to match the Patch Name shown in Ivanti Endpoint Manager

• In the LDMS console, right click the patch, and choose Download Patch...

• The patch repository will be checked for files that match based on name, then will compare hash information.
• In the Downloading Patches window
  • Since the patch does not contain download information, it will be listed as 'skipped'
  • Click Close

• If the Patch is still listed as Downloaded - No, close the Patch Properties window, then reopen the properties
• If the file passed validation, it will now show as Downloaded - Yes

What if the patch still shows Not Downloaded?

In order to use a manually downloaded patch with Ivanti Endpoint Manager, it will need to be placed in the patch repository, and certain properties will have to match what we know of that file.

If there is a mismatch, the file will not show as downloaded, and therefor not be available for use in a repair task.

Example: Patch jdk-8u45-windows-x64.exe was manually downloaded, and placed in the patch repository, but it continues to show 'No' in the Downloaded column.

Submit a Support Ticket

If the patch downloaded has the LDMS name, is located in the patch repository, and still does not show as Downloaded, there is likely a hash value mismatch between the file that was downloaded and the hash value in the Patch table of the Database.

If LDMS content is outdated compared to the current correct hash values of a patch, a ticket should be submitted to Support indicating this so it can be corrected.

Example:

Issue: Patch downloaded, placed in patch repository, has LDMS File Name, but does not show as downloaded.

Vulnerability ID: JREJDKv8U45_Manual

Patch Name: jdk-8u45-windows-x64.exe

Patch Download URL (if available): http://download.oracle.com/otn/java/jdk/8u45-b15/jdk-8u45-windows-x64.exe

Note: Including the URL you obtained the patch from will allow LANDESK to check the hash values of the file in-house, and determine if the hash should be updated within content.

Clone Definition for Use

It is always recommended that hash mismatches be submitted to Support so it can be addressed from a Content perspective.

Once this is done, if you are needing to patch the affected definition in the interim, it can be Cloned for use with LDMS.

Content downloaded from LDMS is 'Read Only' and cannot be modified. Cloning a definition however creates a customizable copy of the definition, with all detection rules intact.

• Right-click the definition and choose Clone

• In the Properties window:
  • Enter a unique ID
  • Double click the desired patch to open its properties

• In the patch properties window:
  • Click Detection Logic | Patch Information
  • Verify the Unique Filename matches the name of the file as it shows in the Patch Repository
  • Click Calculate Hashes
    • A green checkmark should appear next to MD5.
    • Typically SHA-1 and SHA-256 will get checked as well, but if not that is ok.
  • Click Ok
    

• In the Definition Properties window, click Ok.
• Open the new Custom Definition, and choose to download the patch

Because the custom definition for the patch has the name of the file in the patch repository, and the hashes match (because they were obtained directly from the file), it will show as Download = Yes now.

This custom definition can be used to Scan and Repair vulnerabilities accordingly.

Patch Properties That are Checked

File Name

The first property checked to match a file to a patch definition is its filename. The Filename must match the LDMS Definitions name for the patch exactly.

Typically downloading the patch from the vendor will yield the same filename that LDMS checks for:

Example: Downloading the patch Java Runtime Environment (JRE) 7 Update 71 patch from the vendor, will download the file with a name that matches the name LDMS is looking for. To place this file in the patch repository, would be a match based on name.

Name: jre-7u71-windows-i586.exe

Download URL: http://javadl.sun.com/webapps/download/AutoDL?BundleId=97807

In some circumstances however, the patch name LDMS is looking for may vary from what the patch downloads as from the vendor.

Patch names must be unique for LDMS to distinguish between them. Some vendors give their patch files a generic name, which if downloaded manually, would need to be renamed to match the LDMS patch name.

Example:

Downloading Google Chrome 45.0.2454.101 from Google downloads a file called  googlechromestandaloneenterprise.msi; there is nothing unique about this file name.

In order to differentiate it amongst the other multitudes of Chrome patches, LDMS looks for a filename of GoogleChromeStandaloneEnterprise_45.0.2454.101.msi

If the file was downloaded with a name that does not match the LDMS Patch Name, the file must be renamed to match the LDMS Patch Name..

Sha1

If the patch has a SHA-1 Value available in the database, it will compare this against the file's SHA-1 value to determine if the patch found based on filename is the same patch that is expected. By verifying this hash value, LDMS prevents distributing wrong patches that happen to have the name of a patch. If the SHA-1 value of the file does not match what is listed in the database, the file will not be listed as 'downloaded'.

The SHA-1 value is stored within the Database's Patch table in the SHA1 column as a Base64 encoded value.

Note: Patches may contain SHA-256 values, however these are currently not compared when analyzing if the patch exists within the patch repository.

MD5

If there is not a known SHA-1 value available for the patch in the database, Ivanti Endpoint Manager will use the known MD5 value to identify if the patch is the correct file.

The MD5 value is stored in the Database's Patch table in the Hash column as a Base64 encoded value.

How to manually check hash values

The hash values are only available from the database, in the Patch table, not through the LDMS console.

The values are stored as Base-64 encoded values.

Using the Ivanti Endpoint Manager Database

If the definition was cloned for use, the patch had its hash values gathered during the process and are available in the Database.

The following query will return the patches associated with the Custom definition, and display their Hash (MD5) and SHA1 value.

Select vul.vul_id, Patch.Name, patch.Hash, patch.SHA1
From Patch
Inner Join Vulnerability as vul
On Patch.Vulnerability_Idn = vul.Vulnerability_Idn
Where vul.Vul_ID = 'Custom Definition ID'    

Using 3rd Party Utility

The tool outlined in this article (FileHasher64.exe) will provide MD5 and SHA-1 values encoded in Base64. These can be used to compare against the value in the Patch table of the LDMS database.

Tool: Get MD5 & SHA-1 Encoded in Base64

Description

A vulnerability scan is giving the following error:

Wed, 17 Aug 2016 10:19:51 Last status: Failed: No response from core

Wed, 17 Aug 2016 10:19:51 Failed to put vulnerability results to core as file: 8DB301B1

Viewing the IIS logs shows 405 errors.

Cause

Features for the Web Server role in Windows Server Manager are not installed.

Resolution

Ensure that the features for the role match what is seen below (screen shot taken from LDMS 2016)

Additionally you may want to double-check ISAPI and CGI restrictions and Handler Mappings in 'incomingdata' as in the following document.

LDMS introduced SSL Validationfor Client Certificates when communicating with the core via Vulscan. This can sometimes cause errors when clients attempt to verify using the Client Certificates its been given.

This issue is often caused by those who have upgraded their core to 2016 from an older version, or a side-by-side installation with a database import.

Issue

Vulscan hangs on "Contacting Server..." and never proceeds:

Troubleshooting

In order to identify if Vulscan is failing due to Certificate issues, a number of items can be referenced/tested on the Core and Clients.

Disable Client Certificate Validation for WSVulnerabilityCore

1. Open Internet Information Services (IIS) Manager on the core.
2. Drill down to WSVulnerabilityCore under Core Name> Sites > Default Web Site.
3. Double-Click SSL Settings.
4. Set Client Certificates to Ignore and click Apply.

   After this change has been made, attempt to run a vulscan on the client machine. If successful, then the issue is indeed involving Client/Core Certificates.

Reference Core Logs

Logs under C:\inetpub\logs\LogFiles\W3SVC1 can be reviewed for HTTP status return codes when workstations attempt to contact WSVulnerabilityCore.

2016-08-26 19:23:34 10.25.26.50 POST /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 358
2016-08-26 19:23:34 10.25.26.50 POT  /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 358
2016-08-26 19:23:34 10.25.26.50 POST /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 421
2016-08-26 19:23:34 10.25.26.50 POST /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 405

Things that can be derived from this information:

• IIS is returning a 403.16 Status Code which indicates "Client Certificate is Untrusted or Invalid."
• There is also return code 2148204809.This translates to HRESULT 0x800b0109, which is defined by Microsoft as CERT_E_UNTRUSTEDROOT.

Reference Client Logs

ProxyHost.log under C:\ProgramData\LANDesk\Log on the client will show errors when attempting to reach WSVulnerabilityCore.

2016-08-26 18:49:28(5144-148) proxyhost.exe:IsProcessSigned succeeded - returning: 1
2016-08-26 18:49:28(5144-148) proxyhost.exe:Made direct (non-proxy) connection to LDCORE2016:443
2016-08-26 18:49:28(5144-148) proxyhost.exe:Call UpdateCSAROIFile() with numberofDirectConnectSuccess = 1 numberofDirectConnectFailure = 0  csaName =  bCsaSuccess = 1
2016-08-26 18:49:28(5144-148) proxyhost.exe:127.0.0.1:57652 Connection close 0 0 0 0
2016-08-26 18:49:28(5144-148) proxyhost.exe:127.0.0.1:57652 - - [26/Aug/2016:11:49:28 -0800] "POST http://LDCORE2016:443/WSVulnerabilityCore/VulCore.asmx HTTP/1.1" 403 651 469

• ProxyHost verifies what is already known - a 403 is returned when attempting to reach WSVulnerabilityCore from the client.

Cause(s)

As the resolution for this issue isn't reserved to one cause, a few things will need to be verified:

Verify Core Certificates in the Trusted Root Authority Folder

According to this Microsoft KB Article, any Non Self-Signed certificates installed in the Trusted Root Certification Authority certificate store on the IIS Server may cause an error when users attempt to authenticate when using a Client Certificate.

Non Self-Signed Certificates will show in the CertMgrtool as having different information in the "Issued To" and "Issued by" columns.

You can easily determine if this folder contains any non self-signed certs with this PowerShell command:

Get-Childitem cert:LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\certlist.txt"

This command compares the "Issuer" property and the "Subject" property of each certificate in the store and then outputs details of certificates that do not meet the criteria of a self-signed certificate to c:\certlist.txt.

Remove any Non Self-Signed Certificates in the Trusted Root Certification Authority Folder, if found, and attempt running Vulscan again. If the issue persists, continue to next steps.

Verify Core Certificates and Keys in the Shared Keys Folder

The certificates in the C:\Program Files\LANDesk\Shared Files\keys and/or C:\Program Files (x86)\LANDesk\Shared Files\keys need to be valid and not expired as well. You can double-click the .CRT and open the .0 file in notepad to verify the information:

If there are expired certificates in that folder, back them up and remove them from that folder, including any keys and .0 files associated with that cert.

Verify Client Certificates

The certificates on the clients will need to be checked in this issue. Certificate information on the client is stored under C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs.

In this directory, there are usually one to several ".0" certificates. Its possible one or many of these certificates are not trusted by the core, causing the issue. To verify each certificate:

1. Make a copy of each ".0" certificate in a separate location.
2. Change the extension of each certificate to ".crt" and double-click on them.
3. Verify that the LANDESK Trusted Certificate they correspond to exists within the Trusted Root Certification Authority on the core.
   

If a ".0" certificate(s) is found to correspond to a LANDESK Trusted Certificate that does not exist within Trusted Root Certification Authority:

1. Remove the offending certificate(s) from the C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs directory, leaving only the "good" certificates.
2. Delete the contents of C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker. (This folder contains the Broker Certificate, which is the certificate used when communicating with the core).
3. Run "C:\Program Files (x86)\LANDesk\LDClient\BrokerConfig.exe /r" on the client CMD Window. This will generate a new Broker Certificate.

Attempt running Vulscan again. If all steps have been correctly followed, Vulscan should successfully verify with the core and begin scanning.

Resolution

If the issue was found to be a client-side issue, a couple of more steps will need to be taken in order to fully resolve the situation. One of two options can be executed:

Import "Old" LANDESK Certificate into the Trusted Root Certification Authority

If a ".0" certificate was found on the client that didn't correlate with a trusted LANDESK Certificate on the core, its likely due to the client being managed in the past by a core that has since been decommissioned.

The LANDESK Certificate(s) from the old core can be imported into the Trusted Root Certification Authority on the core. This will enable the clients to validate with the core using their existing certificates, provided its the right certificate.

If for whatever reason this is not an option, move on to the next step.

Update Client Certificates to Match Core

Changes will have to be made to the LANDESK Agent Configuration in order to ensure that clients aren't attempting to connect to the core with Untrusted Certificates.

This is configured through the Client Connectivity Agent Settings on the Core under Configuration > Agent Settings > Client Connectivity.

Ensuring that the correctly configured Client Connectivity Settings are included in the Agent Configuration will ensure that all future agent installs will get the correct certificates.

There are a couple known methods to address the existing clients that already have the untrusted broker certificate on them:

Reinstall agent with updated Client Connectivity Settings

• Since Vulscan is not able to connect to the core, reinstalling the agent will ensure the new Client Connectivity Settings are applied to the client and new Broker certificates are generated.

Use a script/batch file

• A script or batch file can be used to clear out the contents of the "certs" and "broker" directory. It can then download the correct ".0" cert and run "brokerconfig.exe /r."
• This script/batch can be deployed via LANDESK Software Distribution. For more information on deploying Batch Files, please see this Community Document.

Check Default Web Site Bindings

The Default Web Site configured by the LANDESK install will utilize the LANDESK Secure Token Server SSL Certificate for the Site Binding within IIS. This is the recommended configuration.

To verify the SSL Certificate being utilized, open Internet Information Services (IIS) Manager and go to CoreName> Sites > Default Web Site.

From there, click Bindings.

This will bring up the Site Bindings window. Highlight port 443 and select Edit.

In the Edit Site Binding window, the SSL Certificate: dropdown will show the currently assigned binding. Click to expand the dropdown list and verify there aren't any Untrusted Certificates in the list.

• Note: Ignore the WMSVC, LANDESK Secure Token Server and LANDESK_CommandsWS here.

If there aren't any Untrusted Certificates found in the drop-down, the Site Bindings are good. No other work is needed here. If there are, a couple options are available.

(1) Remove the Untrusted Certificate from Server Certificates

This is the recommended resolution to this issue as it ensures simplicity and eliminates the possibility of old certificates becoming a problem again in the future.

Open Internet Information Services (IIS) Manager and select Corename. Under the IIS section, double-click Server Certificates.

Within the Server Certificates window, select the Untrusted Certficate(s) and click Remove and select Yes when prompted.

Run IISReset in an Administrator Command Prompt on the core and Re-attempt vulscan to verify the issue is resolved.

(2) Install the Untrusted Certificate in the Trusted Root Folder so it is Trusted

If a copy of the Untrusted Certificate shown IIS is available, it can be imported into the Trusted Root Certification Authority folder so it becomes Trusted.

LANDESK Certificates exist under C:\Program Files\LANDesk\Shared Files\keys on the core by default. They may have been moved to other directories by users for various reasons.

Right-click the currently Untrusted Certificate and select Install Certificate. Follow the configuration detailed below:

Re-attempt vulscan to verify the issue is resolved.

Login to a client device. Press the Windows + R keys to open the Run dialog, type eventvwr.msc, and press Enter.

If prompted by UAC, then click on Yes (Windows 7/8/10) or Continue (Vista).

In the left pane of Event Viewer, double click on Windows Logs to expand it, click on System to select it, then right click on System, and click on Filter Current Log.

Standard Shutdown Events

Click on the drop down arrow to the right of Event Sources, check the USER32 box.

In the Includes/Excludes feild, type: 1074, then click on OK.

This will give you a list of power off (shutdown) and restart Shutdown Type of events at the top of the middle pane in Event Viewer.

You can scroll through these listed events to find the events with power off as the Shutdown Type. You will notice the date and time, and what process was responsible for shutting down the computer per power off event listed.

You can see in this example highlighted that vulscan called the reboot.  If Endpoint Manager calls a reboot this is typically what you will see.  Any other process that calls a reboot is not being controlled by Ivanti.

To See the Dates and Times of All Unexpected Shut Downs of the Computer

These are typically crashes, while the information might not be complete, it can be useful to troubleshooting unexpected shutdowns.

Click on the drop down arrow to the right of Event Sources, check the USER32 box. 

In the Includes/Excludes field, type: 6008, then click on OK.

This will give you a list of unexpected shutdown events at the top of the middle pane in Event Viewer. You can scroll through these listed events to see the date and time of each one.

When finished, you can close Event Viewer.

EPM version 2017.3 Verification - Verify definition signatures/hashes before downloading option is enabled by default and it cannot be disabled.

EPM version 2017.3 Management Console > Tools > Security and Compliance > Patch and compliance > Download updates > tab Content > Verification

Verify definition signatures/hashes before downloading

NOTE: When checked, any definitions that do not have a valid SHA256 hash will not be downloaded. Also, any lists of definitions that do not have a valid signature will not be processed. The download progress form will show any download failures due to invalid/missing signatures or hashes.

An error can occur of "Signature is not valid" if the core server cannot validate the certificate chain correctly.  One cause of this is a failure to connect to the internet and the certificate servers properly.

(Signature is not valid)

(Failed to download platform information)

The resolution to this error is almost ALWAYS the connection to the internet.

• The core ideally should be allowed directly through any proxy.  If a proxy must be in place the information should be filled out in the Proxy Settings tab within Download Updates.
• If there are still failures the Proxy information should be added to the Internet Explorer proxy option.   (Internet Options --> Connections tab --> Lan Settings --> Proxy Server

Further information:https://community.ivanti.com/docs/DOC-23625#jive_content_id_Cannot_connect_to_Ivanti_Patch_Content_servers_andor_vendor_…

Issue

When downloading new Patch content using the Download Updates button or task, nothing will be downloaded. At every step the following message will appear in red. The same information appears in the vaminer.log file:

Signature is not valid. Failed to download platform information.

Resolution

It used to be optional to verify the hash of the downloaded content. Now it is not an option anymore, it is obligated. The current hashes (following the new Patch engine of January 2018) don't match the older ones. Look in your Patch folder (where the actual patches are downloaded by your Core). It will contain a LDHashDir subfolder. Rename this folder to OLD_LDHashDir. Restart the download of the content. A new LDHashDir folder will be created and new hashes will be downloaded along all of the content.

Overview

We are changing how we handle patching for Citrix Receiver to better match up with Citrix's lifecycle process. The changes we are making are:

Versions less than 4.9: Systems running versions of Citrix Receiver prior to version 4.9 will detect as previously, with the newest patch being offered updating the software to version 4.9 which is the Long Term Service Release (LTSR) of Citrix Receiver.

Version 4.9: As this is the LTSR release it will have any Cumulative Updates marked as applicable for it, but it will not have the update to version 4.10 marked as applicable. If you want to upgrade to 4.10 from 4.9, 4.10 will be available as a Software Distribution as a separate branch, similar to how major version updates are handled currently of Java Runtime Environment.

Version 4.10: As this is the current release, and the start of a new branch, it will have updates marked as applicable as they are released up to the point of the next LTSR release of Citrix Receiver. At this point a new branch will be created, with versions between 4.10 and the next LTSR being offered updates to the LTSR version.

Additional Information

• Lifecycle Milestones for Citrix Receiver - Citrix
• Citrix Receiver for Windows 4.9 LTSR

If there is an application update that you would like to see included in Patch Manager content you can submit a request to Ivanti support to have the content added.

For new products that are currently not available in Patch Content, submit a request through the following website:

https://ivantisecurity.uservoice.com/forums/903928-patch-content

A list of current Patch Manager content can be located here: Products and Applications available through Ivanti Security and Compliance content delivery. 12/Oct/2017.

For products that are already available in patch content but the latest update is not available for the product, open a case with support to request it.

To increase the chance of the content being added and the speed that it is added, collecting the following information for the Support case will be helpful.

1. Name of the application including version.
2. Name of the update.
3. Link to the update.
4. A short business justification for adding the content.

It is recommended to use the Support Portalto submit this information.

Purpose

This article explains how our detection the Delta or Cumulative version of the patch is offered.

Description

Our detection logic will verify the  'UBR' value from the registry to determine if the Delta or the Cumulative update will be offered.

HKLM" Key="SOFTWARE\Microsoft\Windows NT\CurrentVersion" Value="UBR" (Update Build Revision)

• The Delta is offered if build version equals N-1. (N= Latest Build. Current build being offered minus one version level)
• The full Cumulative update is offered if build version is N-2 or less.

You will only be offered one or the other and never both.

Related Documentation

Windows 10 release information

Overview:

Ivanti Patch and Compliance now provides support for Office 365 versions 2013 and 2016.  Patch and Compliance administrators can now scan, detect, and remediate client devices that have Office 365 installed. For Office 365 version 2013, Ivanti leverages the Microsoft Office Deployment Tool to perform the remediation tasks for updating Office 2013 installations. For Office 365 version 2016, Ivanti has developed an Office Com API to perform remediation tasks for updating Office 2016 installations. Ivanti provides a utility (Office365Util.exe) for you to use to download the Office installation data and to check the hash for Office 2016 installation data. When the Office patches are downloaded, Ivanti Endpoint Manager will check the hash on the pertinent files to ensure validity.

High Level Process

1. The Ivanti administrator downloads Office 365 definitions from the Ivanti global servers.
2. Once the Office 365 definitions are downloaded to the core, the Ivanti administrator can scan for those Office 365 vulnerabilities.
3. In order to remediate (apply latest patches) detected vulnerabilities, Ivanti administrator have to manually run, on the core machine, a new tool provided by Ivanti (Office365Util.exe). Using this tool, the Ivanti administrator can choose the Office 365 versions that are relevant to the environment. The Ivanti Office 365 utility will download the patch binaries and the Microsoft Office deployment tool from the Microsoft cloud.
4. Once the patch binaries are downloaded to the core, the Ivanti administrator can apply the patches to all vulnerable endpoints using the standard method of applying patches.

Step 1: Download Content

Customers download the Office 365 vulnerability definitions, the O365Util.dll, and the Office365Util.exe from the Ivanti Global Host Content Server by downloading the latest Microsoft Windows Vulnerabilities.

Download Updates (Microsoft Windows Vulnerabilities)	Updating Definitions (Office365Util.exe/O365Util.dll)

Updating Definitions (MSO365)MSOFFICE 365 (Vul_Defs)	MSO365 (Vul_Defs)

Step 2: Launch Office365Util.exe

Upon successful content download, an Office365Utility folder is created under the LDLogon share and will contain the Office365Util.exe file provided by Ivanti.

\\Core_Server\LDLogon\Office365Utility

This utility will allow you to select the specifics regarding the Office 365 product you are patching. Launch this utility directly from C:\Program Files\LANDesk\ManagementSuite\ldlogon\Office365Utility\ by double-clicking on Office365Utility.exe
(do not try to run it via the network share \\Core_Server\LDLogon\Office365Utility or \\localhost\LDlogon\Office365Utility as you will get an error).

Step 3: Select Options from Office365Util

The view provided below displays the available options inside of the Office365Util application (Ivanti Office 365 Utility for Patch and Compliance):

Platforms	Deployment Tools

Channels	Office 365 (2013) Product List View

In order to successfully patch Office 365, select which Office 365 patch product updates to download in order to support client remediation. After selecting the desired product updates from the Ivanti Office 365 Utility for Patch and Compliance application, click START.

Office 365 Tool

The START action will do (2) things:

1. Create an Office365Tool folder under the LDLogon share and process the Microsoft setup.exe file
   
   

   \\Core_Server\LDLogon\Office365Tool

The contents of this folder will contain the Deployment Tool Type (2016 or 2013) selected during the download and all relative installation data applicable to the options selected in the Ivanti Office 365 Utility for Patch and Compliance
application. The display below will outline the contents of both Deployments Tools (2016 and 2013).

Office365Tool	Deployment Tool Options

2016 Content	2013 Content

   
      2. Create an Office365 folder under the LDLogon\Patch share that contains the patch files(s):

\\Core_Server\LDLogon\Patch\Office365

Patch Location

^Updated Office 365 patching is not designed to take advantage of our download technology. The client device will NOT download o365 patch files from a preferred server or peer device. The files will be retrieved from the default or non-default patch location.

Non-Default Patch Location

This section is only applicable to those who have changed the default download location for patches. After downloading the Office 365 patch updates and installation data with the Ivanti Office 365 tool, the following SOURCE will be in the vulnerability definition:

Office 365 (2016)

 

httpSourcesURL="Core_Server/LDLogon/Patch/Office365/DeploymentToolType/Channel/Architecture"

 

Ex: httpSourcesURL=http://2016E/ldlogon/patch/office365/2016/current/x64

Office 365 (2013)

httpSourcesURL=http://Core_Server/LDLogon/Patch/Office365/DeploymentToolType

 

Ex: httpSourcesURL= http://2016E/ldlogon/patch/office365/2013

In order for the Patch Install Commands in the vulnerability definition to interpret the correct patch location, the Custom Variable will have to be set in every MSO365 vulnerability definition.

To do this open the properties on the definition and select the Custom Variables tab. By default the value specified will resolve to the default patch location.

You will need to explicitly set the value to reflect the location your patches reside.

The Patch Install Commands section of the definition utilizes a script that resolves the Custom Variable.

References

How to change the default Patch Location for Security and Patch Manager

Microsoft Office 2016 Deployment Tool

Microsoft Office 2013 Deployment Tool for Click-to-Run

Problem

Patches are being detected as Vulnerable but there is no associated patch to download and remediate

Example of Affected patch(s):

MS18-06-W10-4284880

Solution

Ivanti has released a DETECT_ONLY definition that will show it is vulnerable on the applicable systems. Being a detect only definition is informational only and cannot be used to repair the system. In order to repair the system there are prerequisites that must me met before attempting to repair the  DETECT_ONLY definition. The prerequisite can usually be found in the properties of the DETECT_ONLY definition in the description. Once the prerequisite has been met the standard definition will be offered.

In our example If KB4132216 has been installed then we will detect MS18-06-W10-4284880 as missing, if KB4132216 is not installed we will detect MS18-06-W10-4284880_DETECT as missing so you know the vulnerability is present but it cannot be remediated  until the prerequisite is met.

How to set up your Dark Network Core: Step by step

• How to set up your Dark Network Core: Step by step
• Description
• Assumptions
• Process
  • Step one: Prepare both core servers to have accurate data
  • Step two: Prepare the Dark Core folder structure
  • Step three: Retrieve content on the "Light Core"
  • Step four: Copy PatchSources file to patch directory on Source (Light) Core
  • Step five: Prepare the ENU_PatchSourcesXXX.xml on the Dark Core
  • If automating the copying of Data from the light core to the dark core:

Description

This document details the procedure for copying definitions from a "light core" (A core that is connected to outside networks) and a "Dark Core" (a core that is not connected to outside networks)  This is often done for security purposes or lack of connectivity.

Assumptions

• The user has a familiarity with Ivanti Endpoint Manager and associated files and functions
• The user has 2 servers, one "Light" and one "Dark" (One with Internet connectivity and one without internet connectivity)
• The user has Ivanti Endpoint Manager installed with default parameters, file and drive locations, etc.

Process

Step one: Prepare both core servers to have accurate data

In order to download a complete set of data to transfer from the light core to the dark core, the database tables related to Patch Manager must be reset.  This must occur on any core server that has previously downloaded patch data, otherwise, a complete set of data will not be downloaded.

This can be done on both core servers by doing the following:

1. On each core server, open a command prompt on the server and change to the C:\Program Files\LANDESK\ManagementSuite folder.
2. Run "CoreDbUtil.exe /patchmanager".
3. Open the process list in Task Manager (right-click the taskbar and select "Task Manager) and watch for CoreDbUtil.exe to drop from the list to make sure it has finished.
   (The log for CoreDBUtil.exe is located in the main log location at \Program Files\LANDESK\ManagementSuite\Log)

Step two: Prepare the Dark Core folder structure

On the Dark Network Core Server, you will need to have a location for the vulnerability XML files and a location for the actual patches themselves to be stored in. For ease of use, we recommend using the already created patch folder structure that is set up when you install Ivanti EPM. By default, patches are stored in the \Program files\LANDESK\ManagementSuite\LDLogon\patch  folder. If a different location is desired this article can be used to set up the alternative location.

If patches have not been downloaded on the dark core previously the patch folder may not have been created and should be manually created.

Step three: Retrieve content on the "Light Core"

1. Within Security and Patch Manager open the Download Updates window and select all of the categories you want to download.
2. In addition select "Download patches for definitions selected above and also the radio button for "for all downloaded definitions" and click "Apply" and then "Close".
   
3. From a Command prompt, change to the LANDESK\ManagementSuite folder.
4. From a Command prompt, type "vaminer /noprompt /copy" and hit enter.  (If scripting this action to run regularly please add the /noui" switch to the vaminer command line switches)

(Vaminer.exe is the executable that runs to download content from the Ivanti patch content servers).

The first time this is run it will take quite a while as it will not only be downloading vulnerability definitions but also all patches.  (Due to this you will need a large amount of storage space on the dark core server).  This will download updates and store them to a to the patch directory.  The default patch directory is \Program Files\LANDESK\ManagementSuite\LDLOGON\patch.

To verify further that this process has completed correctly, in \Program Files\LANDESK\Managementsuite\ldlogon\patch and it's subdirectories you should have .XML files that were generated by the Ivanti Content download to represent your vulnerability definitions.  Do not change the folder structure or files.

Step four: Copy PatchSources file to patch directory on Source (Light) Core

Copy ENU_PatchSourcesXXX*.xml (Where XXX equals the current LDMS version) from \Program Files\LANDESK\ManagementSuite\LDMAIN to \Program Files\LANDESK\ManagementSuite\LDLOGON\PATCH on the source core.  This step is necessary because Vaminer.exe (the program that is downloading the Patch Content) expects that file to be in that location.  Again, this needs to match the version you are running: 9.5 (ENU_PatchSources95.xml), 9.6 (ENU_PatchSource96.xml, 2016.3 (ENU_PatchSources101.xml) and so on.  Modification of the file is not necessary, it just needs to exist in that location.

               (It has been noted that on LDMS 2017.3 SU3 the file has to be renamed from ENU_PatchSources1013.xml to ENU_PatchSources10132.xml)

Step five: Prepare the ENU_PatchSourcesXXX.xml on the Dark Core

In the \Program Files\LANDESK\ManagementSuite\LDMAIN folder there will be several files called ENU_PatchSources and then a numerical ending.  These stand for the current and prior versions of LDMS.   Choose the one that is the latest and matches your version on your core server.

For example: On a 2017.3 Core server you will likely see three ENU_PATCHSOURCESXXX files:

• ENU_PatchSources951.XML
• ENU_PatchSources961.xml
• ENU_PatchSources101.xml
• ENU_PatchSources1013.xml

We would select ENU_PatchSources1013.xml as this corresponds to LDMS 2017.3 and begin editing it.

If your core is not running in the English language you will want to select the XML file that matches your language prefix (ESP, JPN, etc)

Modify the Enu_PatchSourcesXXX.xml as modeled below:

Line #3 in the .XML will contain ‘/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&FILENAME=’.  Replace it with  /ldlogon/Patch (or whatever directory you have defined as your patch storage directory).

Before:

PatchesSrcRelativePath>/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=patches</PatchesSrcRelativePath>
<LDAVRelativePath>/kvirus-8.0/mirror</LDAVRelativePath>
<CVEMoreInfo>http://cve.mitre.org/cgi-bin/cvename.cgi?name=%CVE_ID%</CVEMoreInfo>

After:

<PatchesSrcRelativePath>/LDLOGON/PATCH</PatchesSrcRelativePath>
<LDAVRelativePath>/kvirus-8.0/mirror</LDAVRelativePath>
<CVEMoreInfo>http://cve.mitre.org/cgi-bin/cvename.cgi?name=%CVE_ID%</CVEMoreInfo>

1. Next you will need to change the URL's for each Patch Content Server location.    These will be listed under the <Sites> tag.  Search for <sites> and you will see 3 sites, West Coast, East Coast, and EMEA.
   
   Delete two out of three sites leaving just one site. 
   
   You will change the hostname listed in the <URL> field and then the Description.
   
   

If you are using content that will be manually copied to the core server, put the name of your Dark Core server.  If there will be constant or periodic network connection between your light core and dark core, put the name of your light core here.

In the following section, you will select the definition download category that you want to download to the dark core and you will edit that entry in the .XML.  We will replace the string that normally works with the Ivanti Patch server and replace it with a local path.

The following example is for the vulnerability definition category Windows Vulnerabilities  Again, you will modify the path from the patch server location to a local directory.

Search for /LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=Windows2 the correct section by searching for "Windows2".  Modify the section within the <URL> tags

The resulting line will be<URL>/LDLOGON/PATCH/Windows2</URL>. 

You also will add the tag <Enabled>true</Enabled>. This is the same as ticking the checkbox next to the vulnerabilities category when bringing up the Download Updates tool.  Without adding the <Enabled> tag you will need to select the categories every time Download Updates is opened.

When renaming these sections per component you wish to download, FILENAME=Windows2 will use the subdirectory name of "Windows2" under the Patch directory after you modify it.  For example, if I wanted to change the source for Ivanti Data Analytics updates, you would search for that category by searching for just that - "LANDESK Data Analytics Updates".

You would then modify the <URL>/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=LDDA</URL> to <URL>/LDLOGON/PATCH/LDDA</URL>.

 

     Before:
     <Source>

                     <URL>/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=LDDA</URL>

                   <Description>LANDESK Data Analytics Updates</Description>

                   <ShowInLDSM>true</ShowInLDSM>

                   <ShowInLSM>true</ShowInLSM>

            </Source>

 

     After:
     <Source>
                        <URL>/LDLOGON/PATCH/LDDA</URL>
                        <Description>LANDESK Data Analytics Updates</Description>
                        <ShowInLDSM>true</ShowInLDSM>
                        <ShowInLSM>true</ShowInLSM>
                        <Enabled>true</Enabled>
            </Source>

Once all of the edits have been made do a "Save as" and save it as "Patchsourcestemp.xml" and mark it as a read-only file.  (Right-click, go to properties and check the box "Read Only")

After you have marked it as read-only, rename it to "patchsources.xml".  Remember, all of this is taking place in the LDMAIN folder.

     1. On the light Core run Certlm.msc to open the Local Computer Certificates store.

     2. Open the Personal Certificates, locate the certificate with the Light Core server name (also has the Friendly Name LANDESK Secure Token Server)

     3. Export this certificate.

     4. Import this certificate into the Dark Cores  Local Computer Certificates store into the Trusted Root Certification Authorities certificate store.

Step six: Import the vulnerability definitions into the "Dark Core"

1. Now you will need to move the data to the dark core for insertion into the database.   Copy the following to an external hard drive, flash drive, or whatever method you prefer to transfer using.
   • The entire Patch directory and all subdirectories of that folder
   • The entire LDLOGON\Timber folder
   • The following files from the LDLOGON folder on the light core to the LDLOGON directory on the dark core, once at first, but the copying procedure should include copying these files if newer files are detected.
     • Office365Utility (folder)
     • SCSDiscovery_11.1.0.75.exe
2. These files will need to be copied to the same directories on the dark core server.  If the light core will have access to the dark core this can be done automatically through a file transfer process, automated or otherwise.  The key is to download content on the light core server regularly using the "vaminer /noprompt /noui /copy" switch and then copy the updated data to the Dark Core.
3. When copying the Patch Directory from your Light Core to your Patch Directory on your Dark Network Core, ensure the directories look the same.
4. Run Download Updates on the Dark Core Server, if running via script simply run "VAMINER.EXE" from the main ManagementSuite folder.

If automating the copying of Data from the light core to the dark core:

If you are automating the copying of the vulnerability data from the light core to the dark core, ensure the following steps are taking place:

1. "Vaminer /copy /noprompt /noui" is run on the light core server.
2. All files from the Patch directory, its subdirectories, the LDLOGON\Timber folder and the listed files above in step 6 from the LDLOGON folder are copied to the Patch folder on the dark core.  This can be done using content replication, robocopy or other preferred methods.
3. Vaminer.exe is run on the dark core (without switches).

This should be done on an automated schedule so that these steps take place in sequence and that there is enough time for each step to complete before the next one starts.

Description:

When trying to download updates for definitions through Patch Manager, the  errors as below is given:

As the verification option is now greyed out and enabled by default, we could not uncheck this verification to ignore this.

Reason：

Can't get to the site http://Cacerts.digicert.com to download the certificate from core server

The website was blocked

Resolution:

Check if Internet Explorer Browser Security setting block the certificate downloading

Check if local network firewall block the target address

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

Purpose

The purpose of this document is to teach you how to create a simple repair tasks using Ivanti Endpoint Manager, formally Landesk. In some situations you may find you have an employee or yourself who doesn't have the training or knowledge with the product enough to perform a basic repair task on a specific vulnerability when asked to. This document is a step by step guide to create a single repair task for one or more vulnerabilities.

Assumptions

If you are reading this they it is assumed that your licensing and vulnerabilities are already setup and you are ready to repair a client. You also know the name of the vulnerability that you are wanting to patch.

For additional information on assumed expectations please visit these links:

How to get Started with Patch and Compliance Manager

About Ivanti EPM Distribution and Patch settings

Step 1: Creating the repair task

The first step to creating a repair task is locating the patch in question. Once the patch you desire is found simply right click on the vulnerability and select "Repair..."

Selecting this will bring up the scheduled task window where we configure the parameters for the task.

Step 2: The Scheduled Task Window

In this step I will go over a basic overview of the settings for a simple repair task, I will not go to far into detail. For and in depth understanding of the different options and configurations selecting the "Help" button at the bottom of the scheduled task window will give more information on what those options do or visit our community for more information. I will make important notes for settings to be aware of.

Repair settings

This is the first window that you'll see when the window opens. This contains options to add target clients, overrides to the Preferred Server and Maintenance windows. This is also where you can name the task that is about to be created.

For this example we are going to leave everything here blank. We are also going to leave the name of the task as the default name.

Task Settings

Next you'll see Task Settings, it is here you will see the Task type, Action type (Opens Portal settings window), Frequency, Additional Push options, And Download option.

Task type: This will change how the task will interact with the clients.

Frequency: This will change how often the task will run.

Additional Push options: These are additional parameters the task will apply to the task.

Download options: Changing this option will allow for different methods of download and execution for the task.

For this example we are going to use the default settings

Portal settings

This is an optional setting, for more information please visit our community on Portal Manager here.

Agent Settings

This is one of the more important windows in the process. Here you will configure the Distribution and Patch and Reboot settings the task will use. Configuring these will alter how the task behaves when it comes to scanning and reboots.

You can alter what setting is used by selecting where it says "Keep agent's current settings" this will bring a drop down that will allow to you to select which setting will be used for the task. Keep agent's current settings refers to the setting that is applied to the client by default. After selecting an alternative setting you can select "Edit.." to look more in depth at what that particular setting and it's behavior.

For the example I will use the default settings.

Definitions

This window gives an overview of the definitions that have been selected for the task. There is nothing to change in this window so we can move on.

Patch list

Here you will be able to get an overview of the list of patches that will be used in the task. Looking at this you can double check the amount of patches and download status of the patches. In this example, I have not downloaded the patches yet as indicated by the "Downloaded" column. I know I am able to download because the "Can Download" column indicates that I can.

I can download the required patch by highlighting the patch and this will allow for the "Download" button to become available. Selecting this option will download the patch.

Targets

Here you can assign what clients will receive this task. There are many options to choose from which option will depend on the method of choice. Most of these options are for groups that once the specific group or query is selected for the task it will pull all clients in those groups into the task.

Targeted Devices: Selected individual clients in the environment.

Targeted LDAP objects: Clients that are associated with an LDAP objects.

Targeted queries: Clients that are assosiated with a custom built Landesk Query.

Targeted LDAP quries: Clients that are assosiated with an LDAP query.

Targeted device group: Clients that have been placed in a custom device group in the Network View.

Targeted scopes: Clients that have been placed in a scope in the network view.

Targeted email addresses: Clients who have had an email address associated with the machine.

Targeted time zones: Informational only. Displays clients time zone as well as how many of those clients in that zone.

Simply select the option you want and press "Add" this will bring up a list of options available that fall under that particular group.

For this example I have selected Targeted devices. Notice the PC "Elexi" under Targeted Devices.

Schedule task

Now that we have our clients selected and the task configured it is now time to schedule it. Here you are given 3 options, Leave unscheduled, Start now, and Start later.

Leave unscheduled: This will leave the task unscheduled for you to either come back later to reschedule or for you to manually start later at a time that works best.

Start now: Once the "Save" button is selected the task will begin processing.

Start later: Allows you to schedule it to start the task at a specified time. This has additional options for clients in different time zones as well the option to make it repeat at certain intervals.

For the example we will leave it unscheduled.

Step 3: Launching the task

Now that we have the task configured how we want, and assuming we haven't already started it, you will see that the application has taken you to your scheduled tasks window. Here you can monitor the status of the task. The display shows 4 different statuses, Active, Pending, Successful, Failed. When a task is left unscheduled the clients will be in a pending state. In order to launch the task from the console simply right click on the task and select "Start Now" this will give you options on what you want to start we are going to select "Devices that did not succeed." From there the task will start and Endpoint Manager will do the rest. The console will periodically update with it's status.

Now that the task is started, simply wait for the return which will display. If it is successful congratulations you just launched your first repair task. If you're getting failures, take a look at the pane on the right side and it will give a brief report of the reasons for failure in the form on an associated return code. Some may require Technical Support to assist you with but our community is full of troubleshooting steps.

Useful Links:

Ivanti Endpoint Manager and Endpoint Security - Security and Compliance Frequently Asked Questions

How to Effectively open a patch related Support ticket

How to use Reboot Settings

About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes

This article describes how to report patch vulnerability definition issues to Ivanti Support.

There are several things that can happen with a vulnerability definition.

• Definition is not detecting a vulnerability on an Operating System it should be.
• Definition is detecting a vulnerability it should not be.
• Definition is not detecting the product correctly.
• Definition is detecting a product incorrectly.

First review the following document to make sure you understand what is going on with the detection:

Troubleshooting detection problems in Ivanti Patch and Compliance Manager

Please obtain or verify the following information

1. The computer has rebooted.
2. The patch was actually installed. You can find this by checking the following.
   • Open the Ivanti Endpoint Manager Console.
   • Expand Devices and click on All Devices.
   • Find the computer in question.
   • Right-click on the computer and select Security and Patch Information.
   • Highlight Installed Patches.
   • Verify the Vulnerability in question is listed.
3. Run a security Scan on the computer.

When reporting these issues to Ivanti Support the following is recommended to expedite this process

1. Open a new support ticket in the Self Service Portal here.
   • Select LANDESKas the Product Line you are working with.
   • Select Management Suite / Security Suite as the Product you are using.
   • Select the version of the Product you are using.
   • Select Patch Manageras the component that is involved.
2. Gather vulscan*.log from C:\ProgramData\LANDESK\Log, place them into a .ZIP file and attach them to your case.

1. Open a new support ticket in the Self Service Portal here.
   • Select LANDESKas the Product Line you are working with.
   • Select Management Suite / Security Suite as the Product you are using.
   • Select the version of the Product you are using.
   • Select Patch Manageras the component that is involved.
2. See if an article is displayed that will help you with your issue, otherwise select "Request contact from Support".

Please provide a detailed Subject and Description, and give a detailed explanation as to what impact this issue is causing.

Expectations

Updates to Security-related definitions can typically be expected within 2 days.   Non-security definitions can take longer.

Note: Clicking on a photo will enlarge it.

This document will go over what to look for and do if you think you have a patch that is detecting incorrectly on your devices.  Incorrect detections can happen if the detection logic is incorrect and still reports as needed but the patch has already been installed, is not applicable to the system or other issues.  In this document, you’ll learn what to look for in the vulscan logs which are required to submit the incorrect patch detection for review.

This document assumes you know how to find individual patches, create a patch group and move patches to it in the console and create a repair task on a specific patch or group of patches in the console.  It also assumes you have an understanding of repair tasks and how to add target devices to them and run the task.

Step 1: Run a repair task with just the patch having the issue on the client

Select the patch(es) having the issue in Security and Compliance and right click.  Click Repair.  Once saved you will have a scheduled task that repairs the patch.  Add the device to the task and run it, wait for it to complete.

When you click on Repair, the repair task dialog will open.  Most settings you can leave as a defaults.  You can add a target device at this time as well.  If you have a maintenance window on your clients, be sure to check Ignore Maintenance Window if specified so the patch tries to install as well as scan in this repair task.

Once you have a target in your task run it and wait for it to complete.

Step 2: Collect regular log files after the repair task.

Once the repair task is done, go to the client device and zip up all the files in the C:\programdata\landesk\log folder and attach the zip file to the support case.

Step 3: Run a DPDTrace on the device and upload its zip file.

As of January 2018, a new patch engine is being used to patch devices.  A DPDTrace will scan the device for installed software and versions and is needed by support to troubleshoot new definitions.

This document goes over how to run a DPDTrace on the device:  DPDTrace GUI Tool: Used to troubleshoot patch detection issues

Once the DPDTrace completes, upload its output HFCli_xxxxxxxxx.zip file to the support case.

Manually Testing the Patch

It is best practice that you manually run the patch in question on the device in the GUI.  The patch should display a message giving a reason for not installing in a dialog.

Vulscan Log

The full vulscan log, created as a result of running the repair task, is needed for us to determine the issue of the false detection.  This log is located on the target devices in the C:\programdata\Landesk\Log folder. They are named vulscan.log.  Older logs have a number in the name.   The correct log file will have a line at the top with the task ID in the name as shown in the example.  This information changes with each task.

Thu, 26 Oct 2017 14:59:37 Command line: /policyfile="C:\ProgramData\LANDesk\Policies\CP.2353.RunNow._iOiXj4cedTDG&#474FOGYMztt+mWNQ=.xml"
Thu, 26 Oct 2017 14:59:37 client policy file: C:\ProgramData\LANDesk\Policies\CP.2353.RunNow._iOiXj4cedTDG&#474FOGYMztt+mWNQ=.xml
Thu, 26 Oct 2017 14:59:37 Reading policy parameters
Thu, 26 Oct 2017 14:59:37 scan=0
Thu, 26 Oct 2017 14:59:37 scanFilter=INTL_4049179_MSU;INTL_3089023_MSU
Thu, 26 Oct 2017 14:59:37 fixnow=True
Thu, 26 Oct 2017 14:59:37    maintEnable=False

Once you have found the correct vulscan log. Doing a search in the log file for the all capitals case sensitive “DETECTED” will yield the detection of the patch and the reason.  In our example case it show the file version is out dated and that is the reason the patch is needed.

Thu, 26 Oct 2017 14:59:45 VUL: '3089023_MSU' (windows8.1-kb3089023-x64.msu) DETECTED.  Reason 'File C:\Windows\System32\flashplayerapp.exe version is less than the minimum version specified.'.  Expected '18.0.0.232'.  Found '11.3.300.265'.  Patch required 'windows8.1-kb3089023-x64.msu'.
Thu, 26 Oct 2017 14:59:45    Patch is NOT installed

You can see in the example the patch was detected as needed due to a file being at a lower version than in the patch.  Now scroll down to the bottom of the log file.  You’ll see a “Patch Installation” header and below that you will find details of what happened when the device attempted to install the patch. In our example the patch returned the error code 2149842967 converted to a hex value that gives a result of  0x80240017 Looking on the list of WUSA codes the patch returned a “Not Applicable”.

Thu, 26 Oct 2017 15:03:21 Command Interpreter running
Thu, 26 Oct 2017 15:03:21 Setting current directory: C:\Program Files (x86)\LANDesk\LDClient\
Thu, 26 Oct 2017 15:03:21 Executing C:\Windows\system32\wusa.exe "C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows8.1-kb3089023-x64.msu" /quiet /norestart
Thu, 26 Oct 2017 15:03:23 Exit Code: -2145124329 (0x80240017)
Thu, 26 Oct 2017 15:03:23 Error: "C:\Windows\system32\wusa.exe" returned failure exit code (2149842967)
Thu, 26 Oct 2017 15:03:23 ERROR(EXECUTEFILE) Failed to run command - 80004005
Thu, 26 Oct 2017 15:03:23 DownloadPatch ERROR: Failed to run commands (80004005).
Thu, 26 Oct 2017 15:03:23 Last status: Failed
Thu, 26 Oct 2017 15:03:23 Stopping wuauserv service.
Thu, 26 Oct 2017 15:03:23 Stop service wuauserv
Thu, 26 Oct 2017 15:03:25 Successfully controlled the service.
Thu, 26 Oct 2017 15:03:25 DeferredReportAction: name 'windows8.1-kb3089023-x64.msu', code '1', type '-1', status 'Error: "C:\Windows\system32\wusa.exe" returned failure exit code (2149842967)'
Thu, 26 Oct 2017 15:03:25 Running post-install/uninstall script 
Thu, 26 Oct 2017 15:03:25 RunPatches completed.  1 processed.  0 installed. 1 failures.  Thu, 26 Oct 2017 15:03:25 Sending previous action history to core

STdeployercore.log

In addition the STdeployercore.log will also show the patch being installed and the error code for the Next Gen definitions:

2018-01-26T21:15:53.2279239Z 134c I DeploymentPackageReader.cpp:783 Deploy package 'C:\ProgramData\LANDesk\timber\sandboxes\InstallationSandbox#2018-01-26-T-21-15-15\0001c460-0000-0000-0000-000000000000.zip' successfully opened unsigned for package IO
2018-01-26T21:15:53.2279239Z 134c I Authenticode.cpp:134 Verifying signature of C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows6.1-kb4056894-x64_tw1158080.msu with CWinTrustVerifier
2018-01-26T21:15:54.2534266Z 134c V UnScriptedInstallation.cpp:30 Executing (C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows6.1-kb4056894-x64_tw1158080.msu /quiet /norestart), nShow: true.
2018-01-26T21:19:19.4406288Z 134c V ChildProcess.cpp:140 Process handle 00000408 returned '3010'.

Windows Update(WUSA) Error Codes

Windows Update Agent Result Codes

Description

This article illustrates how to create a custom vulnerability definition in Patch and Compliance Manager.  Creating custom definitions is not part of the regular support that Ivanti offers, so this Community article will serve the purpose of assisting customers in creating these definitions.

In Ivanti Security and Compliance Manager the ability to create a "user-defined" vulnerability definition provides an extremely flexible and powerful tool that can be used to implement and maintain computers in your environment.

Create Custom vulnerability definitions (and detection rules) to scan managed devices for any operating system, application, single file, registry condition, or use custom VBScript for various conditions to have the client be detected in order to implement various solutions.

Possible implementations

Implementations of the custom vulnerabilities are almost limitless. It can be used to update any application on managed devices. It can be used to apply any single file executable to a managed device based on detection rules defined by the Ivanti LANDESK administrator.

The following step-by-step example shows how to create a custom vulnerability to update or install a fictitious "in-house" application.

Assumptions

The administrator should be able to install the Ivanti Endpoint Manager Core Server and clients.  The core and managed devices should be configured with the latest LDMS version and service pack.

Creating a Custom Vulnerability Definition

Vulnerability Definition Help Page

We will now create the custom vulnerability to detect a condition.  In this case, Iwe will use "File Detection" logic to look for a minimum allowed version of "SuperSpecialInHouseApplication.dll".

1. From the Endpoint Manager on the Core Server or a Remote console open the Security and Compliance tool group.
2. Open the Patch and Compliance tool and click on the Create Custom Definition icon. (Green circle with + in the middle)
   
3. The following window will open which shows the General information for your Custom Definition:
   
4. Enter an ID, Title, Severity, and Notes.  This will show up in your Custom Definitions list in the following way:
   

Detection Rules

1. Under Detection Rules click Add to add detection rules.
   Detection Rule Help
   

   Detection rules define the conditions that will cause the computer to be deemed "vulnerable" or simply needing an update, configuration change, installation of an application, etc.
   Sometimes multiple detection rules are necessary to install patches, make configuration changes, based on conditions.
   A common use of multiple detection rules is when you have separate patches for 32-bit patches and 64-bit patches.

The following Properties for Rule # window will appear.

Give the rule a name, title, and comments as depicted below:

Vulnerability definitions are processed from the top down, and the following detection checks are taken:

Selecting Affected Platforms

Affected Platforms Help Guide

The scanner checks to see if the client is running an affected platform (in this case as defined by the user).
This is the operating system that is running on the client computer.  It is possible to differentiate between 32-bit and 64-bit versions of the Operating Systems, Etc.
The following is an example of the Platform pick-list:

If the client computer is not running an affected operating system all other detection criteria is ignored and the computer is not deemed "vulnerable" as it has not met the first detection criteria.
It the client computer is running an affected operating system (platform) the scanning will continue to "Affected Products".

Creating a custom Affected Product

Affected Products Help

The "Affected Products" check is to see if the Product exists on the client computer.  This is a top-level criterion, and will typically check for the mere existence of a file or registry key associated with the product.  Sometimes a VBScript is used.
If writing a custom definition for a product that is already in the EPM database, you can simply click "Configure" and select that product.
Otherwise, in our case of writing a custom definition for "Super Special In-House Application" we will create a new Product based on file detection of "SuperSpecialIn-HouseApplication.exe".

1. Click "Configure" in the Properties for Rule # properties window.
2. Click Add and file in the ID, Name, Vendor, and Version information (as applicable)
   
   Creating a custom product or selecting an already existing product adds another level of detection making other detection processes later in these steps more flexible.
   For example, if the scanner doesn't detect that Super Special In-House Application is installed it will leave the detection process.
3. Move down to the "Files" section of the Detection logic and enter SuperSpecialIn-HouseApplication.exe (or of course your filename you are concerned with).
4. Enter in a range for the Minimum Version the file has to be and the Maximum version.  In this case, we will enter 0.0.0.0 for Minimum version, and 99.99.99.99 so that any version found will be applicable.
5. Click OK to save the newly created Custom Product.
6. Now that the Product has been created, it will need to be included in the Rule.  Select the new  Product from the bottom pane of the Select Affected Products window and then click on Include to move it to the Affected Products pane.
7. Click OK.

Query Filter

Now move down to the Query Filter section.  All detection fields are optional.  Typically the Query Filter pane is used to include or exclude clients from the detection based on EPM queries.
An existing query can be selected or a new query created.  For our example, we will not use a Query Filter.

Files Detection Logic

Files used for detection help

Registry settings used for detection help

Custom script detection help

1. Move to the Files pane. 
   Our example will use "File Version" for detection.  However, there are various methods of detection that exist file Files detection:
   
2. Since SuperSpecialIn-House.dll is used in our detection process, and our new file is version 1.5, we will check to see if anything older than 1.5.0.0 exists.  Note that the top of the window says "Detection will occur if any of these conditions are not met".
   Several different criteria can be added (stacked up) in the File detection section.  If any one condition is not met, the computer will be deemed vulnerable.  However, typically only one criterion will be added here.
3. For path, you can enter in a static directory and filename (C:\Program Files (x86)\SuperSpecialIn-HouseApplication.dll) or use variables.  In order to use variables, right-click the FILEPATH entry and you will be presented with variables that can be used.
   
4. In Min version enter "1.5.0.0".  This will indicate that if the scanner sees any version of the .DLL that is earlier than 1.5.0.0 (the version of the .DLL in the update to be installed) the computer will be deemed vulnerable. For our example, we will not use the Registry Settings detection or the Custom Script detection however, if any combination of detection criteria for all three detection types are not met, the computer will be deemed vulnerable.

Patch Information

Patch Information Help

There are three options available regarding Patch Information:

1. "Repairing this issue requires downloading a patch" is used when you want to install a patch, an upgrade file, or an application.
2. "This issue can be repaired without downloading a patch" is used when you intend to use scripting, additions/changes to the registry, copying files, starting or stopping a service, etc to "repair" the computer.
3. "This issue cannot be repaired by Security and Compliance Manager" is used when you simply want to use detection only and do not plan to patch, upgrade or otherwise configure the client.

For our example, we will use the "This issue requires downloading a patch".

1. Select "This issue requires downloading a patch"
2. If you have a source to download from, enter the FTP or HTTP address into the "Manufacturer's patch URL:" section.
3. Select "Auto-downloadable" and set it to "Yes".  If the patch is not downloadable, the patch file will need to be placed in the default patch location.  (Also see this document: How to change the default Patch Location for Patch and Compliance Manager)
4. Each file that is installed by Patch Manager must be given a unique filename when it is downloaded.  This filename can differ from the original filename that existed on the source for the download.  Enter in a unique filename or the existing filename if manually copying the file into the default patch location rather than downloading from an FTP or HTTP source.
5. Once the file is in place, you will need to generate a hash for the file to ensure that it is secure and cannot be replaced with another file surreptitiously. 
   To do so, click the Calculate Hashes button and you should see the red X's above turn to a green checkmark, you will also see the "File Size" line populated with the file size.
6. If your application requires a reboot, enter the appropriate choice in the "Requires Reboot" section.
7. If your application can be installed silently select the appropriate choice in the "Silent Install" section.
   (Note: These fields are used for purely informational purposes.  The "Patch Install" section of the rule controls the silent switches, and the Distribution and Patch Settings control the reboot options.

Detecting the Patch

Various criteria can be used to detect whether the patch is installed.  Both File Detection and Registry Detection can be used.  This detection criterion is the opposite of the detection criteria to detect the vulnerability.  Note that this section says "The patch will be detected if all these conditions are met, along with all registry and script conditions".    The Detection Logic section says if the criteria is NOT met.  This is an important distinction.  Due to this, the exact same criteria can possibly be used both in the Detection Logic section and in the Detecting the Patch section.

Patch Installation and Removal

Patch Install and Uninstall Help

Stop Processes

If processes need to be stopped prior to your install, update or configuration change, you can list the process name as it would appear in Task Manager in windows.  Several entries can exist.

This will cause any of these processes to be "killed" (stopped) prior to the patch install actions.

Additional files

This will allow you to specify additional files that will be downloaded to the client along with the main file that is listed under the Patch Information section.    Enter the HTTP and/or UNC path, then click the blue arrow to browse to that location and then select the file(s) you wish to include from the "Available files" listing. After adding the files you will be presented with options to hash the files.

Patch Install Commands

Various combinations of actions can be added to the Patch Install commands section:

   
These actions will be run in the order that they are listed.  You can re-arrange them with the Move Up and Move Down buttons after they are entered.

As in other areas of the Rule properties, variables can be used, this is typically displayed by right-clicking an appropriate field such as "Path".

Patch Uninstall Commands

Path uninstall commands are the same as the Patch Install commands.  A combination of actions can be defined to uninstall a patch, undo a configuration change, etc.

Tips and Tricks

In order to see examples of vulnerability definitions and rules, you can right-click any existing definition (custom or not) and select "Clone".   This will create a duplicate of the definition that will show up in the Custom Vulnerabilities category and can be edited.

This is a great way to learn how to create detection logic and installation commands.