Hello Everyone,

I'm a French user of EPM 2017.3 Update 3.

I want to donwload only the Microsoft critical definitions in my "Scan (global) folder in order to scan my client for these vulnerabilites and fix them.

Here are my "donwload" settings :

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Sorry, the sreencaps are in French. Basically i chose to downloade only the definitions for the critical vulnerabilities from MS; but when i donwload are when i look into my "Scan (global)" folder i have almost all definitions that exist (Google, Mozilla, etc... and any type of vulnerabilities.

Does anyone know how to fix this issue ?

Regards,

David.

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

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

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

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

Troubleshooting detection problems in Ivanti Patch and Compliance Manager

Please obtain or verify the following information

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

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

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

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

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

Expectations

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

I can't seem to get any of my endpoints to patch the O365 updates. Have followed the instructions and downloaded the appropriate patches (into the default /patch location, not custom)

One or two machines patched fine but now all of them are failing.

This is the extract from the Vulcan log.

Fri, 21 Sep 2018 09:07:09 Downloaded  C:\Program Files (x86)\LANDesk\LDClient\O365Util.dll

Fri, 21 Sep 2018 09:07:09 Download the following file successfully: O365Util.dll

Fri, 21 Sep 2018 09:07:09 Called CreateProcess: "C:\WINDOWS\system32\regsvr32.exe"

Fri, 21 Sep 2018 09:07:09 Exit Code for process C:\WINDOWS\system32\regsvr32.exe: 3, (0x3)

Fri, 21 Sep 2018 09:07:09 The result of regsvr32 is:  3

Fri, 21 Sep 2018 09:07:09 ReportRepairResult returned failure: Unable to register O365Util.dll

Fri, 21 Sep 2018 09:07:09 Unable to register O365Util.dll

Fri, 21 Sep 2018 09:07:09 Create object of  O365Util

Fri, 21 Sep 2018 09:07:09 ERROR.  Microsoft VBScript runtime error: ActiveX component can't create object: 'O365Util.O365Update' (line: 55, char: 1, text: )

Fri, 21 Sep 2018 09:07:09 Message returned from repair script was ERROR.  Microsoft VBScript runtime error: ActiveX component can't create object: 'O365Util.O365Update' (line: 55, char: 1, text: )

Fri, 21 Sep 2018 09:07:09 ERROR(RunVbScript) Failed to run command  - 80004005

Fri, 21 Sep 2018 09:07:09 DownloadPatch ERROR: Failed to run commands (80004005).

Fri, 21 Sep 2018 09:07:09 Last status: Failed

I've tried deleting the dll and then re-downloading but this hasn't fixed it.

Any help appreciated.

Note: Clicking on a photo will enlarge it.

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

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

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

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

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

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

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

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

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

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

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

Manually Testing the Patch

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

Vulscan Log

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

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

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

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

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

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

STdeployercore.log

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

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

Windows Update(WUSA) Error Codes

Windows Update Agent Result Codes

Description

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

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

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

Possible implementations

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

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

Assumptions

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

Creating a Custom Vulnerability Definition

Vulnerability Definition Help Page

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

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

Detection Rules

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

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

The following Properties for Rule # window will appear.

Give the rule a name, title, and comments as depicted below:
Image may be NSFW.
Clik here to view.

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

Selecting Affected Platforms

Affected Platforms Help Guide

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

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

Creating a custom Affected Product

Affected Products Help

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

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

Query Filter

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

Files Detection Logic

Files used for detection help

Registry settings used for detection help

Custom script detection help

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

Patch Information

Patch Information Help

There are three options available regarding Patch Information:

Image may be NSFW.
Clik here to view.

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

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

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

Detecting the Patch

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

Patch Installation and Removal

Patch Install and Uninstall Help

Stop Processes

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

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

Additional files

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

Patch Install Commands

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

    Image may be NSFW.
Clik here to view.
These actions will be run in the order that they are listed.  You can re-arrange them with the Move Up and Move Down buttons after they are entered.

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

Image may be NSFW.
Clik here to view.

Patch Uninstall Commands

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

Tips and Tricks

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

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

The following error messages were pulled out of the clients vulscan.log when attempting to patch Office 365.  I followed the document and have the patches in the folder specified.  I can browse to the patch folder in a web browser and see the files on the client.

Sun, 30 Sep 2018 16:16:11 -------------------Patch Installation----------------------

Sun, 30 Sep 2018 16:16:11 BeginWaitForMutex 'Global\vulscan_continue'

Sun, 30 Sep 2018 16:16:11 WaitForMutex 'Global\vulscan_continue' succeeded

Sun, 30 Sep 2018 16:16:11 Getting list of autofix patches

Sun, 30 Sep 2018 16:16:11 HTTP POST: http://LANDESK01.ck.c-k.com:443/WSVulnerabilityCore/VulCore.asmx

Sun, 30 Sep 2018 16:16:11 Setting a proxy...

Sun, 30 Sep 2018 16:16:11 Setting socket timeout to 1000 * 60 * 4

Sun, 30 Sep 2018 16:16:12 Success

Sun, 30 Sep 2018 16:16:12 1 patches were found to run

Sun, 30 Sep 2018 16:16:12 Last status: Done.  1 patches were found

Sun, 30 Sep 2018 16:16:12 No patch download required for *MSO365_MONTHLY_16.0.10730.20102_X64

Sun, 30 Sep 2018 16:16:12 Removing local scheduler maint window task: 893751

Sun, 30 Sep 2018 16:16:12 Checking for other running install/repair actions

Sun, 30 Sep 2018 16:16:12 Last status: Waiting

Sun, 30 Sep 2018 16:16:12 BeginWaitForMutex 'Global\SDClientLockMutex'

Sun, 30 Sep 2018 16:16:12 WaitForMutex 'Global\SDClientLockMutex' succeeded

Sun, 30 Sep 2018 16:16:12 Last status: Done

Sun, 30 Sep 2018 16:16:33 Exit Code: 0 (0x0)

Sun, 30 Sep 2018 16:16:33 Launched desktop instance of vulscan to detect full screen apps.  It returned: 0

Sun, 30 Sep 2018 16:16:33 Running patch *MSO365_MONTHLY_16.0.10730.20102_X64

Sun, 30 Sep 2018 16:16:33 Running pre-install/uninstall script

Sun, 30 Sep 2018 16:16:33 ERROR: Failed to open Patch monitoring info HKLM\Software\LANDesk\ManagementSuite\WinClient\PatchMonitoring (0x2)

Sun, 30 Sep 2018 16:16:33 Patch directory : 'C:\Program Files (x86)\LANDesk\LDClient\sdmcache\'

Sun, 30 Sep 2018 16:16:33 Patch name : '*MSO365_MONTHLY_16.0.10730.20102_X64'

Sun, 30 Sep 2018 16:16:33

Sun, 30 Sep 2018 16:16:33 Command Interpreter running

Sun, 30 Sep 2018 16:16:33 Work Path: C:\Program Files (x86)\LANDesk\LDClient\

Sun, 30 Sep 2018 16:16:33 regsvr file:C:\WINDOWS\system32\regsvr32.exe

Sun, 30 Sep 2018 16:16:33 fullPathDll of DLL file:C:\Program Files (x86)\LANDesk\LDClient\O365Util.dll

Sun, 30 Sep 2018 16:16:33 obtaining core server name LANDESK01.ck.c-k.com from scriptable interface.

Sun, 30 Sep 2018 16:16:33 Core server Name:  LANDESK01.ck.c-k.com

Sun, 30 Sep 2018 16:16:33 Hash File: O365Util.dll

Sun, 30 Sep 2018 16:16:33 In SendRequest: Action = SOAPAction: "http://tempuri.org/GetHashForSingleFile"

Sun, 30 Sep 2018 16:16:33 SendRequest: SOAPAction: "http://tempuri.org/GetHashForSingleFile"

Sun, 30 Sep 2018 16:16:33 Action SOAPAction: "http://tempuri.org/GetHashForSingleFile" failed, socket error: 10054, SOAPCLIENT_ERROR: 5.  Status code: -1, fault string:

Sun, 30 Sep 2018 16:16:33   Retrying in 7 seconds...

Sun, 30 Sep 2018 16:16:36 Last status: Retrying in 4 seconds...

Sun, 30 Sep 2018 16:16:37 Last status: Retrying in 3 seconds...

Sun, 30 Sep 2018 16:16:38 Last status: Retrying in 2 seconds...

Sun, 30 Sep 2018 16:16:39 Last status: Retrying in 1 seconds...

Sun, 30 Sep 2018 16:16:41 Success

Sun, 30 Sep 2018 16:16:41 Work Path: C:\Program Files (x86)\LANDesk\LDClient\

Sun, 30 Sep 2018 16:16:41 GetFileHash: could not find "C:\Program Files (x86)\LANDesk\LDClient\O365Util.dll"

Sun, 30 Sep 2018 16:16:41 obtaining core server name LANDESK01.ck.c-k.com from scriptable interface.

Sun, 30 Sep 2018 16:16:41 About to call DownloadFiles (1 files) with these settings:

Sun, 30 Sep 2018 16:16:41 m_allowedBandwidthWAN: 91

Sun, 30 Sep 2018 16:16:41 m_allowedBandwidthLAN: 91

Sun, 30 Sep 2018 16:16:41 m_discardPeriodSeconds: 604800

Sun, 30 Sep 2018 16:16:41 m_preserveDirectoryStructure: 0

Sun, 30 Sep 2018 16:16:41 m_bUseWanBWForPush: 0

Sun, 30 Sep 2018 16:16:41 m_bSynchronize: 0

Sun, 30 Sep 2018 16:16:41 Allowed download methods(m_downloadControl):

Sun, 30 Sep 2018 16:16:41 Peer

Sun, 30 Sep 2018 16:16:41 Source

Sun, 30 Sep 2018 16:16:41 m_preferredServerControl: AttemptPreferredServer

Sun, 30 Sep 2018 16:16:54 http://LANDESK01.ck.c-k.com/ldlogon/O365Util.dll Done

Sun, 30 Sep 2018 16:16:55 Last status: Done

Sun, 30 Sep 2018 16:16:55 Downloaded  C:\Program Files (x86)\LANDesk\LDClient\O365Util.dll

Sun, 30 Sep 2018 16:16:55 Download the following file successfully: O365Util.dll

Sun, 30 Sep 2018 16:16:55 Called CreateProcess: "C:\WINDOWS\system32\regsvr32.exe"

Sun, 30 Sep 2018 16:16:55 Exit Code for process C:\WINDOWS\system32\regsvr32.exe: 0, (0x0)

Sun, 30 Sep 2018 16:16:55 The result of regsvr32 is:  0

Sun, 30 Sep 2018 16:16:55 Create object of  O365Util

Sun, 30 Sep 2018 16:16:55 created the instance ok : O365Util

Sun, 30 Sep 2018 16:17:07 Register C2RCom returnCode:0

Sun, 30 Sep 2018 16:17:07 Custom Variable URL : http://landesk01.ck.c-k.com/Patch/Office365/2016/Current/x64/

Sun, 30 Sep 2018 16:17:07 Patch Binaries URL : http://landesk01.ck.c-k.com/Patch/Office365/2016/Current/x64/

Sun, 30 Sep 2018 16:17:09 ReportRepairResult returned failure: Failed to execute download and apply actions for installer

Sun, 30 Sep 2018 16:17:09 Failed to execute installer. ReturnCode:5

Sun, 30 Sep 2018 16:17:09 Message returned from repair script was Failed to execute download and apply actions for installer

Sun, 30 Sep 2018 16:17:09 ERROR(RunVbScript) Failed to run command  - 80004005

Sun, 30 Sep 2018 16:17:09 DownloadPatch ERROR: Failed to run commands (80004005).

Sun, 30 Sep 2018 16:17:09 Last status: Failed

Sun, 30 Sep 2018 16:17:09 DeferredReportAction: name '*MSO365_MONTHLY_16.0.10730.20102_X64', code '1', type '-1', status 'Failed to execute download and apply actions for installer'

Sun, 30 Sep 2018 16:17:09 App killer is stopping

Sun, 30 Sep 2018 16:17:09 Running post-install/uninstall script

Sun, 30 Sep 2018 16:17:10 RunPatches completed.  1 processed.  0 installed.  1 failures.

Sun, 30 Sep 2018 16:17:10 Sending previous action history to core

Sun, 30 Sep 2018 16:17:10 HTTP POST: http://LANDESK01.ck.c-k.com:443/WSStatusEvents/EventHandler.asmx

Sun, 30 Sep 2018 16:17:10 Setting a proxy...

Sun, 30 Sep 2018 16:17:10 Setting socket timeout to 1000 * 60 * 4

Sun, 30 Sep 2018 16:17:10 Success

Sun, 30 Sep 2018 16:17:10 Last status: Done

Sun, 30 Sep 2018 16:17:10 Reboot action set to 'never.'  Not rebooting.

Sun, 30 Sep 2018 16:17:10 Reboot and rescan.  Rescan set to false, so doing nothing.

Sun, 30 Sep 2018 16:17:10 ReleaseMutex 'Global\SDClientLockMutex' succeeded. Code: 0

Sun, 30 Sep 2018 16:17:10 No 'continue' tasks

Sun, 30 Sep 2018 16:17:10 ReleaseMutex 'Global\vulscan_scan' succeeded. Code: 0

Sun, 30 Sep 2018 16:17:10 Exiting with return code 0x8db3019c (412).

Sun, 30 Sep 2018 16:17:11 Process is terminating, cleaning scanner...

Hello,

I've started using Patch manager and completely understand the way it works technically.

My aim is now to make sure all our Ivanti clients are patched with MS critical updates. I just don't know where to start. Should i take all MS critical definitions and include them in a rollout project ? Should i only start with the current/last month ?

if you have advice or can explain how you manage it, i'd be glad.

For your info, some of my clients used WSUS where some others never had any patch. Clients are mainly W10 (different build) and few Windows 7.

I know the question could be difficult to answer (or too long) but i'd just be on the right tracks right now.

Thank you.

David.

My environment is all x64 Firefox installations on ~version 60.  Every since Ivanti changed the name of the patching scheme to "FF18-0X_INTL" the patches are no longer being detected as needed.  Even though the computer does need to be patched.

I'm considering fixing this myself by cloning and adjust the detection logic, but I'd rather not have to and just hope Ivanti fixed the detection logic.

I have the Groups i want to patch already set up and a scheduled task to scan those groups and download patches.

My first big question is should i be cleaning out my unassigned folder and adding them to my patching groups. I ask because i found the security roll ups in the un assigned folder so they were not being applied.

Next i would appreciate any good documentation videos and what not any of you use to get a good handle on the Patching and Compliance workflow in Ivanti. Thank you all for your help.

Semi new to the Patching process with ivanti and would just like to know the best practice for using the unassigned folder. Should i move them all to the scan global folder and see if it is detected? Thank you for your help.

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

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

Description

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

Assumptions

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

Process

Step one: Prepare both core servers to have accurate data

In order to make correct Patch data transfer from the"Light" Core to "Dark" Core, the Database tables related to Patch Manager must be reset.

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

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

               (The log for CoreDBUtil.exe is located in the main log location at \Program Files\LANDESK\ManagementSuite\Log)

Step two: Prepare the Dark Core folder structure

On the "Dark" Core (Without Network), you will need to have a location for the vulnerability XML files and a location for the actual patches themselves to be stored in.
We recommend using the already by default created "\Program files\LANDESK\ManagementSuite\LDLogon\patch" patch folder structure that is set up when you install Ivanti EPM.

(If patches have not been downloaded on the "Light" Core to "Dark" Core previously the patch folder may not have been created. On the "Dark" Core it should be manually created.)

If a different location is desired this article can be used to set up the alternative location.

Step three: Retrieve content on the "Light Core"

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

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

The first time this is run it will take quite a while as it will not only be downloading vulnerability definitions but also all patches. 

(Due to this you will need a large amount of storage space on the dark core server). 

This will download updates and store them to a to the patch directory.  The default patch directory is \Program Files\LANDESK\ManagementSuite\LDLOGON\patch.

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

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

          Copy *ENU_PatchSourcesXXX.xmlfrom \Program Files\LANDESK\ManagementSuite\LDMAIN

           to \Program Files\LANDESK\ManagementSuite\LDLOGON\PATCH on the source core. 
          This step is necessary because Vaminer.exe expects that file to be in that location.
          This needs to match the version you are running: 9.5 (ENU_PatchSources95.xml), 9.6 (ENU_PatchSource96.xml, 2016.3 (ENU_PatchSources101.xml) and so on. 

          Modification of the file is not necessary, it just needs to exist in that location. *(XXX equals the current LDMS version)

               (On LDMS 2017.3 SU3 the file needs to be renamed from ENU_PatchSources1013.xml to ENU_PatchSources10132.xml)

Step five: Prepare the *ENU_PatchSourcesXXX.xml on the Dark Core
*(XXX equals the current LDMS version)

               In the \Program Files\LANDESK\ManagementSuite\LDMAIN folder there will be several files called *ENU_PatchSourcesXXX.xml. *(XXX equals the current LDMS version)

               Choose the one that is the latest and matches your version on your core server. To check correct version of your Core server please refer to this article.

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

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

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

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

Modify the Enu_PatchSourcesXXX.xml as modeled below:

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

Before:

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

After:

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

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

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

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

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

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

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

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

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

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

 

     Before:
     <Source>

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

                   <Description>LANDESK Data Analytics Updates</Description>

                   <ShowInLDSM>true</ShowInLDSM>

                   <ShowInLSM>true</ShowInLSM>

            </Source>

 

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

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

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

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

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

Image may be NSFW.
Clik here to view.

     3. Export this certificate.

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

Image may be NSFW.
Clik here to view.

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

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

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

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

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

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

Hello,

I know there's a lot of topics about it and i've read them all but i just want to be sure. There's probably something i don't understand.

For Windows 10 we only have cumulative updates for the differents build.

So, for exemple, the  "Security Cumulative Update for Windows 10 Version 1709: September 11, 2018" should replace the "Security Cumulative Update for Windows 10 Version 1709: August 14, 2018".

Now if i use the "disable replaced rules" feature, the August Cumulative Update should not be display in my "Scan (global)" folder and should be in the "replaced" folder.

If i look in my "Scan (global)" this is what i've got (i use Ivanti in French):

Image may be NSFW.
Clik here to view.

If i look into my "replaced" folder or "partially replaced" folder there's nothing. It is empty.

Is it a normal behaviour or is there a problem in my console?

Thank,

David.

I have been reviewing the latest patch release:

New Ivanti Endpoint Manager Content Available - 10/09/2018

I can't see any of the new definitions replacing older patches, even though there clearly are patches that would be superseded.

For example, I would expect:

     MS18-10-W10-4462919_INTL Security Cumulative Update for Windows 10 Version 1803: October 9, 2018 (KB4462919)

to replace:

     MS18-09-W10-4457128_INTL Security Cumulative Update for Windows 10 Version 1803: September 11, 2018 (KB4457128)

I have also noticed that the some of patches are not even marked as critical/important:

     APSB18-35_INTL

     ARDC18-005_INTL

This is problematic as we rely on these ratings for automatic patch approval.

I am going to submit a ticket for this, but am curious if any one else seeing the same thing?

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)
Image may be NSFW. Clik here to view.	Image may be NSFW. Clik here to view.

Updating Definitions (MSO365)MSOFFICE 365 (Vul_Defs)	MSO365 (Vul_Defs)
Image may be NSFW. Clik here to view.	Image may be NSFW. Clik here to view.

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

Image may be NSFW.
Clik here to view.
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
Image may be NSFW. Clik here to view.	Image may be NSFW. Clik here to view.

Channels	Office 365 (2013) Product List View
Image may be NSFW. Clik here to view.	Image may be NSFW. Clik here to 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.

    Image may be NSFW.
Clik here to view. 

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
Image may be NSFW. Clik here to view.	Image may be NSFW. Clik here to view.

2016 Content	2013 Content
Image may be NSFW. Clik here to view.	Image may be NSFW. Clik here to view.

   
      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.

Image may be NSFW.
Clik here to view.Image may be NSFW.
Clik here to view.

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.

Image may be NSFW.
Clik here to view.

You will need to explicitly set the value to reflect the location your patches reside. For instance, if you are desiring to distribute from a location called "Patches" on your network storage server and are updating a 32 bit machine on the Office 365 2016 Deferred (now Semi-Annual) channel, you would put in the following path:

http://nameofmystorageserver/Patches/office365/2016/Deferred/X86

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

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

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

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

Image may be NSFW.
Clik here to view.

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 Image may be NSFW.
Clik here to view. icon on the Patch and Compliance menu bar.

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

Once the dialog is open click New on the bottom.

Image may be NSFW.
Clik here to view.

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.

Image may be NSFW.
Clik here to view.

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.

Image may be NSFW.
Clik here to view.

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.

Image may be NSFW.
Clik here to view.

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.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Hi All,

I am using an Ivanti (agentless) to scan VMs on a host (vCenter) via machine groups

2 of 7 VMs are having issues while being scanned as the IP which has no route from our Ivanti server is the one scanned.

Is it possible for Ivanti to force the scan on a specific NIC/IP?

I tried to include the 2 VMs in the group via adding the required IP, it worked.

However, im afraid it will not do a snapshot before the patch deployment so I need to add the machines via Hosted virtual machines.

Thanks in advance.

I know LANDesk cannot patch it natively, but is there a way to patch/update this software?

I have a handful of computers that need it.

Issue

Gather Historical Information crashes the LANDESK Console.

Gather Historical Information task is failing to run.

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

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

Solution

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

9.6 or 2016 Core Server:

HKLM\SOFTWARE\LANDesk\ManagementSuite\WinConsole

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

Maybe you are wondering like me, why some of your 1607 clients do not get any MS-Patches via Ivanti EPM.

Support pointed out to me:

It is Because Win 10 Pro 1607 is End Of Life by Microsoft and newer patches are no longer offered to it. They need to update to a newer version: 1703, 1709 or 1803 to be offered patches for Pro.

https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet