I've got patches piling up.
the repairs are failing due to "Status marked as detected because pre-req check failed."
not sure how to go about troubleshooting this. its started with the new patching process this year.
I do have the MS registry key set on the computer I am using to try and get patched first.
example:
Microsoft released KB4058702 late the night of 1/3/18 (out of band) to address an Intel CPU firmware vulnerability. The patches released will be added to our patch definition update to be released later today, 1/4/18.
List of patches from Microsoft:
https://www.catalog.update.microsoft.com/Search.aspx?q=2018-01
Additional Information
Important information on detection logic for the Intel 'Meltdown' security vulnerability
Hello all,
I have downloaded the Next Gen patch definitions. I am unable to download the associated patch file for any of these. Most give me this error that the hash "does not match with the host". 
Has anyone else encountered this?
-Pat
Hi
I am very new to the forums and Landesk in general
I have a problem upgrading windows 10 from 1511 to 1709 using patch and compliance.
Here is what I've done so far
I followed the below guide, downloaded the ISO from our Microsoft portal, we have both Enterprise and Pro in our environment so I created a file for both of them and Landesk accepts them both as downloaded
How to upgrade to Windows 10 Creators Edition using Ivanti Patch Manager
Then I distributed the ISO's to our preferred server and created a repair job
this job I sent to a specific machine and within 2 minutes it showed Success
now for my stress factor..
Noting happened on the machine itself, I cannot see the package on the machine and it does not patch.
I have created several software packages and set up PXE booting for the environment but this one I cannot solve
I sent a package to the machine to check if I could install to it, and that works as it should
I hope you guys can point me in the right direction
Is anyone else having issues with the detection logic for this months Windows 10 patches?
I continue to get the same error on a couple machines: Registry key 'SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_for_RollupFix_Wrapper~31bf3856ad364e35~amd64~~16299.248.1.17', value 'CurrentState', contents '64' should contain '112'
The machine just continually attempts to patch, say's it was successful, asks for a reboot, but the detection doesn't go away.
I found this article: https://support.microsoft.com/en-us/help/4074588/windows-10-update-kb4074588
stating:
Even though the update was successfully installed, Windows Update incorrectly reports that the update failed to install. Select Check for Updates to confirm that there are no additional updates available.
You can also type About your PCin the search box on the taskbar to confirm that your device is using the expected OS build.
Microsoft is working on a resolution and will provide an update in an upcoming release.
I've noticed that over the last couple months as definitions have been rolled out, I'm no longer seeing any custom variables in them. Previously I would use custom variables to force updates for Firefox and Java, and disable auto update/enable silent update for Flash, but the newer versions of these definitions are missing the custom variables. Has this functionality been deprecated?
Ivanti EPM uses the vulnerability scanner process (vulscan.exe) to evaluate and conduct necessary reboots. Vulscan considers your agent settings and references Windows API and two specific registry keys to determine whether or not a Windows device needs a reboot. Having the agent installed on your devices allows them to present a reboot GUI to your end users if a reboot is pending and if your Agent Settings configuration allows. Depending on your agent settings options and the tasks you are deploying, vulscan may cause the device to prompt for reboots multiple times.
Under some circumstances multiple reboot prompts may appear in short order, even after allowing a reboot. Distribution and Patch agent settings, along with Reboot settings, are very flexible and can be configured in many different ways. Sometimes the combination of options chosen causes unexpected behavior. This document provides an overview of the applicable systems and settings, and discusses some common reasons and configurations that may result in multiple reboots or reboot prompts.
This document focuses on reboots triggered via patching instead of a software deployment task (sdclient) but for the most part the lessons herein apply to sdclient as well
It is normal expected behavior for vulscan to detect if a reboot is pending. It does so during every scan job by evaluating the presence of the below registry keys:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager]
"PendingFileRenameOperations"
The vulscan log will contain this text:
Pending file rename data is present. Reboot is needed.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\WinClient\VulscanReboot ]
The vulscan log will contain this text:
Vulscan reboot key exists. Reboot is needed.
Detecting that a reboot is pending does not automatically cause vulscan to process that reboot.
Vulscan detects when reboots are pending during any job but will only process a reboot when all of the below conditions are met:
Whether a reboot is pending will be detected anytime vulscan runs but scan only tasks will not cause reboot conditions to be evaluated or a reboot to be triggered. Vulscan must actually process the install phase due to a repair task or autofix in order to subsequently process the reboot phase.
The keys mentioned previously are set by the OS or by vulscan. They are volatile and should be removed when the device reboots. Under some circumstances (for example if either key is manually set) they aren't removed upon reboot. This causes vulscan to detect a pending reboot again the next time it runs, although as mentioned previously detecting that a reboot is pending is not enough by itself to cause a reboot to happen.
If you determine that either key is stuck, it's usually sufficient to manually delete the key. Afterward, it should be volatile when the OS or vulscan next set the key.
You may also find at times that faulty applications constantly re-set the Pending File Rename Operations key. The key identifies the files in question that are pending and you can use this info to identify the misbehaving application. You may need to work with the application vendor's support team to identify and solve why it keeps setting reboot keys.
Your distribution and patch settings contain a 'continuation' option:
Continuation allows vulscan to automatically continue a repair task after the computer reboots or other necessary prerequisites are met. A common situation that triggers continuation is when patching must halt due to a pending reboot, or when some patches fail due to a necessary reboot. After the reboot occurs, vulscan can automatically continue and may repair additional patches. If vulscan attempts an install, even if it's due to continuation, it will evaluate your reboot settings and if allowed, may reboot or prompt the user to reboot. By default Continuation is allowed up to 5 additional repairs.
Important note: continuation only applies if you have started a repair task. Continuation cannot give vulscan permission to install patches unless you granted this permission to the original repair task
It is unfortunately true that many end users don't understand technology as well as we'd like, and sometimes misunderstand or misinterpret what they see and experience. Our support teams have encountered many of these situations. One common example is when an end user gets the reboot prompt and chooses to defer. Sometimes the user will log off or lock their computer, or go home for the day, or otherwise forget that they deferred the reboot. The prompt later appears again according to agent settings, and the end user assumes that they are being prompted to reboot again, when in reality they never completed the first reboot.
Beyond educating the user there isn't a lot that can be done to fix this. It is helpful as a first step to determine if\when the computer rebooted and which process was responsible for it. You can most easily see this by opening event viewer and filtering the Windows Application logs by event ID 6006 and 6008:
The timestamp of the applicable restarts can be matched up to vulscan logs to get more information
In some cases you may find that the computer did not reboot, or did not reboot due to any Ivanti process.
We've been getting reports of vulscan.exe running outside of our intended/schedule times, and today I learned about Local Scheduler time creep (Local Scheduler and being aware of time creep ).
This is definitely what we're seeing in our environment. Our scans are configured via schedule in the agent's Distribution and Patch settings. The schedule is set for 12:00am, with an additional random delay of an hour. No other filters are applied.
Screenshot:
Over time, the drift has caused set our start times to move all over the map, and on some devices the scan presents a noticeable slowdown for our staff. I have been exploring the community to find some examples of good practice that others may be using to address this issue. I've worked through the command line options for "localsch.exe", and while it seems fairly trivial to run a script periodically to reset the start time, I'm hopeful that a better solution exists.
Ultimately, I would like to have the scan begin at a specific time (12:00am is just an example), and only run at that time. I understand that forcing a scan into a window may cause some devices to not be scanned within this scheduled scan (due to device being off, etc...), but I have other mechanisms for dealing with that.
How are you accomplishing this in your environment?
After updating our core to 2016.3 SU7 (I know it's a BETA, but I was hoping fix 382509 would work for us) our Definition updates for Patch and Compliance are failing with following errors:
Signature is not valid
Failed to download platform information
Checking the vaminer.details.log I see several errors:
INFO 6060:LoadingPatchSources : Certificate fail chain of trust validation.
INFO 6060:Main Thread : Signature is not valid
6060:Main Thread : Failed to download platform information
INFO 6060:LoadingPatchSources : Alert.RaiseAlert succeeded : alertId = internal.ldms.SPM.SignaturesDidntMatch
INFO 6060:LoadingPatchSources : File https://patchemea.landesk.com/LDPM8/ldvul.php?KEYWORD=filename&FILENAME=Virus4/10107_updates.xml does not exist
INFO 6060:LoadingPatchSources : About to check source type for preload steps
INFO 6060:LoadingPatchSources : Load: https://patchemea.landesk.com/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&FILENAME=Virus4/
INFO 6060:Main Thread : No updates found.
I have worked with support and re-imported the Digicert GloballRoot CA certificate as a Trusted Root CA, and have tried various settings related to our proxy and firewall with no success. It appears to be related to the 'Verify digital signatures/hashes before downloading setting' which has been enabled in SU7 seemingly without warning (I know it is enabled in 2017.1 and above), but the definition downloads were working in 2016.3 SU6.
How can I get this working again?
Overview
Ivanti Endpoint Manager’s Patch and Compliance tool now welcomes our Next Generation patch engine. This new architecture enables us to continue optimizing well into the future and is only applicable to the Windows environment. As a preliminary feature, we’re providing the ability to opt-in, allowing for a more controlled introduction of all Next Generation content into your environment. The new patch engine is currently available in the 2017.3 product version.
Updated We are now offering this feature in ALL supported versions of the product.
By electing to download Next Gen content, the core will download new vulnerabilities definitions for products that are currently not supported in the standard content stream (i.e. Microsoft Windows Vulnerabilities). This means that if both options are selected (Next Gen Microsoft Windows Vulnerabilities (beta) and Microsoft Windows Vulnerabilities) there will be no overlap in the vulnerability content downloaded to the core.
Note: All images within this document can be viewed full size by clicking on them
In the definition download utility, a new definition type exists under Windows | Vulnerabilities | Next Gen Microsoft Windows Vulnerabilities (beta).
New As of 3 Jan 2018, the Next Gen Microsoft Windows Vulnerabilities (beta) option is no longer applicable. All new Windows Vulnerability (this includes 3rd party software) content has been formatted to use the Next Gen scan engine and is contained under Vulnerabilities | Windows Microsoft Vulnerabilities. Any content downloaded prior to 3 Jan will not be affected by this change.
Please ensure your definition downloads are scheduled to occur (2) times per week for the Microsoft Windows Vulnerability definitions. The recommended download occurrence should be scheduled on Wednesday and Friday evenings.
New
When selected, all associated Next Gen binaries/vulnerabilities definitions will be downloaded to the core. The binaries (about 30 MB) will be contained in Managementsuite \ Ldlogon \ Timber directory and the definition grouping will be based on your configuration and download filters. Upon definition download, the following can be expected:
| Definition Download | Managementsuite \ Ldlogon \ Timber |
|---|---|
 |  |
The Managementsuite \ Ldlogon \ Timber \ Content folder will contain a WindowsPatchData.zip file and associated Delta zip files. The WindowsPatchData.zip file contains all vulnerability detection rulesand the Delta zip files contain the differences. This content, along with the remaining Next Gen binaries, will be downloaded to the endpoint upon scanning against Next Gen content. The main WindowsPatchData.zip file will only be downloaded once, Deltas are downloaded to the Core if there are differences that aren't in the WindowsPatchData.zip file. Once the endpoint has the main zip file, it will only retrieve the Delta zip files when scanning against Next Gen content.
30
Upon definition download completion of Next Gen Microsoft Windows Vulnerabilities (beta), filtering for this definition type can be done by using the filter string "Next Gen". Every next-gen definition has the filter string hardcoded in the Summary column.
To isolate these definitions, a custom patch group can be created to house these definitions. If you elect to do so, a manual transfer has to take place. To further isolate which devices scan against this custom group, an alternate Distribution and Patch agent setting can be configured to scan against this group. More information on how to configure this is outlined in How to Scan and /or Repair against a custom group and How to use Custom Groups to repair groups of computers.
Every Next Gen definition will contain a pre-defined fixed script for Detection and Remediation. The pre-defined detection script will evaluate Registry, File and Script logic to determine if a device is vulnerable to a definition. The detection details have been included at the beginning of the script content. The Files and Registry Settings section will be blank for all Next Gen content.
These scripts are not meant to be modified. Modification of this logic will leave these definition in an unsupported state
| Sample Next Gen definition (Detection Logic) | Sample Next Gen definition (Repair Logic) |
|---|---|
 |  |
Updated The "Enable security scan debug trace log" UI feature is only available in 2017.3 and newer product versions. To enable debug trace logs for versions 9.6 - 2017.1 run the following cmd locally on the endpoint or distribute a script to the desired device:
vulscan /enableDpdTrace=true /showui (the showui switch is optional).
This will generate additional logging in the Programdata\Landesk\DebugLog folder consisting of the following (2) files:
- PatchManifestSyncSDK.log
- PatchScanSDKDpdTrace.log
To enhance the log level for all Next Gen content definitions, the following addition has been made to the Distribution and Patch agent settings:
This feature is only intended for troubleshooting purposes and should not be on in your default agent setting. When troubleshooting a Next Gen content issue, please create an alternate Distribution and Patch agent setting, enable this feature and assign this setting to the device during troubleshooting only.
Updated The "Get debug logs and zip (patch)" feature is only available in 2017.3 and newer product versions.
To retrieve logging remotely access the Diagnostic tool and select the Logs | Client option to view client-side logs. An additional option "Get debug logs and zip (patch)" is present for debug logging for all Next Gen definitions. This will only function if the Distribution and Patch agent setting has Enable security scan debug trace log selected.
If the endpoints are on a supported version of the product, the agent does not need to be updated immediately to take advantage of the enhanced patch engine. All devices on an unsupported product version will need to be upgraded. Upon initiation of the vulnerability scanner, the self-update feature will update the necessary vulscan files to ensure compatibility between the files on the client and the latest files on your 2017.3 core. For more on the Self Update feature please reference About Patch Manager Self Update. These binaries must be updated in order for the Next Gen binaries to work with vulscan.exe.
Scanning:
A security scan works the same as before for all current content. Whenever the scanner encounters a definition with Next Gen content it will launch the fixed script contained within the definition and perform the following actions:
- Check for definition scan results in memory.
- If this is the first Next Gen definition encountered in the current security scan, no scan results will be found on the client and the following will occur:
- The client will check if it needs to download any Next Gen binary files from the core (ldlogon/timber) and transfer them to the LDCLient\Timber directory:
- The detection rules “WindowsPatchData.zip” file (about 14MB) is updated on the content servers every time new content is added and will be download to the client. If WindowsPatchData.zip already exists on the client, the smaller delta files will be used to update this file to the current version.
- Additional Next Gen binary files will be downloaded if the current versions do not already exist on the client:
- The Next Gen COM object is then registered on the client to allow Vulscan.exe to interact with the Next Gen scan engine
- The Next Gen scan engine then scans for ALL vulnerabilities and stores the scan results “in-memory”. A FULL scan of all vul_defs is only completed if this is the first Next Gen definition encountered in the current security scan.
- The script then references the in-memory scan results to determine if the current definition is vulnerable.
The security scan continues scanning as usual. For any remaining Next Gen content definitions in the current security scan, the detection script will return the result of the specified definition from the in-memory scan results.
The Next Gen scanner runs (maximum of once per vulscan instance) it checks for everything and stores that information in memory, but that information is only used by Next Gen definitions. Legacy definitions work the same way they always have.
Remediation:
- Patch files (Default location - Ldlogon/Patch) uses the existing download mechanism "lddwnld.dll" to transfer the patch files to the sdmcache directory on the client.
- The pre-defined remediation script calls the Next Gen SDK with a GUID, Language and a unique file name that’s used for patching.
- A temporary “package” is created during the repair and contained on the client (Programdata\Landesk\Timber\Pkgs) which is used by the Next Gen patch SDK.
The vulscan.log file will continue to serve as the primary log for content detection and remediation, however, several additional logs have been introduced to provide further insight on the activity of the Next Gen content.
- vulscan.log (Programdata\Landesk\Log folder)
- PatchManifestSyncSDK.log (Programdata\Landesk\Log folder)
- PatchScanSDK.log (Programdata\Landesk\Log folder, only created when debug trace logging is disabled)
- PatchScanSDKDpdTrace.log (Programdata\Landesk\DebugLog folder, only created when debug trace logging is enabled)
- STDeploy.log (Programdata\Landesk\Log folder, but only created when repairing)
- TimberDeployEvents.log (Programdata\Landesk\Log folder, only created when repairing)
When attempting to run a vulnerability scan, the scan will fail. On the Windows agent, if running in verbose, you'll see the scan hang on Verifying Device ID with the core. If you browse the logs on the clients, either Mac or Windows, you'll see some 403 error codes similar to the example below.
Action SOAPAction: "http://tempuri.org/ResolveDeviceID" failed, socket error: 0, SOAPCLIENT_ERROR: 5. Status code: 403, fault string: Retrying in 2 seconds...
On the Core, you may see "certificate not presented" for the agent you requested the security scan.
With Enhanced Client Security, it's imperative to have a clean certificate store on the local device for IIS. Having a non-self-signed certificate in the Trusted Root Certification Authority will cause issues. The installer will prompt you to remove bad certificates prior to proceeding with the install, but if you have a GPO that may restore the bad certificate. For more information regarding this issue, see https://help.ivanti.com/docs/help/en_US/LDMS/10.0/default.htm#cshid=RootCertificateConfiguration
More detailed information related to certificate troubleshooting is available here:
About Vulscan and SSL Verification
If you're having an issue with security scans and want to test a potential bad certificate:
On some systems(Core Servers) it may be necessary to change the following registry keys that affect how certificates are trusted:
Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL, Value name: ClientAuthTrustMode, Value type: REG_DWORD, Value data: 2
Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL Value name: SendTrustedIssuerList Value type: REG_DWORD Value data: 0 (False, or delete this key entirely)
For additional information, see Ivanti's article https://help.landesk.com/docs/help/en_US/LDMS/10.0/default.htm#cshid=RootCertificateConfiguration or Microsoft's article https://support.microsoft.com/en-us/kb/2802568
Hello,
I have an enviromnet of about 1200 Windows machines. I need to implement a patching solution which would be minimally affecting users. My users complain about prompts to restart a computer. They shut them down when they end their day after 8 hours of work. This way computers are restarted everyday. Whey i deploy patches the percent of installed patches is low. Most of errors are return code 437 "The device must be rebooted first" but computers were already shut down and started so why do these errors happen? I was thinking about setting "ignore pending reboots" Would that be a good idea in my case?
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)
You will only be offered one or the other and never both.
Related Documentation
Overview
Ivanti Endpoint Manager's Patch and Compliance vulnerability scanner (vulscan.exe), will attempt to download an additional 30MBs (approx.) of data from the core server (source) when scanning against Next Generation definitions. This file download size can stress environments not configured to accommodate this additional data and could cause latency on the network. To minimize the bandwidth constraints, Ivanti's download functionality is designed to retrieve content from (3) locations; Peer, Preferred Server, Source. This document outlines how to stage the Next Generation binaries which allow your existing endpoints to leverage Ivanti's download capabilities allowing for more efficient file transfers throughout your environment.
In order for the Next Generation Binaries to exist on the core server, a download of the Next Gen Microsoft Windows Vulnerabilities (beta) definitions must be completed from the Download Updates interface. The required binaries for scanning against Next Generation definitions will reside in ManagementSuite\Ldlogon\Timber.
To control the scanning of all Next Generation definitions, transfer the "Next Gen" definitions to a custom patch group, assign the custom group to an alternate Distribution and Patch agent setting and assign the setting to (1) device per subnet. Once (1) device on the subnet has the necessary binaries to scan against Next Generation definitions, the use of Peer to Peer downloading can be leveraged when the remaining devices need the next generation binaries.
The steps to do so are as follows:
This is accomplished by right-clicking and selecting "New Group" in Patch and Compliance | Groups | My custom groups. Name the group as desired; in the below example the custom group name is "Next Gen".
To do this, perform a search in Patch and Compliance | All Types for keyword "Next Gen". Once filtered, highlight (ctrl+a) these definitions and move them to your custom patch group. To move you can drag and drop the highlighted definitions to the group or right-click copy and paste.
This can be done by right-clicking "New" after navigating to Agent Settings | My Agent Settings | Distribution and Patch
Right-click on the alternate Distribution and Patch agent settings and select properties. From this view select Patch-only settings | Scan Options. In the "Scan for" section select Group and associate your custom group for scanning and save. This will restrict the vulnerability scanner's view to the definitions residing in this group. Any device assigned this setting will only be able to scan definitions from this custom group.
This new setting configured to scan against only Next Gen definitions has to be assigned to (1) device per subnet. This will allow the vulnerability scanner to download the next generation binaries to the endpoint. Once these binaries reside on (1) device in the subnet, all remaining devices will be able to pull the files from a peer negating the need to traverse the network to the source.
To do this select "Create a task" and choose "Change Settings" under Agent Settings.
This will present you with a Patch and Compliance - Change Settings task interface. Choose the alternate agent setting previously configured to scan against "Next Gen" definitions and select save. Upon saving, a change settings task will be created for you to target the desired subnets throughout your environment.
The same approach taken with Peer can be done with a Preferred Server on the same subnet as your endpoints. You are less likely to have (1) Preferred Server per subnet so it is recommended to use the functionality available through Content Replication to transfer for the Next Generation binaries from the source to a preferred server.
The following documentation outlines How to use Ivanti EPM Content Replication
About Distribution and Patch Bandwidth Throttling (Advanced)
How to troubleshoot Download Failures in Software Distribution (Advanced)
Hello all,
Trying to create a custom query to see the last successful patch installation date. What I mean by this is if you go to a machine and go to "Security and Patch Information" then go to "Clean/repair History" you'll see the last repair/install of a patch and the date. I'd like to create a query that will show me this.
So far all I've come up with is this:
"Computer"."Patch and Compliance Definitions"."Patch Install Date" > "GetDate() -31"
Which only shows me ones that HAVE updated in the past 31 days. Reversing the greater than sign actually gives me no results (EDIT: technically it gives some, I was also sorting by OS which originally gave me none), and I couldn't figure out a way to properly reverse things -- There are even some machines with nothing in the clean/repair log, which I expected to show. So, clearly something's a bit off with my thinking, and I can't figure out what it might be.
Also, in a means of sorting things, I'd like them sorted by date order. I tried adding in the same parameter (Patch Install Date) and sorting by that, but what it wound up doing was creating a seperate entry for each patch that was installed (so three patches installed means the machine was listed three times).
Any help in these areas would be greatly appreciated, though obviously the actualy query is more important than the sorting.
Thanks in advance!
Although we support many products and patches, there are times when customers encounter support gaps. This document outlines how to request support for new patches or products not currently supported by Ivanti Patch Manager.
All requests for new Patches and Products should be submitted through our Ivanti Ideas Patch Content forum. The Ivanti Ideas portal utilizes the same login as our support and community portals.
All non-content-related feature requests should be submitted through the enhancement request forum here: Enhancement Requests
This document details common patch content download issues and the troubleshooting steps involved in troubleshooting and resolving the issue.
There are three different patch content servers, DNS on the core server must be able to resolve these hostnames.
DNS on the core server must be able to resolve these hostnames. In addition, the Ivanti core server will contact the following addresses:
If using Ivanti Antivirus, the following URL's will be used for pattern file downloads:
[1-9] and [01-19] denote separate entries such as http://downloads1.kaspersky-labs.comand http://dnl-01.geo.kaspersky.com.
The following ports need to be allowed to the core server:
Check the proxy configuration and credentials within the Proxy tab of the Download Updates section of the Patch and Compliance tool.
If it does require login credentials which format does it require?
- DOMAIN\username
- username
The following steps should be followed:
If anything is missing, incorrect (such as product version is wrong), or shows as expired you should reactivate your core server.
From within the Core Server Activation Tool, make sure the Contact Name and Password are correct and click "Activate".
If you have reactivated and the information still does not appear correct, contact Ivanti Support to investigate further. If either is expired, contact your Sales Representative or the Licensing Queue at Ivanti Support for further assistance. This can be done through the Self Service Portal or via Telephone.
A screenshot of the Licensing screen from the Core Activation Utility would be advised to give to Ivanti Support.
If a particular vendor's updates fail to download (for example Adobe, Java, etc), this is most likely due to a proxy or other internet appliance configuration.
The proxy or Internet appliance must be configured to allow the core server access to various vendor download sites, both on HTTP and FTP.
For a complete list of the URL's used by Ivanti patch content, consult this article.
For patches that are already in the Scan folder that are from the vendor you wish to exclude:
To automatically assign the unwanted vendor patches to the "Do not scan" folder as they are downloaded:
See articlePatch Download Settings - custom settings reverted back to original options
See the article How to change the default Patch Location for Security and Patch Manager?
Security patch updates are generally available within a 48-hour window.
See article Error when downloading content "Hash for patch does not match with host. Discarding."
When this error occurs, there is likely another update process that is still taking place, possibly from a scheduled task, or a previous download process has hung.
Another possible cause is another user logged into the core server using Remote Desktop in a separate session.
Typically closing and reopening the Management Suite console will resolve this error.
If a Remote Desktop session is not being used or is being used in an Admin Session, and the Core Server has been rebooted and the error still does not go away, it is possible that there is a lock entry in the database that needs to be cleared.
Within SQL Management Studio, connect to the Management Suite database, open the Query Tool, and do the following:
select * from PatchSettings where Name like '%LOCK.UpdVulnLock%'
If entries, as pictured below, are returned, those rows should be deleted:
In order to delete the rows, run the following query:
delete from patchsettings where Name like '%LOCK.UpdVulnLock%'
When trying to download updates for definitions through Patch and Compliance Manager all patches and of the following errors is given:
"Object does not match the specified SHA-256 hash" or "Signature is not valid, failed to download platform information"
To resolve this, uncheck the box "Verify definition signatures/hashes before downloading" on the Content tab of the Download Updates window.
See article Error: "You have not specified a site from which to download updates" when downloading updates in Patch Manager
The Global Autofix and Reboot settings can be set up in the Agent configuration> Standard LANDesk Agent page, but once configured it seems there is no way to update it by a Change Setting task, or by simply updating on the Agent configuration and save the setting. Some believe that the Agent will need to be redeployed in order to overwrite the existing Global Autofix and Reboot settings. This document provides a way to update those settings without having to redeploy the Agents.
1. First it will be useful to get an idea of which Agents have used the Global Autofix and Reboot settings. Follow this article: Displaying the Settings "Never Reboot" and "Never Autofix" in Your Inventory
2. After the above step, an inventory scan will have to be run successfully in order for the inventory information to be synced back to the core server. Then you should be able to see an entry like the following in the Agent's inventory:
NOTE: If the Agent doesn't have the Global Settings configured, the inventory will simply look like this.
3. Locate the Agent configuration that your Agent has been using, modify the Global Autofix and Reboot settings as needed, save the configuration.
4. Right click on the Agent configuration, and select Schedule Update to Agent Setting to create a scheduled task.
5. Drag and drop the Agents you need the setting to be modified and start the task.
6. When this is done, start an inventory scan on the Agent machines and you can see that the above entry in the inventory value has changed.
Displaying the Settings "Never Reboot" and "Never Autofix" in Your Inventory
Note: This feature is enabled by default in EPM 2017.1 and newer and cannot be disabled in these versions.
This article describes the content verification feature within Ivanti Patch and Compliance Manager
Content verification can be enabled to cause the Ivanti EPM Core server to add in a hash checking feature when downloading content from the Ivanti EPM Patch Content servers.
The content verification feature applies to the content only, it does not apply to individual patch files themselves. The patch file hash information is contained within the definition information and is verified as part of the patch installation process.
Content verification is only available for the following content types:
Note: When content verification is enabled, but content types other than the types mentioned above are downloaded (Apple Macintosh definitions, for example), errors may be thrown.
Example of errors for content types that do not support Content Verification:
Even though an error is thrown, the content is still downloaded correctly.
Content verification can be enabled within the Download Updates tool under the Content Tab:
This feature was updated in Ivanti EPM 2017.3. The verification option is now greyed out as this feature is baked into the Patch Download Tool and enabled by default.
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.
Hi
I've been struggling to deploy any Citrix patches beyond version 4.8. The patch definitions (in my mind) appear to be wrong or the downloads do not work.
Does anyone have any idea what we are supposed to do with the latest Citrix patch definition that came through last night?
It is not downloadable and gives no information in the description as to whether this is a manual download or not.
Presumably I have to find the same version from Citrix manually, in which case, do I then have to rename the file?
Many thanks for any help you can offer!