Overview

Ourpatchengine allows binary updates through definition downloads. At times it is necessary for us to make changes to some of the binary files to remediate issues.

When changes are made to these binaries and they are published to our patch servers they will automatically be downloaded to the core (during the next content sync initiated by the core). When the client next scans in, it will check to verify what version of these binaries it has compared to the version on the core server. If needed, these binaries will be downloaded to the client automatically using the standard download mechanism (i.e., utilizing the CSA and/or preferred servers if configured).

We only make changes to these files if it is found necessary to correct a critical issue. Below lists the file(s) updated,

the date, and the reason why the change was necessary. We will update the list before every expected change to binaries. However, in some cases more urgent fixes are required, and in such cases we will only be able to post the change to this list a short time before the release

Updated Binaries

Overview

Microsoft has identified a severe compatibility issue with a small number of anti-virus software products.

We highly suggest all customers review these issues here:  https://support.microsoft.com/en-us/help/4072699

Due to to possible BSOD issues that may occur when installing this update on system with out of date AV software, we will be adding a detection prerequisite as Windows Update does:

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"

Value="cadca5fe-87d3-4b96-b7fb-a231484277cc"

Type="REG_DWORD”

If key does not exist you will be offered the detection only version of this patch.

This means that the associated patch for a system will not be remediated unless the Registry key is present. This mirrors how the patches are handled by Microsoft. Full details regarding the offering of the patch, and options if the Registry key is missing, are located in the Microsoft article here: https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released

The patches will be offered for deployment if the key exists.

Affected patches:

• MS18-01-IE Q4056568
• MS18-01-SO7 Q4056897
• MS18-01-SO8 Q4056899
• MS18-01-SO81 Q4056898
• MS18-01-W10 Q4056888, Q4056890, Q4056891, Q4056892, Q4056893

Affected CVEs:

• CVE-2017-5753
• CVE-2017-5715
• CVE-2017-5754

Link to Security bulletin advisory:  https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

Set up Definition Filter Rules by Product to Automatically move to a Custom Folder

Note: All images within this document can be viewed full size by clicking on them.

This document will teach you how to setup definition filter rules by affected product in the Download Updates > Definition Download Settings section when downloading future updates.  For this example we will set Google Chrome definition updates to go to a group folder named Chrome in the console.

Open patch and compliance by going to Tools > Security and Compliance > Patch and Compliance.  Next find and double-click a patch who’s future updates you want to set up a rule for, in our case, we used the current Google Chrome patch.

Then double-click a file name in the Detection Rules section.  Then click on Affected Products.

In the Products section make a note of the wording used by the definition.  In our case the word "Chrome" is relevant so we will use that.

Close out of the dialogs and open the Download Updates by clicking on the icon on the Patch and Compliance menu bar.

Once the Download Updates dialog is open click on the Definition download settings… button in the lower right corner.

Once the dialog is open click New on the bottom.

On the Filter tab create the filter by Selecting Vulnerability and Any in the lower tabs.  Then in Comparison Choose Product, contains, and Type out Chrome.  You can be as general or granular here as you want.

Next go to the Groups and Tags tab.  Check the Put Definition in custom group(s) box and click Add.  Then select the group you want to put the definition in.  In our example, it is named Chrome.

Click Ok in all the dialogs to close out of all of them.  You should see the new filter present in the Definition download settings dialog. Any new Chrome updates will be automatically added to then Chrome folder.

If you run a Download Updates now and there were definitions with the word Chrome in the product information.  They would be placed in the Chrome folder.

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

Ivanti Agent May Continually Prompt to Reboot

• Ivanti Agent May Continually Prompt to Reboot
  • Detecting a Pending Reboot
    • Pending File Rename Operations
    • Vulscan Reboot Registry Key
  • When is Vulscan Allowed to Reboot?
  • Common Causes
    • "Stuck" registry key
    • Continuation
    • User Error

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.

Detecting a Pending Reboot

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:

Pending File Rename Operations

[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.

Vulscan Reboot Registry Key

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\WinClient\VulscanReboot ]

The vulscan log will contain this text:

Vulscan reboot key exists. Reboot is needed.

When is Vulscan Allowed to Reboot?

Vulscan detects when reboots are pending during any job but will only process a reboot when all of the below conditions are met:

1. One of the above registry keys indicates a reboot is pending
2. Vulscan attempted to install patches (a scan-only job will not trigger reboot processing)
3. The applied agent settings give vulscan permission to reboot the device (vulscan will still process any end user prompts, honor automatic reboot conditions, and honor the automatic reboot window (if configured)).

