Issue

Error when downloading content "Hash for patch (Patch Name) does not match with host. Discarding."

You can also be getting the following errors:

Causes and Resolutions

For security purposes, each patch file referenced within a vulnerability definition contains a hash value to ensure that the file referenced is the authentic patch file.

After downloading the patch, if the patch does not match, Patch Manager will discard the file.

There are various causes that can contribute to this issue.

Vendors use static URLs

This issue occurs because the update contains a static URL for the vendor file. This means that the vendor uses the same URL for thier files and they only make the latest patch available to download.

Often this is seen with Adobe and Google Crome updates.

A web caching or other networking appliance within the environment is causing the contents of the file to change or is serving up a deprecated version of the file

This is especially when getting the "Invalid XML file TOC_Product.xml" error.

In many environments, web caching appliances are in place.   When Ivanti Patch and Compliance Manager attempts to download the file, the Internet caching appliance intercepts the request and incorrectly delivers an older version of the file.   Once the file is downloaded on the Ivanti Core Server, the hash check fails.

In this instance, the cache for the particular failed file can be cleared on the Internet caching appliance, the entire cache can be cleared, or the Internet caching appliance can be configured to allow the core server to bypass caching.

Manually copying the file to the patch storage directory from a computer that bypasses the Internet caching appliance can verify that this is the issue.

The patch content needs to be updated as the local content is out of date

If the Ivanti Patch Content has been changed since the last time patch content has been downloaded this error can occur.

Download patch content again.   If the error still occurs, try downloading from a different patch content server (US West Coast, US East Coast, or Europe)

Patch definition content is corrupted in the database

If the latest patch content is downloaded, there are no caching appliance is in the environment, the locally downloaded patch file has been deleted from the storage directory, and there is still a failure, the following SQL query can be run to force the content to download again.

This query changes the LANDESKRevision number to "0".   When the core server compares revision numbers with the revision on the Ivanti patch content servers the version on the Ivanti patch content server will be higher, thus the content will download again:

UPDATE Vulnerability SET LANDESKrevision = 0 WHERE vul_id = 'definition name'

A more advanced variation on this is:

select * from VULNERABILITY where VUL_ID IN ('<vul_no1>', '<vul_no2>')

Update VULNERABILITY 
set LANDESKREVISION=0 where vul_id in ('<vul_no1>', '<vul_no2>')

The file has changed after the patch definition was published

If other steps fail, it is possible that the file has changed, and it is necessary for Ivanti to update the patch content.

It is possible that the vendor changed the contents of the file but kept the same filename, and Ivanti has not updated the related vulnerability definition yet.   At times a vendor will make a change to a file but does not publish information regarding the change.

If this is the case, this download should fail regardless of the Core server attempting the download.   This would be a global issue.

In this instance, contact Ivanti Support and request that the patch content be updated.   An Ivanti technician can also verify the file download failure internally.

Manual download patches

It can be difficult to determine if the hash does not match for patches that must be manually downloaded from the vendor.   Typically these require going to the vendor web site, finding the correct file and version, renaming it to the unique filename specified in the rule for the definition, and placing it into the patch download folder.

Superseded patches are attempting to download

In some cases of hash mismatches it can be caused by a superseded vulnerability. Vendors will occasionally disable the patch download source when a new version of the product is available. Check the vulnerability to see if it hasn't been replaced. You can accomplish this automatically by running a disable replaced rules scan in the following document.

How To: Manage Superceded Patches in Patch and Compliance Manager

Description

Ivanti Endpoint Manager Patch and Compliance Manager may include certain vulnerability definitions which require a manual download of the patch file. The message "Skipping manual download patch..." may be displayed in the Downloading Patches window, as shown below:

Cause

There are a few potential reasons for a patch file to require a manual download:

1. Vendor does not provide patch download URLs.
2. Customers have to get the patches via e-mail or by registering a user on vendors’ website.
3. The different versions of the product updates use the same download URL.
4. The old patches have been replaced by the latest ones. And the download URLs for the old patches are not available.
5. Vendor requires a License Agreement that cannot be bypassed by Ivanti.

Resolution

When a vulnerability definition is marked as requiring a manual download of the patch file, please follow these steps:

1. Download the patch from vendor site manually.
2. Modify the filename as described in the property of the Ivanti Patch definition field.
3. Place the downloaded file into the core server's Patch folder.

Related: How to use Manually Downloaded Patches

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.

Issue

You are getting Server busy, unable to complete request Code 433 on all patch jobs ran on the clients. This can be seen in the status of a patching task in the Scheduled Tasks of the console or seen in a vulscan.log file located on the client.

Cause

Likely patching is still taking place but returning information to the core is unable to complete which is giving this error.  You can verify this by looking in a vulscan log located in the C:\Programdata\LANDesk\Log folder on the client.  In the vulscan.log file at the very end, you should see a postcgi.exe entry like the ones shown below but ending with an error near the end of the vulscan log when it tries to upload data to the core.

A good entry is show here:

Thu, 03 Aug 2017 11:08:39 HTTP POST: http://LDMS20163.ak.local:443/incomingdata/postcgi.exe?prefix=vulscanresults\&name=ScanResults_{E0098567-4CC5-1F41-B922-2D5DDB6B8FDB}_034.vrz
Thu, 03 Aug 2017 11:08:39 Setting a proxy...
Thu, 03 Aug 2017 11:08:39 Setting socket timeout to 1000 * 60 * 4
Thu, 03 Aug 2017 11:08:39 Success

A failing log entry is shown here, the HTTP error code on the end of the failed entry might be different in your environment, note the 433 return code at the bottom of the vulscan log:

Thu, 03 Aug 2017 09:52:18 HTTP POST: http://LDMS20163.ak.local:443/incomingdata/postcgi.exe?prefix=vulscanresults\&name=ScanResults_{E0098567-4CC5-1F41-B922-2D5DDB6B8FDB}_034.vrz
Thu, 03 Aug 2017 09:52:18 Setting a proxy...
Thu, 03 Aug 2017 09:52:18 Setting socket timeout to 1000 * 60 * 4
Thu, 03 Aug 2017 09:52:19 Failed http://LDMS20163.ak.local:443/incomingdata/postcgi.exe?prefix=vulscanresults\&name=ScanResults_{E0098567-4CC5-1F41-B922-2D5DDB6B8FDB}_034.vrz on server (0), server status: 404.
Thu, 03 Aug 2017 09:52:19 HTTP Error 404.  Giving up.
Thu, 03 Aug 2017 09:52:19 Last status: Failed: No response from core
Thu, 03 Aug 2017 09:52:19 Failed to put vulnerability results to core as file: 8DB301B1
Thu, 03 Aug 2017 09:52:19 Skipping repair step because scan errors occurred.
Thu, 03 Aug 2017 09:52:19 ReleaseMutex 'Global\vulscan_scan' succeeded. Code: 0
Thu, 03 Aug 2017 09:52:19 Failed
Thu, 03 Aug 2017 09:52:25 Read from pipe (0x230) failed: 109
Thu, 03 Aug 2017 09:52:25 ClosePipes
Thu, 03 Aug 2017 09:52:25 Exiting with return code 0x8db301b1 (433).

Resolution

Please ensure that the file postcgi.exe is still well present in the folder C:\Program Files\LANDesk\ManagementSuite\incomingdata and that it was not deleted by your antivirus. If the file is still there, please proceed to the following steps:

On the core itself, open IIS Manager.  Select you core name on the left pane then open ISAPI and CGI Restrictions.  An entry for postcgi.exe should be present in ISAP and CGI Restrictions section as shown in the photo.  If one is not present add an entry for it by clicking Add on the right Make sure it is set to Allow and Allow Extension Path to Execute is checked.