Common Causes

"Stuck" registry key

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. 

Continuation

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.

User Error

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:

In some cases you may find that the computer did not reboot, or did not reboot due to any Ivanti process.

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.

Definition Downloads

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.

^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.

Content Changes

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.

Sample Next Gen definition (Detection Logic)	Sample Next Gen definition (Repair Logic)

Distribution and Patch Agent Setting

^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.

Diagnostic Tool

^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.

How Does Scanning and Remediation Work

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:

 

1. Check for definition scan results in memory.
2. 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:
   1. 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:
      1. 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.
      2. Additional Next Gen binary files will be downloaded if the current versions do not already exist on the client:
   2. The Next Gen COM object is then registered on the client to allow Vulscan.exe to interact with the Next Gen scan engine
   3. 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.
   4. 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:

 

1. 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.
2. 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.

 

Logging

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)

Pre-Staging Next Generation Binaries

Pre-Staging Next Generation Binaries

Overview:

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.

Cause

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

Validation

If you're having an issue with security scans and want to test a potential bad certificate:

1. Open Internet Information Services (IIS) Manager
2. Expand the Sites and click on the WSVulnerabilityCore application.
3. Open SSL Settings and set Client Certificates to 'Ignore' (default is 'Accept').
4. If the scan works, that is indicative of the problem. Leaving the configuration at Ignore is NOT recommended and could compromise the Enhanced Client Security.  This is just to test to see if a bad certificate is the cause.

Fix

1. Launch certmgr.msc on the Ivanti Endpoint Manager Core Server
2. Expand Trusted Root Certification Authorities
3. Click on the Certificates sub folder and review the certificates in the store, paying particular attention to the Issued By category.  Look for certificates that are not signed by the server itself or by a certificate provider and remove them.

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

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 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.

Peer Staging

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:

Step 1: Create a custom patch group.

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".

Step 2: Isolate the Next Gen definitions and add them to the custom patch group.

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.

Step 3: Create an alternate Distribution and Patch agent setting

This can be done by right-clicking "New" after navigating to Agent Settings | My Agent Settings | Distribution and Patch

Step 4: Assign the custom group to an alternate Distribution and Patch agent setting

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.

Step 5: Assign the alternate Distribution and Patch agent settings to a device

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.

Preferred Server Staging

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

References

About Distribution and Patch Bandwidth Throttling (Advanced)

How to troubleshoot Download Failures in Software Distribution (Advanced) 

Description

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.

Overview

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

How to troubleshoot Core Server patch content download issues

This document details common patch content download issues and the troubleshooting steps involved in troubleshooting and resolving the issue.

Log Locations

Patch content download activity

• \Program Files\LANDESK\ManagementSuite\log\console.exe.log
• \Program Files\LANDESK\ManagementSuite\log\vaminer.log
• \Program Files\LANDESK\ManagementSuite\log\vaminer.details.log

Antivirus content (pattern files) downloads

• \Program Files\LANDESK\ManagementSuite\log\getbases.exe.log
• \Program Files\LANDESK\ManagementSuite\log\updatevirusdefinitions.exe.log

Cannot connect to Ivanti Patch Content servers and/or vendor patch download locations

Patch Content Servers - DNS Resolution

There are three different patch content servers, DNS on the core server must be able to resolve these hostnames.

• US West Coast (patch.LANDESK.com)
• US East Coast (patchec.LANDESK.com)
• EMEA (patchemea.LANDESK.com)

DNS on the core server must be able to resolve these hostnames.  In addition, the Ivanti core server will contact the following addresses:

• community.LANDESK.com
• cswebtools.LANDESK.com
• license.LANDESK.com
• Various vendor patch URL's as detailed in this article.

Ivanti Antivirus URL's used

If using Ivanti Antivirus, the following URL's will be used for pattern file downloads:

• http://downloads.kaspersky-labs.com/
• http://downloads[1-9].kaspersky-labs.coms
• http://dnl-[01-19].geo.kaspersky.com/

Open Ports

The following ports need to be allowed to the core server:

• Port 80 (for access to patch download URL's)
• Port 21 (for access to patch downloads from FTP sources)
• Port 443 (for secure HTTPS access to the patch content servers)

Proxy Configuration recommendations

Check the proxy configuration and credentials within the Proxy tab of the Download Updates section of the Patch and Compliance tool.

• Is it set to use a proxy server?
• Does your environment require a proxy server?
• Is the proxy server address correct? (Can the core server reach the IP, server name or FQDN?)
• Is the port correct for what the proxy server is configured to use?
• Is this an HTTP based proxy?
• Does it require login credentials?

If it does require login credentials which format does it require?

- DOMAIN\username

    - username

- username@domain.com

Vulnerability content category not showing up in the Download Updates window

The following steps should be followed:

1. From the Start menu on the core server go to All Programs --> Ivanti --> and run "Core Server Activation"
2. Within the "Activate Ivanti Core Server" utility click on "Licenses"
3. Compare the licenses listed with your licensing agreement.  Are any expired?  Do you have all of the licenses you expect to have?
4. Reactivate the core server by clicking on "Activate"

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.

A particular vendor's updates fail to download - Likely Proxy configuration required

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.

How to exclude scanning of patches from a certain vendor

For patches that are already in the Scan folder that are from the vendor you wish to exclude:

1. In the "Find" section put in the name of the vendor you wish to exclude and then under "In column" select "Vendor"
2. Select all of the vendor patches that show as a result of the search, and then drag them into the "Do Not Scan" folder.

To automatically assign the unwanted vendor patches to the "Do not scan" folder as they are downloaded:

1. Click the "Download updates" tool. (Yellow diamond with black down arrow).
2. Under "Definition Grouping" click the "Definition group settings" button. 
   
   The definition grouping option is not available in SP2 or earlier, it is a feature added with the Patch Manager component patch
   
3. Click "New" to define a new filter.
4. Select "Vulnerability" under "Definition Type" and "Any" under "Severity"
5. Under "Comparison" select "Vendor" and "equals" and put in the vendor name you wish to exclude.

Patch storage folder resetting back to defaults

See articlePatch Download Settings - custom settings reverted back to original options

How to change the default patch download location

See the article How to change the default Patch Location for Security and Patch Manager?

How long will it take for Ivanti to release new vulnerability definitions?

Security patch updates are generally available within a 48-hour window.

Error "Hash for patch does not match with host. Discarding." when downloading content

See article Error when downloading content "Hash for patch does not match with host. Discarding."

Error: "Waiting for file lock" when downloading patch content

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%'

Error: "Object does not match the specified SHA-256" hash

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.

Error: "You have not specified a site from which to download updates" when downloading updates in Patch Manager

See article Error: "You have not specified a site from which to download updates" when downloading updates in Patch Manager

Purpose

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.

Step by Step

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.

Relevant Articles

Displaying the Settings "Never Reboot" and "Never Autofix" in Your Inventory

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:

• Microsoft Windows Vulnerabilities
• Microsoft Windows Security Threats
• LANDesk Updates

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:

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.

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.

Purpose

The purpose of this document is to provide more information about severity and supersedence in Patch Manager.

Explanation of Severity

The patch types in Patch Manager are primarily categorized as Security and Non-Security Updates.

In Patch Manager Security Updates will have the severity rating associated with it in the "Severity" column, this is set to what the Vendor has assigned.

Non-Security Updates do not use the "Severity" column, that value will be marked as NA, if this is a Critical Non-Security Update then you will see "Critical Update" in the column "Category"

Explanation of Supersedence

In Patch Manager we do not set any Non-Security Updates to supersede a Security Update. This is done on purpose. There are times the vendor will supersede a Security Update with a Non-Security Update but we do not set that Supersedence.

Additional Information

Description of the standard terminology that is used to describe Microsoft software updates

Description of Update Types

Security update

Definition: A widely released fix for a product-specific, security-related vulnerability. Security vulnerabilities are rated by their severity. The severity rating is indicated in the Microsoft security bulletin as critical, important, moderate, or low.

Update

Definition: A widely released fix for a specific problem. An update addresses a noncritical, non-security-related bug.

Critical update

Definition: A widely released fix for a specific problem that addresses a critical, non-security-related bug.

Security-only update

Definition: An update that collects all the new security updates for a given month and for a given product, addressing security-related vulnerabilities and distributed through Windows Server Update Services (WSUS), System Center Configuration Manager and Microsoft Update Catalog. Security vulnerabilities are rated by their severity. The severity rating is indicated in the Microsoft security bulletin as critical, important, moderate, or low. This Security-only update would be displayed under the title Security Only Quality Update when you download or install the update and will be classified as an "Important" update.

Monthly Rollup

Definition: A tested, cumulative set of updates. They include both security and reliability updates that are packaged together and distributed over Windows Update, WSUS, System Center Configuration Manager and Microsoft Update Catalog for easy deployment. The Monthly Rollup is product specific, addresses both new security issues and nonsecurity issues in a single update and will proactively include updates that were released in the past. Security vulnerabilities are rated by their severity. The severity rating is indicated in the Microsoft security bulletin as critical, important, moderate, or low. This Monthly Rollup would be displayed under the title Security Monthly Quality Rollup when you download or install. This Monthly Rollup will be classified as an "Important" update on Windows Update and will automatically download and install if your Windows Update settings are configured to automatically download and install Important updates.

Disclaimer

Please read this disclaimer before using this tool:  LANDESK Share IT Disclaimer

Description

We created a GUI tool to simplify diagnostic scanning to troubleshoot patch scan issues.

The DPDTrace GUI interface requires .Net 2.0 or greater to work.

How to use the DPDTrace GUI

1. Download the latest version of the DPDTrace GUI. Download Link(the download is also attached to the bottom of this document)
2. Extract the DPDTrace.zip to the desktop of the machine you will scan from.  This can be on a server remote to the target machine or on the target machine itself.  Support may specify where to scan from depending on the issue being diagnosed.
3. Open the DPDTrace GUI by double-clicking DPDTraceGUI.exe from the extracted folder.

4. Choose Local to scan the local machine. The IP address or the Machine Name of the local machine will automatically populate.    

5. Choose Remote to scan a remote machine. You will need to provide a valid Machine Name or IP Address to scan.    

6. Enter a username with administrator access to the target machine.        

      a. The format must be DomainName\UserName or MachineName\UserName depending on how you are authenticating to the target machine.    

7. Enter a valid Password. You can choose to un-check the Hide option if you wish to see your password for troubleshooting purposes.

OEM Version: (EPM Customers)

8. Choose the OEM scan engine version  9.3.2644 to be used during the scan.

Patch Type:

9. Choose Patch Type to be used during the scan.

          a. We highly suggest leaving the defaults of Security Patches and Non-Security Patches selected unless a support tech requests a change.

10. Click Run to start the scan.

11. You will see Command Prompt popups and popups for the Rename HF.Log utility during the scan process.  Do not close either these.

12. All popup windows will close and a new popup will occur once the scan is complete.  Click OK.

13. The scan diagnostic is complete and all of the trace logs, scan outputs and registry exports have been zipped to this folder:  C:\Users\UserName\Desktop\DPDTrace\SendToSupport

          a. The zip file will be named HFCLi_YearMonthDay.zip

14. Provide this zip files to support!  If you have any issues attaching this zip to the case, please let the support tech know so they can provide you with more options.

Additional Information

A command line DPDTrace tool can be used by customers who cannot run this GUI version:  DPDTrace command line logging tool used for patch detection issues

You receive word that some end users were prompted to reboot multiple times.  This document is intended to help you identify what reboots occurred and why.

MORE INFORMATION

The most common reason for reports of multiple reboots is user error.  If your reboot settings are such that they prompt the user but do not force an automatic reboot, many end users will snooze the reboot multiple times.  They leave for the day locking or logging out of their computer and come in the next day to see a new reboot prompt.  They assume that they are being prompted for an additional reboot when in fact they are being prompted for the same reboot that they snoozed the day before.

The first questions you should ask the end user is, "Did you snooze the reboot?" and, "When did your computer actually reboot?"

The Ivanti EPM agent does not track reboots.  If you view the Security and Patch information for a device, the Clean/Repair History section will show when the device logged out and logged in, and rebooting the device does show up as a logout event, but you can't tell from this information whether the device actually rebooted or just logged out.  For this reason this information should not be relied on or considered an accurate log of rebooting.

HOW TO TELL WHEN A DEVICE LAST REBOOTED

To rule out user error you can check to see the last time the device rebooted.  If you have physical access to the device, just open a CMD prompt and run this command:

systeminfo | find /i “Boot Time”

You will see the date and time of the last reboot or shutdown:

From the Ivanti EPM console, you can right-click the device and go to Inventory.  Select OS from the options on the left and you will see the Last Start Up Time.  Keep in mind this is the last time the device started, which may have been a shutdown event that took place earlier and not necessarily from a reboot:

It is also helpful to see how many times a device has rebooted and when.  To do this you'll need to search the Event logs on the device.  Look at Windows Logs -> System.  Filter the current log and look for Event ID 13 (shutdown event):

PATCH INSTALL & CONTINUATION

If you determine that the device did actually reboot multiple times, the next step is to determine why.  Continuation is one legitimate reason why Ivanti EPM would cause multiple reboots.  If some patches were installed, but a reboot is required before additional installs can take place, the vulnerability scanner (vulscan.exe) will set a continuation task in the LANDESK local scheduler so that vulscan starts again after the reboot.  When vulscan runs again, it may cause an additional reboot.  By default, Continuation is allowed for up to 5 additional repairs.  This can be configured or disabled in your Distribution and Patch settings:

PATCH DETECTION ERRORS & AUTOFIX

Another possible cause for multiple reboots is incorrect patch detection.  If you are using Autofix and a vulnerability has a specific kind of detection error, the patch could be detected as vulnerable and install, only to be detected as vulnerable again when vulscan runs the next day and prompt for another reboot.  This is a rare situation but it is possible.  If you see this happening, move that vulnerability to the Do Not Scan folder to halt the loop and log a case at support.landesk.com to fix the detection issue.  Please include a vulscan log showing the detection when logging a case.

LOGS TO REVIEW

If none of these situations are occurring then we will look at the logs to find out what happened.  If rebooting happened due to a Patching task, the vulscan.log files in c:\programdata\landesk\log will be the most helpful.  Please note - if the user has snoozed a reboot, vulscan will run every 10 minutes to determine if any of the automatic reboot conditions in your Reboot settings have been met.  By default 10 vulscan logs are retained before being overwritten.  This makes it very important to review the logs shortly after the reboot occurs, otherwise, the log which shows the event that originally triggered the reboot will be overwritten.  If it's not possible to retrieve the logs in a timely manner, you can instead increase the default amount of logs that are retained.  This document explains how:

How to:  Retain more vulscan logs before they are overwritten

The beginning of the vulscan log will tell you what type of vulscan task was running and how it started.  Pay attention to the "Command line:" and "Parent process:" sections which can tell you the type of task (repair task vs. scheduled scan only vs. autofix vs. continuation etc.).  The section dealing with rebooting is usually close to the bottom of the log.  If you skip to the bottom and search upwards for "reboot" you will quickly find the relevant information.

While reviewing the vulscan log, pay attention to the agent setting for reboot that was used for the task at hand.  The vulscan log will show the setting by name and ID, and lists the revision number.  If this doesn't match exactly with the setting ID and revision number on your core, then this device is using an out of date or incorrect reboot behavior and you will need to troubleshoot why vulscan is not properly updating agent settings.

If the vulscan logs don't indicate reboots with timestamps that match up to the shutdown events in the Event Viewer, then a process other than Patching caused the reboot.  The next logs to look at are the sdclient_taskxxx.log files located at %LDMS_LOCAL_DIR%.  These are the logs created by software distribution tasks.  Again, the relevant reboot info can be found by skipping to the bottom of the log and searching upward.

If the reboot was not caused by patching or software distribution, then most likely it happened due to a non-Ivanti Endpoint Manager process.

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

• • Background:
  • Step by Step:
  • Reference:

Background:

This is a step by step document guide you how to check the version of your Ivanti Patch Subscription and check if it expired. The most common issue related to Patch Subscription is suddenly you find you cannot download the latest patch definitions anymore manually or automatically on a schedule.

Step by Step:

1. Open the console and confirm the console.exe version.

For your reference:

LDMS 2016.3, EPM 2017.1 and EPM 2017.3 console.exe version is 10.1.XX.

LDMS 2016.0 console.exe version is 10.0.XX.

LDMS 9.6 console .exe version is 9.6.XX

Note: The XX does not matter to the Subscription. The version 10.1 is enough to validate if the license expired.

The below screenshot is taken from EPM 2017.3 SU3 and its version is 10.1.

2. Open Core Server Activation application and click "Licenses". In the pop-out window, check if the next verification date is expired. If it expired, please reactivate the core first.

3. According to the console.exe version which is found in step 1, check if the corresponding Patch Content Subscription expired or not.

Example, you are on EPM 2017.3. Its console.exe version is 10.1. You need to find it in the list and check if the Ivanti Patch Content Subscription powered by Landesk 10.1 expired or not.

4. Please note if you have multiple versions, you only need to validate the version you are using. Such as you have 10.0 and 10.1 licenses and you are on 10.1, you need to check if the 10.1 license expired only.

Reference:

Troubleshooting Core Server Activation

Utility to activate the core server has stopped working

How to Activate the Core Server

How to activate the LANDESK Core Server

How to troubleshoot Core Server patch content download issues

This document details common patch content download issues and the troubleshooting steps involved in troubleshooting and resolving the issue.

Log Locations

Patch content download activity

• \Program Files\LANDESK\ManagementSuite\log\console.exe.log
• \Program Files\LANDESK\ManagementSuite\log\vaminer.log
• \Program Files\LANDESK\ManagementSuite\log\vaminer.details.log

Antivirus content (pattern files) downloads

• \Program Files\LANDESK\ManagementSuite\log\getbases.exe.log
• \Program Files\LANDESK\ManagementSuite\log\updatevirusdefinitions.exe.log

Cannot connect to Ivanti Patch Content servers and/or vendor patch download locations

Patch Content Servers - DNS Resolution

There are three different patch content servers, DNS on the core server must be able to resolve these hostnames.

• US West Coast (patch.LANDESK.com)
• US East Coast (patchec.LANDESK.com)
• EMEA (patchemea.LANDESK.com)

DNS on the core server must be able to resolve these hostnames.  In addition, the Ivanti core server will contact the following addresses:

• community.LANDESK.com
• cswebtools.LANDESK.com
• license.LANDESK.com
• Various vendor patch URL's as detailed in this article.

Ivanti Antivirus URL's used

If using Ivanti Antivirus, the following URL's will be used for pattern file downloads:

• http://downloads.kaspersky-labs.com/
• http://downloads[1-9].kaspersky-labs.coms
• http://dnl-[01-19].geo.kaspersky.com/

Open Ports

The following ports need to be allowed to the core server:

• Port 80 (for access to patch download URL's)
• Port 21 (for access to patch downloads from FTP sources)
• Port 443 (for secure HTTPS access to the patch content servers)

Proxy Configuration recommendations

Check the proxy configuration and credentials within the Proxy tab of the Download Updates section of the Patch and Compliance tool.

• Is it set to use a proxy server?
• Does your environment require a proxy server?
• Is the proxy server address correct? (Can the core server reach the IP, server name or FQDN?)
• Is the port correct for what the proxy server is configured to use?
• Is this an HTTP based proxy?
• Does it require login credentials?

If it does require login credentials which format does it require?

- DOMAIN\username

    - username

- username@domain.com

Vulnerability content category not showing up in the Download Updates window

The following steps should be followed:

1. From the Start menu on the core server go to All Programs --> Ivanti --> and run "Core Server Activation"
2. Within the "Activate Ivanti Core Server" utility click on "Licenses"
3. Compare the licenses listed with your licensing agreement.  Are any expired?  Do you have all of the licenses you expect to have?
4. Reactivate the core server by clicking on "Activate"

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.

A particular vendor's updates fail to download - Likely Proxy configuration required

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.

How to exclude scanning of patches from a certain vendor

For patches that are already in the Scan folder that are from the vendor you wish to exclude:

1. In the "Find" section put in the name of the vendor you wish to exclude and then under "In column" select "Vendor"
2. Select all of the vendor patches that show as a result of the search, and then drag them into the "Do Not Scan" folder.

To automatically assign the unwanted vendor patches to the "Do not scan" folder as they are downloaded:

1. Click the "Download updates" tool. (Yellow diamond with black down arrow).
2. Under "Definition Grouping" click the "Definition group settings" button. 
   
   The definition grouping option is not available in SP2 or earlier, it is a feature added with the Patch Manager component patch
   
3. Click "New" to define a new filter.
4. Select "Vulnerability" under "Definition Type" and "Any" under "Severity"
5. Under "Comparison" select "Vendor" and "equals" and put in the vendor name you wish to exclude.

Patch storage folder resetting back to defaults

See articlePatch Download Settings - custom settings reverted back to original options

How to change the default patch download location

See the article How to change the default Patch Location for Security and Patch Manager?

How long will it take for Ivanti to release new vulnerability definitions?

Security patch updates are generally available within a 48-hour window.

Error "Hash for patch does not match with host. Discarding." when downloading content

See article Error when downloading content "Hash for patch does not match with host. Discarding."

Error: "Waiting for file lock" when downloading patch content

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%'

Error: "Object does not match the specified SHA-256" hash

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.

Error: "You have not specified a site from which to download updates" when downloading updates in Patch Manager

See article Error: "You have not specified a site from which to download updates" when downloading updates in Patch Manager