The next section to look at is the incomingdata settings under Default Web Site by expanding the tree. You should see two entries under Handler Mappings One for CGI-exe and ISAPI-dll both should be enabled here in incomingdata but they disabled in the other parts of the website this is normal. If they are not enabled or missing, select Edit Feature Permissions on the right menu and check all boxes in the dialog to Enable or Add Script Map to create an entry.

After you make the changes close IIS Manager and run a patching task on the client again.

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.

My core server is 2017.3 SU4 with about 160 clients.  My clients are mixed win7 & win10 Enterprise.  I am experiencing an issue where about half of my clients are completing patching without issue. 

The rest are reporting this error for every patch:

"Downloading file from source http://CoreServer/LDLogon/patch/csi2016-kb4011634-fullfile-x86-glb_tw1220050.exe.

http://CoreServer/LDLogon/patch/csi2016-kb4011634-fullfile-x86-glb_tw1220050.exe

     Failed

     Failed: Could not download http://CoreServer/LDLogon/patch/csi2016-kb4011634-fullfile-x86-glb_tw1220050.exe"

I can log into the client and open a browser and copy/paste the url and the patch will download manually.  However the task fails with the Result of "All patches Failed" and Return Code of "412".

Has anyone seen this behavior?  How do I start to troubleshoot this?

Hi all,

We have noticed that our reboot tasks in LD 2016 is not acting the same as with LD 9.6.  Here is our configuration:

1. Default Reboot Settings in agent > Act as reboot NEVER needed.

2. Task settings created via Patch Manager console > Act as reboot Always needed (with message and deferral option).

In LD 2016, task always returns "Reboot not needed or not allowed" - In LD 9.6, reboot message comes up and device restarts.  So it looks like in 9.6, the task settings would override the default which is what we would expect to happen but in LD 2016, that is not the case.

So another test - I changed default reboot settings on a device to be "Detect if reboot needed"  and pushed a task with "Always reboot" - result was the same - reboot not needed/not allowed.

Is anyone else seeing this?  We want for force regular reboots on devices but after hours and not have reboots kick off if software or a patch is installed during regular hours. 

Thanks

Hallo in die Runde,

nach vielen Jahren der Nutzung deutscher Versionen von LANDesk/Ivanti Management Console wurde die neueste Version englisch installiert.

Sehr hilfreich für die Übersicht in der "Patch and Compliance "Übersicht ist das Sortieren nach Veröffentlichungsdatum.

In der englischen Version ist die Datums-Angabe dd/mm/jjjj --> er sortiert als nach dem Tag im Datumsfeld des Erscheinens.(1/3/2018 steht in der Liste also weiter oben als 3/8/2014)

Das ist ziemlich unpraktisch.

Wie kann ich das Datums-Format umstellen, damit wieder nach dem tatsächlichen Erscheinungsdatum sortiert werden kann?

Freundliche Grüße

Frank Morgner

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

Is there patch for Google earth Pro  in  ivanti Enpoint Manager? I've seen only patch for Google earth  but not Pro.

I have version 2017.

Thank you,

EndPointManager 2017.3 10.1.30.401

Hello, I think I already asked this before but can't seem to understand.

1. Everything under Detected(current scope) is/are (I assume) vulnerabilities found for the Selected Scope

2. If I schedule a repair task for a particular vulnerability, and the task is successful, when are the vulnerabilities removed from the Detected(current scope) Folder?

After point 2 I manually ran on the Client:

a) PolicySync

b)Security Scan

c) Gather Historical Information on the Core

d) restarted the client

e) PolicySync

f)Security Scan

g) Gather Historical Information on the Core

But the vulnerability is still listed there.

What M I missing?

Any help is appreciated.

Best

EPM 2017.3

I'm trying to download 2017.3 SU3 but its skipped, why?

Any help is appreciated,

Best.

Hi Andy,

How are you doing today?

I have two questions for you.

1. I’m trying to push a critical Microsoft patch which is 15 Mo but the status still showing Waiting and it been more than 45 munities what do I have to do?
2. My manager would like to know if there we can do the cloning Hardware with LANDesk Ivinty or you have something else.

Thanks for you feedback

Regards

Andre