^Updated

We've implemented a new method for patching Office 365. Please review How To: Patch Office 365.

Introduction

As we all know, the latest release of Office from Microsoft comes in 2 flavors. A 'rich client' based installation, which is practically the same as running the Setup as in previous versions, and a Click-to-Run setup. The Click-to-Run version basically downloads stand-alone App-V packages of the applications you want to use from the Office Suite. Easy as this may be (and, depending on your licensing scheme, the only option you may have), this provides a challenge for Patch Management, as Ivanti EPM cannot patch within an App-V package.

This document will describe how to easily still use Ivanti EPM to patch Click-to-Run Office365 installations using all Ivanti EPM intelligence. From now on, the use of Office365 will assume the Click-to-Run version.

Configure your Office365 installation

More information about actually deploying Office365 can be found here. During configuration of Office365 setup, you can create an XML file that will change certain settings in your Office365 package to fit your environment. This XML can be created using the Office Deployment Tool for Click-to-Run. In this setup, there are 2 important setting for Patch Management. First off, you can set the Office365 installations to Auto-update. This will prevent that users need to manually check for updates. Second, there is a path where the installed Office365 packages will look when Auto-Update is configured. By default, this will point to a share. In a configured XML this will look like this:

In a small environment, you can just point the UpdatePath to the location where Ivanti EPM downloads patches. But, in a larger environment, you don't want all devices to connect to a central share, when you have options like Preferred Servers, Bandwidth Usage or the Cloud Services Appliance you want to use. For this reason, change the UpdatePath setting to: %ProgramFiles%\landesk\ldclient\sdmcache (or whatever the location of your sdmcache is)

Using Ivanti Endpoint Manager

Ideally you have 1 installed rich Office365 installation (Office Professional Plus 2013), although this is not completely necessary.

First, create a query which checks All Devices for Office365 installed.

You can download the Patch definitions in the normal way. If you have the Office Professional Plus 2013, running the vulscan will detect the definitions you need to deploy on the Click-to-Run devices. If not, you need to have a manual monthly process to select from the definitions last month from the Patch and Compliance screen, Vulnerabilities, View by Product --> Office2013 and/or Office2013x64, download the detected/selected patch content from the definitions and wait until all replications to Preferred Servers have completed.

Now we can select all Office365/2013 vulnerabilities from this month and create a Repair Task.

Most importantly, change the settings in Task Settings, so that the task uses Policy based delivery (so it will also work with devices through the CSA) and uses the Pre-Cache option under the Download options. Don't add any targets automatically to the task. Rename the task to cover the content, like 'Office365 Patches December'. Save and add the query you created as the target.

Start the task. When the devices check for Policies, they will start this task and download (with all Ivanti EPM intelligence) the selected patch content to the SDMCACHE on the client. From there, it will be picked up by the auto-update of the Office Setup.

Summary

Change the setup XML to use the UpdatePath setting: %ProgramFiles%\landesk\ldclient\sdmcache

Select all Office2013 vulnerabilities for the selected month

Download all their content

Wait for replication tasks until the content is on all Preferred Servers

Create a repair task with Policy/Pre-cache options configured

Target the query you created which queries Office365 installation

Start the task

The devices check for their policies and download the patches to SDMCACHE

The Auto-Update of Office picks the patches up from the local SDMCACHE folder

Thanks

Many thanks to remon.mulders for his brilliant thoughts on this subject.

Overview

Additional control over who can edit and import definitions has been added in LDMS 9.6 Service Pack 1.

Previously anyone with the "Edit" right for "Patch and Compliance" could edit all definitions and import definitions.

In 9.6 Service Pack 1 Ivanti EPM Administrators will be able to enforce greater control over who can edit and import definitions.

Require "Edit Public" right

To open this setting, go into Patch andCompliance.

Click the Configure Setting icon (cog wheel)

Click "Permissions..."

Only users with the LANDESK Administrator role will be able to control this setting.  If you wish to require the "Edit Public" right, check the box.

If you wish anyone with the less restrictive "Edit" right to make changes, uncheck the checkbox.

Issue

"Failed to apply compliance settings" during vulnerability scan.

Steps to reproduce issue

1. Right click on the device to run compliance scan, it gives error "unable to get compliance settings from core"
2. Error in vulscan log:

Loaded 0 custom variables from C:\ProgramData\vulScan\CustomVariables.CoreServerHostName.ini

Last status: Could not find compliance settings

Error: No compliance behavior specified, unable to perform compliance scan

Failed to apply compliance settings

Last status: Failed

 

Resolution

In agent settings, create a new compliance setting, and then run a change settings task to deploy the settings to client machine.

This document assumes that you are getting started with patching, or that you are redesigning your patch processes at a high level.  Before applying any patches you should familiarize yourself with the Ivanti EPM patching process and capabilities.  Here are several related documents to help you get started:

LANDESK Management Suite 9.6 patch & compliance documentation

Patch Manager- Strategic and Tactical Implementation Guide

Due to varying requirements and computing environments, your patching process needs to be tailored to your environment and needs.  This document serves to provide a general guideline for setting up baseline patching.  Your individual needs may vary. 

A baseline patch group will include minimal patch definitions that apply to computers and applications in your environment.  By design, it applies to newly imaged computers containing your baseline production applications and serves to bring them up to a minimal standard of compliance before being released to your production environment.  Patches in this group are tested against baseline computers in your environment and are known to be safe to apply without unintended consequences.  

Here are the steps to get started:

• Build baseline computers with your standard OS image and all production applications installed. You should have baseline computers for all your major OS versions. These can be virtual machines, or physical.
• Download all applicable patch content and move all definitions to the scan folder. Ensure autofix, do not scan, and unassigned folders are empty. Create a custom group for Baseline Patch Definitions.
• Run a security scan on your baseline computers. This will detect what patches are required for these computers and applications but will not install any patches.
• Once completed view the Security and Patch Information for your baseline computers. Select every definition in "All Detected" and drag it to your Baseline Patch Definitions custom group.
• Look through this group and remove definitions (if any) which you know will break things in your environment. You can search by the vendor or any other column that is useful. Move any bad definitions to Do Not Scan and delete them from your custom group.
• Determine whether to apply patches for vendor products such as Adobe, Firefox, Chrome etc.  Move definitions which you will not apply to Do Not Scan and delete them from your custom group.
  
• Look at all patches marked "Manual" and determine if they are needed in your environment. If so, manually download the patches from the vendor. If not, move to Do Not Scan and delete the definition from your custom group.
• Right-click the Baseline Patch Definitions group and select Repair. Create a repair task for this custom group, ensuring you have downloaded all patch files as needed, including manual patches that you want to apply.
• Run this task on your baseline computers using Agent Settings that allow the reboot.  This will take some time and possibly several reboots as several hundred patches will likely be installed.
• Investigate and remediate any failed patches, and ensure that no patches have caused unintended consequences for your baseline machines. Ensure none of your production applications have broken due to patches.  Move on only after you have validated that all patches are safe for your baseline computers.
• Move all definitions in your Scan folder back into the unassigned folder. Then, click on your Baseline Patch Definitions group, select all definitions and move them back to the scan folder. This assures you are only scanning against definitions that you have tested and which are needed to establish your baseline (so far).
• In the Download Updates window, check the box to "Put new definitions in 'unassigned' group" so that newly downloaded patches are not automatically set to scan.  You may change this later as you design and implement your continuing patch processes.

Your Baseline Patch Definition group is now complete and you are prepared to start baseline patching for newly imaged computers or to catch up unpatched computers in your environment.  You can run baseline patches during OS provisioning by adding a Patch System action to your template.  This video provides more information on this action:

How to use the Ivanti Endpoint Manager OS Provisioning "Patch System" action

You will want to design your production patching process according to your needs.  You will need to investigate the remaining definitions in the "unassigned" folder and determine whether to scan and repair them or move them to Do Not Scan.  As you design your continuing patch process, make effective use of additional custom groups and Definition group settings to reduce your management workload.

Before applying baseline patches to your production environment you should apply them to a larger patch pilot group for further testing, and to eliminate any potential patch issues that would affect your users or break applications.  It is vital to be aware of your environmental needs and make educated determinations regarding which patches you apply and the potential consequences of them all. 

The Distribution and Patch Settings are at the core of the patching process. These settings are stored on the core server and are updated automatically when vulscan runs. That means if you change the Distribution and Patch Settings that are configured for a device, the next time it runs vulscan it will update and use the new settings.

Each client machine has an "installed" Distribution and Patch Setting. That means that it is the default configuration that will be used on any tasks that don't have an assigned Distribution and Patch Setting. The currently "installed" settings can be found in the client machine inventory at: Computer - LANDESK Management - Vulnerability Scan - Settings - Distribution and Patch Settings Name. The "installed" settings can be changed using a "Change settings..." task found the the "Create a task" drop-down in the Security and Compliance tool.

Each of the settings and its effects can be found below.

• General settings
  • Policy sync schedule
  • Notification
    • User message
• Distribution-only settings
• Offline
• Logged off user options
• Download options
• Patch-only settings
  • Do not disturb
  • Scan options
    • Schedule
    • Frequent scan
    • Pilot configuration
    • Spyware scanning
  • Install/remove options
    • Continuation
    • Maintenance window
    • Pre-repair script
    • Post-repair script
  • MSI information
  • Branding

General settings

On the General settings page, enter a name that will be associated with the settings you specify on all of the pages in this dialog. This name will appear in the Agent settings list in the console.

Network settings

Use this page to customize how distribution packages will impact your network traffic. For more information, see About file downloading.

• Attempt peer download: Allow packages to download if they are already on a peer in the same subnet. This will reduce network traffic. For example, if you have several satellite offices, you could select one device at each office to receive the package over the network. Then, the other devices at each office would get the package directly from the first device instead of downloading it from the network.
• Attempt preferred server: Allow automatic redirection to the closest package shares. This will reduce the load on the core server.
• Allow source: Download from the core server if the files aren't found on a peer or preferred server. If the files are not in one of those locations and this option is not selected, the download will fail.
• Use multicast: Uses targeted multicast to send files to multiple devices simultaneously. Enter a value for the amount of time to wait on each subnet before the download begins.
• Bandwidth used from core or preferred server: Specify the percentage of bandwidth to use so you don't overload the network. You can limit bandwidth by adjusting the maximum percentage of network bandwidth to use for the distribution. The slider adjusts the priority of this specific task over other network traffic. The higher the percentage slider is set, the greater the amount of bandwidth being used by this task over any other traffic. WAN connections are usually slower, so it is most often recommended to set this slider at a lower percentage.
• Bandwidth used peer-to-peer: Specify the percentage of bandwidth to use locally. This value is typically higher than the bandwidth used from core or preferred server because of physical proximity.
• Send detailed task status: Click to send information about the task to the core server. This increases network traffic, so if you select this option to help troubleshoot a particular issue, you may want to clear it once you resolve the issue.

Policy sync schedule

Use the Policy sync schedule page to specify when the client will check the core to see if there are any packages available for download.

• Policy sync schedule
  • Event-driven
    • When user logs in: Click to run policy sync once a user has logged in.
    • When IP address changes: Click to run policy sync when the IP address changes.
      • Max random delay: Specify an amount of time to delay the scan in order to avoid downloading the package on all of the devices at the same time, which could flood the network.
  • Schedule-driven
    • Use recurring schedule: Click to only download distribution packages during a specified time frame. The default is to check once a day.
    • Change settings...: Click to open the Local scheduler command dialog, where you can create a different schedule.

Notification

Use the Notification page to specify what information to display to the user and what actions the user can take.

• Notification options before installing/removing
  • Automatically begin downloading: Begins the download of the distribution package without notifying the user.
  • Notify user before downloading: Notifies the user before a managed device initiates download of the package. This option is particularly useful for mobile users if used with deferral options to prevent a user from being forced to download a large application over a slow connection.
  • Automatically begin installing/removing: Begins the installation of the distribution package without notifying the user.
  • Notify user before installing/removing: Displays the installation or removal dialog before a managed device initiates installation or removal of the package.
  • Only notify user if processes must be stopped: Only displays a dialog if a process must be stopped before the managed device initiates the installation or removal of the package.
  • Kill processes that need to be stopped before starting the update: Click to shut down any processes that must be stopped before installing the package.
  • Prevent those same processes from running during the update: Click to ensure the processes are not allowed to restart until after the package has finished installing.
  • If deferring until lock/logoff: Specify how long to wait before the package will install.
• Progress options
  • Show progress: Select whether to never show the installation progress, to only show it when installing or removing files, or to show it when installing or removing and when scanning files.
    • Allow user to cancel scan: If you choose to always show the progress to the user, this option will be enabled. Click to give the user the ability to cancel the scan.
• No response timeout options: These options are enabled if you allow the user to defer or cancel.
  • Wait for user response before repair, install or uninstall: If you allow the user to defer or cancel, this option will be enabled. Click to force the agent to wait for a user response before continuing. This may cause the task to timeout.
  • After timeout, automatically: Click to automatically start, defer, or cancel the task after the amount of time you specify.

User message

Use this page to create a custom message that the user will see if you select Notify user before downloading or Notify user before installing/removing on the Notification page. When you schedule a task, there is an option to override this message.

Distribution-only settings

Use the Distribution-only settings page to select the download location, deferral and installation feedback options when dealing with SWD packages.

• Feedback
  • Display full package interface: Select this option to let the user handle the whole installation process manually.
  • Show successful or failed status to end user: Select this option to only let the user know whether an unattended installation that took place in the background failed or succeeded.
• Defer until next logon: Quite self explanatory. Select to have the installation started only once the currently connected user logs off and back on again (or just log on if there was nobody connected). (I'll clarify how this works exactly on servers, where there are multiple people connected at once)
• When the user chooses to defer package installation: You need to allow the user to defer the SWD task in the Notification settings section to enable this section.
  • Defer for a specific amount of time: This will require an extra step and may cause delays or network issues.
  • Limit number of user deferrals: This will reschedule the download. Select this option if bandwidth is an issue.
  • Maximum deferrals allowed: .
• Select the location to store Ivanti virtualized applications: Set the slider to specify whether to allow low or high CPU utilization during a scan.
• Enable LDAP group targeting: Specify which information the scanner sends to the core. For example, if you are experiencing an issue, you may wish to send debug information to try to troubleshoot the problem.

Offline

Use this page to specify mission-critical processes so that a scan will not occur if those processes are running. For example, to ensure that the scanner will not run during a presentation, you could apply the filter so that a reboot could occur.

• If a managed device cannot contact the core server when installing a package
  • Wait until the device can contact the managed core server: Select this option to let the user handle the whole installation process manually.
  • Install package(s) offline: Select this option to only let the user know whether an unattended installation that took place in the background failed or succeeded.

Logged off user options

Use this page to specify mission-critical processes so that a scan will not occur if those processes are running. For example, to ensure that the scanner will not run during a presentation, you could apply the filter so that a reboot could occur

• Logged off user behavior
  • Continue installation
  • Fail installation
  • Run at next logon

Download options

Use this page to specify mission-critical processes so that a scan will not occur if those processes are running. For example, to ensure that the scanner will not run during a presentation, you could apply the filter so that a reboot could occur

• Run from source (execute on share)
• Download and execute

Patch-only settings

Use the Patch-only settings page to select reboot and alternate core options when scanning, repairing, and downloading files.

• When no reboot is required
  • Require end-user input before closing: Select this option for the notification dialog to remain visible until the user responds to it.
  • Close after timeout: Select this option to close the notification dialog after a specified countdown.
• Alternate core
  • Communicate with alternate core server: Click to select a server to use if the default core server is unavailable.
• When installing via CSA: Click an option in the drop-down list to specify how the scanner will install via the portal Cloud Service Appliance (formerly known as Gateway). This is helpful if you have people who are outside the network, such as employees who are on the road, who need to communicate with the core.
  • Download patches from core as usual: This will require an extra step and may cause delays or network issues.
  • Do not download patches. Fail the request: This will reschedule the download. Select this option if bandwidth is an issue.
  • Download patches from manufacturer. Fall back to core on failure: This will attempt to download the patch directly from the manufacturer, such as Microsoft, before going through the core server. This will use less bandwidth on your own network.
  • Download patches from manufacturer. Do not fall back on failure: This will attempt to download the patch directly from the manufacturer, such as Microsoft. If it is unable to download the patch, it will reschedule the download.
• CPU utilization when scanning: Set the slider to specify whether to allow low or high CPU utilization during a scan.
• Scheduled task log: Specify which information the scanner sends to the core. For example, if you are experiencing an issue, you may wish to send debug information to try to troubleshoot the problem.

Do not disturb

Use this page to specify mission-critical processes so that a scan will not occur if those processes are running. For example, to ensure that the scanner will not run during a presentation, you could apply the filter so that a reboot could occur with PowerPoint open but not if PowerPoint was running full screen.

• Add defaults: Populates the list with the default processes.
• Add...: Opens the Specify process filter dialog box, where you can enter the name of the process and specify whether to apply the filter any time the process is running or only when the process is running full screen.
• Edit...: Opens the Specify process filter dialog box, where you can change the filter for a process that is already in the list.
• Delete...: Removes a process from the list.
• Legacy Mac agent user interruption settings If you have upgraded your Mac client, all of the settings on the Do not disturb page are supported. However, if you have not upgraded your Mac client, you can use the following options:
  • Hide scan progress dialog when a presentation is running: Click to keep the scan progress dialog in the background so that it does not interrupt a presentation.
  • Defer repairing when a presentation is running: Click to postpone any repairs until the presentation is over.

Scan options

Use this page to specify whether the security scanner will scan by group or by type of vulnerability.

• Scan for
  • Group: Select a custom, preconfigured group from the drop-down list.
    • Immediately repair all detected items: Indicates that any security risk identified by this particular group scan will be automatically remediated.
  • Type: Specifies which content types you want to scan for with this scan task. You can select only those content types for which you have a Ivanti EPM Security Suite content subscription. Also, the actual security definitions that are scanned for depends on the contents of the Scan group in the Patch and Compliance window. In other words, if you select vulnerabilities and security threats in this dialog box, only those vulnerabilities and security threats currently residing in their respective Scan groups will be scanned for.
• Enable autofix: Indicates that the security scanner will automatically deploy and install the necessary associated patch files for any vulnerabilities or custom definitions it detects on scanned devices. This option applies to security scan tasks only. In order for autofix to work, the definition must also have autofix enabled.

Schedule

Use this page to specify the time frame during which the security scanner will run as a scheduled task. After you select the settings, this page displays a summary of the schedule.

• Event-driven
  • When user logs in: Click to scan and repair definitions once a user has logged in.
    • Max random delay: Specify an amount of time to delay the scan in order to avoid simultaneously scanning all of the devices, which could flood the network.
• Schedule-driven
  • Use recurring schedule: Click to only scan and repair definitions during a specified time frame.
  • Change settings...: Opens the Local scheduler command dialog box where you can define the parameters for the security scan. This dialog box is shared by several Ivanti EPM Management tasks. Click the Help button for details.

Frequent scan

Use this page to enable the agent to check definitions in a specific group more frequently than usual. This is helpful when you have a virus outbreak or other time-sensitive patch that needs to be distributed as soon as possible. For example, you may want a client to scan every 30 minutes and at every login for a specific group that may contain critical vulnerabilities. The frequent scan is optional.

• Enable high frequency scan and repair definitions for the following group: Enables the frequent security scan features. Once you've checked this option, you need to select a custom group from the drop-down list.
  • Immediately install (repair) all applicable items: Click to enable the agent to install a patch if it locates one in the folder that you specify.
• Schedule
  • Event-driven
    • When user logs in: Click to scan and repair definitions once a user has logged in.
      • Max random delay: Specify an amount of time to delay the scan in order to avoid simultaneously scanning all of the devices, which could flood the network.
  • Schedule-driven
    • Use recurring schedule: Click to only scan and repair definitions during a specified time frame.
    • Change settings...: Opens the Local scheduler command dialog box where you can define the parameters for the security scan. This dialog box is shared by several Ivanti EPM management tasks. Click the Help button for details.
• Override settings: From the drop-down box, select the settings that you wish to override with the settings that you specify in the Distribution and Patch dialog.
  • Edit...: Click to open the Distribution and Patch settings dialog for that particular setting.
  • Configure: Click to open the Configure distribution and patch settings dialog. For more information, click Help.

Pilot configuration

Use the Pilot configuration page to test security definitions on a small group before performing a wider deployment on your entire network. For example, you may wish to install a new Microsoft patch on the devices in only the IT group to make sure that it doesn't cause any issues before it goes out to everyone in the organization. Using a pilot group is optional.

• Periodically scan and repair definitions in the following group: Enables the pilot security scan features. Once you've checked this option, you need to select a custom group from the drop-down list.
• Schedule
  • Event-driven
    • When user logs in: Click to scan and repair definitions once a user has logged in.
      • Max random delay: Specify an amount of time to delay the scan in order to avoid simultaneously scanning all of the devices, which could flood the network.
  • Schedule-driven
    • Use recurring schedule: Click to only scan and repair definitions during a specified time frame.
    • Change settings...: Opens the Local scheduler command dialog box where you can define the parameters for the security scan. This dialog box is shared by several Ivanti EPM management tasks. Click the Help button for details.

Spyware scanning

Use this page to replace or override spyware settings from a device's agent configuration.Real-time spyware detection monitors devices for new launched processes that attempt to modify the local registry. If spyware is detected, the security scanner on the device prompts the end user to remove the spyware.

• Override settings from client configuration: Replaces existing spyware settings on devices initially configured via an agent configuration. Use the options below to specify the new spyware settings you want to deploy to target devices.
• Settings
  • Enable real-time spyware blocking: Turns on real-time spyware monitoring and blocking on devices with this agent configuration.
    
    NOTE: In order for real-time spyware scanning and detection to work, you must manually enable the autofix feature for any downloaded spyware definitions you want to be included in a security scan. Downloaded spyware definitions don't have autofix turned on by default.
    
    
  • Notify user when spyware has been blocked: Displays a message that informs the end user a spyware program has been detected and remediated.
  • If an application is not recognized as spyware, require user's approval before it can be installed: Even if the detected process is not recognized as spyware according to the device's current list of spyware definitions, the end user will be prompted before the software is installed on their machine.

Install/remove options

Use the Install/remove options to specify what the agent should do once it determines the need for a patch.

• Reboot is already pending: Click this option if you want to start a patch installation regardless of whether the device has requested a reboot.

Continuation

Use the continuation page to enable the agent to immediately install or remove patches as soon as it meets the specified criteria. For example, if you need to install ten patches to remove a single vulnerability, continuation provides a way to install them one after another.

• Automatically continue install/remove actions after prerequisites are met: Click to allow the agent to automatically install or remove patches once it meets any prerequisites.
  • Additional automatic repair count: The default is to allow 5 automatic repairs, which balances the urgency of getting the patch installed with allowing users complete their work.

Maintenance window

Use this page to specify the parameters for when the agent can perform any install, repair, or remove actions.

• Machine must be in this state: Click to specify whether the user must be logged off or the device must be locked for the specified amount of time.
  • Delay: Use this option if you want to delay the action for several minutes to ensure that the user is not returning to the device.
• Machine must be in this time window: Click to configure the maintenance window by setting a detailed schedule. Specify the time of day, days of the week, and days of the month. The agent will only run when it meets all criteria.

Pre-repair script

Use the Pre-repair script page to execute a custom command before installing a patch. For example, if you want to get the environment ready for the patch by turning off a particular service, you can use a script.

• Abort patch install or uninstall if this script fails: Specify whether to cancel the patch installation if the script does not run.
• Insert sample script...: Click to select a VBScript, PowerShell script, or batch file to include in the pre-repair script.
• Insert method call...: Click to open a list of method calls that you can add to the pre-repair script. Click a method call in the list to move it to the Script Content box.
• Use editor...: Click to open Notepad, where you can write your custom script.

Post-repair script

Use the Post-repair script page to execute a custom command after installing a patch. For example, if you used a script to shut off the AV service before installing a patch, you can use the post-repair script to turn it back on.

• Run this script even if pre-repair fails: Specify whether to uninstall the patch if the post-repair script does not run.
• Insert sample script...: Click to select a VBScript, PowerShell script, or batch file to include in the post-repair script.
• Insert method call...: Click to open a list of method calls that you can add to the post-repair script. Click a method call in the list to move it to the Script Content box.
• Use editor...: Click to open Notepad, where you can write your custom script.

MSI information

Use this page if a patch file needs to access its originating product installation resource in order to install any necessary supplemental files. For example, you may need to provide this information when you're attempting to apply a patch for Microsoft Office or some other product suite.

• Original package location: Enter the UNC path to the product image.
• Credentials to use when referencing the original package location: Enter a valid user name and password to authenticate to the network share specified above.
• Ignore the /overwriteoem command-line option: Indicates the command to overwrite OEM-specific instructions will be ignored. In other words, the OEM instructions are executed.
• Run as Information: Credentials for running patches: Enter a valid user name and password to identify the logged in user for running patches.

Branding

The Branding page allows you to customize the status dialog that will notify the user of a scan or other scheduled task. For information on how to hide or display the dialog, see Notification.The Branding dialog box contains the following options:

• Customize window caption: Enter a title for the dialog.
• Preview...: Click to see the dialog box with the custom icon and banner that the user will see.

Distribution-only settings

Use the Distribution-only settings page to select download location, deferral and installation feedback options when dealing with SWD packages.

·        Feedback

·        Display full package interface: Select this option to let the user handle the whole installation process manually.

·        Show successful or failed status to end user: Select this option to only let the user know whether an unattended installation that took place in the background failed or succeeded.

·        Defer until next logon: Quite self explanatory. Select to have the installation started only once the currently connected user logs off and back on again (or just log on if there was nobody connected). (I'll clarify how this works exactly on servers, where there are multiple people connected at once)

·        When the user chooses to defer package installation: You need to allow user to defer the SWD task in the Notification settings section to enable this section.

·        Defer for a specific amount of time: This will require an extra step and may cause delays or network issues.

·        Limit number of user deferrals: This will reschedule the download. Select this option if bandwidth is an issue.

·        Maximum deferrals allowed: .

·        Select the location to store LANDESK virtualized applications: Set the slider to specify whether to allow low or high CPU utilization during a scan.

·        Scheduled task log: Specify which information the scanner sends to the core. For example, if you are experiencing an issue, you may wish to send debug information to try to troubleshoot the problem.

Purpose

This document outlines how to import and export Patch Content/Definitions. This can be useful to know when moving content between Ivanti EPM Cores.

Example:

• Export Custom Definitions on one Core, and import for use on a second Core.
• Import new Content from Ivanti EPM when testing for detection issues.

Export Content

• In the Ivanti EPM Core select Tools | Security and Compliance | Patch and Compliance
• In the Patch and Compliance window select the Content(s) to be exported
• Right click the Content(s) highlighted, and choose Export

• In the Select Export Filename window navigate to the directory you want to save the file to
• The Filename will automatically show the name of one of the selected Content items. You can change the name as needed. Keep the file extension as *.ldms.
• Choose Save

• The Export Status window will display the progress.
• When the Export Status window indicates Done, click Close.

The content is now available as a single *.ldms file that can be copied to other Ivanti EPM Cores and imported for use.

Note: If multiple Content items were exported together, they will all exist within a single *.ldms file.

Import Content

• In the Ivanti EPM Core select Tools | Security and Compliance | Patch and Compliance
• In the Patch and Compliance window right click the Scan folder and choose Import

Note: Content can be imported into any folder or group by right-clicking, but must be set to 'Scan' to be included in a patch scan.

• In the Select File to Import window, set the filter to match your content file's extension.
• Next, select the content file to be imported and click Open.

Note: Content Exported from an Ivanti EPM core will typically have the extension *.ldms. Content received while troubleshooting a content detection issue will typically have the extension *.xml.

• In the Import Options window select Update and click Import.

• When the Import Status window displays Done, click Close.

The imported content is now available for use within the Ivanti EPM Core.

Purpose

This article explains the behavior of optional and recommended Patch Repair tasks as they relate to the Ivanti EPM Portal

.

Symptoms

When creating a patch repair task as a policy, and setting the task to be optional or recommended in the Ivanti EPM Portal, the task may:

• Take multiple refreshes to show in the portal
• May not show in the portal at all

Cause

When a patch repair task is set as a policy, and is made optional or recommended in the Ivanti EPM Portal, the following occurs:

• The policy is made available to the client
• The client runs policy sync (clicks refresh in the portal)
• The policy is downloaded and triggers vulscan to scan for the patches in the repair task
  • A patch must be detected as 'missing' to be displayed in the portal.
• A secondary policy.xml file is created on the client containing a list of which patches were found as missing
• The client runs policy sync (clicks refresh in the portal)
• The second policy.xml file is parsed, and any patches listed within it are published to the portal

If 'show one portal entry with the following title:' is selected, a single entry will be created in the portal which when ran will repair all detected patches.

Note: If no patches were found as missing, no items will be shown in the portal.

If 'show each definition separately' is selected in the scheduled tasks properties, patches will be contained per definition within the portal.

Example: Definition MS15-020_MSU contains patch kb3039066 and kb3032323.

In our test scan, both of these patches were detected as missing, but since they belong to the same definition (MS15-020_MSU), only the definition is advertised in the portal.

Because vulscan checks patches listed for repair first, and only offers those needed through the portal for repair, policysync (refresh in the portal) is required to run a second time after vulscan finishes its scan.

Running policysync (refresh in the portal) prior to vulscan completing its scan will not populate any items in the portal.

If policysync (refresh in the portal) is not manually run, it will run on its scheduled interval as defined in the agent's settings.

Issue

The following error may be observed when downloading Patch and Compliance Manager definition content:

VulnerabilityTOC.SaveToDBThread.2 : Vulnerability.UpdateVulnerabilityLeanXML failed: The statement has been terminated.

Length of LOB data (635145) to be replicated exceeds configured maximum 500000.

 

Cause

The download updates tool is attempting to download a definition that exceeds the limit imposed by the "max text repl size" as configured in the database.

The max text repl size option specifies the maximum size (in bytes) oftext, ntext, varchar(max), nvarchar(max), varbinary(max), xml, and image data that can be added to a replicated column or captured column in a single INSERT, UPDATE, WRITETEXT, or UPDATETEXT statement. The default value is 65536 bytes. A value of -1 indicates that there is no size limit, other than the limit imposed by the data type.

To check your SQL server current maximum Text Repl size:

1. Right-click on your Ivanti EPM Database and select "New Query"
2. Enter the following text into the SQL Query Analyzer:
3. Hit "Ctrl-E" or click the "! Execute" icon in the toolbar.
   

EXECsp_configure 'show advanced options', 1 ;

RECONFIGURE ;

GO

EXECsp_configure 'max text repl size';

GO

This will show the currently configured options.

Resolution

Run the following statement in SQL Query Analyzer while pointing to the Ivanti EPM database:

sp_configure'max text repl size', 2147483647

Description

When installing the agent generated from the 9.6 core, we observe that remote control and agent status does not function from the Console. Upon further inspection i verified and found these items:

• cba8 service is running
• port 9595 is listening (both from a remote PC and locally on the pc, e.g. 127.0.0.1)
• port 9595 does not return valid data (for example using curl or a web browser, it returns empty data

Possible cause

CBA8 service is not working as expected

Steps:

1. Launch the Ivanti EPM console

2. Import the custom definition: CheckCBA8.ldms.zip is for LDMS 9.5;CheckCBA8_96sp2.ldms.zip is for LDMS 9.6

3. Set this custom definition as Autofix:

4. On the client machine, run a Security Scan.

5. On the client machine, input vulscan e in the run command dialog box, check vulscan.log if there is one patch which name is checkcba8

6. in the run command, input services.msc, refresh LANDesk Management Agent service, check if this service is started and startup type is set to Automatic.

Here is one article on how to create a custom definition:

How To: Create a Custom Vulnerability Definition in Patch and Compliance Manager

Issue

When comparing the performance of Ivanti EPM Patch and Compliance Management to standard Windows Update, it was noted that deployment of Windows patches with Ivanti EPM Patch and Compliance manager slowed down very much during the progress of the task while Windows Update patches kept installing at the same pace. The same patch installl can take up to 10 times as long after a while! This was purely in the deployment of the patches, not the scanning part of the task.

Nothing in the vulscan logs indicates any problem and all patches do get installed in the end.

On the servers where the patch deployment slowed down, the TrustedInstaller process takes up a very high amount of CPU load (this can be seen through the Windows Task manager). Also, the free disk space on the C: drive of the server decreased rapidly. This can be tracked down to the generation of a lot  (GB's) of files named starting by "_cab" in the directory C:\Windows\Temp and also GB's of cbs log files in the directory C:\Windows\Logs\CBS. These log files just log the creation of the cab files which most times ends in an error on the makecab.exe.

After a Patch deployment, these files can be deleted without any problem, the recommended way to do this is via the Disk Cleanup Tool.

Cause

First a bit of background... This applies to all Windows versions above Windows 7/Server 2008 up to now.

The Servicing Stack in Windows consists of three levels:

• At the top of the stack are the top level clients, such as Windows Update, Programs and Features, and WUSA/MSI, which deliver packages to a system.  The top-level clients are also responsible for control of user input and collection of user preferences during the servicing process.
• In the middle of the servicing stack is the Trusted Installer, CBS (Component Based Servicing). The top-level clients pass downloaded packages to CBS, which evaluates each individually to determine if they are applicable to the system.  For applicable updates, CBS provides the components to CSI, generates appropriate installation events, and registers packages with Programs and Features if needed.  Finally, CBS exposes the interfaces to enumerate and inventory the updates.
• At the bottom of the servicing stack is CSI (Component Servicing Infrastructure), which uses the Kernel Transaction Manager (KTM) to do its work.

CSI is responsible for the actual installation of components.  To install components, CSI utilizes the Component Store (the %windir%\WinSXS folder) which is a collection of all components, manifests (%windir%\WinSXS\Manifests) and files on the system.  As new components are added, CSI moves them into the Component Store and determines what state the component should enter.  Staging determines the current state of the package in the file system.  There are different staging activities that occur during the installation of a package:

• Identify any files that are missing from the package.  For a file to be installed, it must first be staged.  Some may already present in the system store, others may need to be transferred from installation media or downloaded from network locations
• Determine which files are required to install a package and identify files in other packages that may also be required
• Resolve dependencies and ensure that all required files are present before installation begins.
• If a file or process is in use during a component installation and cannot be replaced, generic commands and advanced installer actions are written to %windir%\WinSXS\Pending.xml, and then written to disk on the following reboot.  If several packages are installed at the same time, each additional package appends to Pending.xml.  Additional logging during this phase occurs in %windir%\Logs\CBS\CBS.log.
• Complete installation

So, to summarize, TrustedInstaller is used by a service called “Windows Module Installer” which is used to install and update Windows system modules. The system modules include content from Windows Update and Automatic Updates which both automatically scan your system to check for any new updates and hotfixes available. So when scheduled Windows Update is performing its update scan or check on your system, the TrustedInstaller.exe process increases the CPU usage. TrustedInstaller is also 1 of 2 processes that log to the CBS logs (Component Based Servicing). The other being SFC (the System File Scan) which is not relevant here.

Although Ivanti EPM uses the Windows WUSA (The Windows Update Stand Alone Installer) to deploy patches, the Trusted Installer seems to be unaware of the source of the patch content. On a not configured Windows OS this results in the Trusted Installer also using Windows Automatic Updates and previous download content from it as source for scanning and repairing the patches on the server, each time adding to the queue when a patch through the Ivanti EPM Vulscan was installed; as evidenced by the makecab.exe tasks running (and failing as the process was already running) and the cab/log files created.

Resolution(s)

The resolutions are fortunately quite simple.

If you don't want to use the Automatic Windows Update Services (some people might want to use this, because they also use WSUS as central reporting/auditing tool) then make sure the TrustedInstaller doesn't have Windows Automatic Updates as the source.

This can be achieved by configuring 2 Group Policy settings:

• Setting "Configure Automatic Updates "  DISABLED
• Setting "Do NOT connect to any Windows Update INTERNET location" ENABLED

DO NO set the Windows Module Installer Service and the Windows Update Service to DISABLED. Both services are used during the update process, also with Ivanti EPM Patch and Compliance Management.

If you do want/need to run Windows Update beside the Ivanti EPM Patch and Compliance Management:

• Stop the “Windows Update” service
• Rename the C:\Windows\SoftwareDistributionfolder to C:\Windows\SoftwareDistribution.old
• Start the “Windows Update” service.
  • This will create a new C:\Windows\SoftwareDistribution folder
• Check the C:\Windows\SoftwareDistribution.old folder.
  • This folder contains all previously downloaded Windows updates
  • TrustedInstaller is unaware that Ivanti EPM has patched and still thinks it needs to install old downloaded updated. This process deleted those old updates.
  • Once recreated, Window update will check itself and WSUS for only the latest patches
  • You can delete the SoftwareDistribution.old folder.
    

This article has been created referencing many different articles both on and off the internet. As such, I thank the many of the authors of those articles, some of who I have blatantly copied here Thank you all and if you feel your individual effort should be mentioned here, please drop me a note. Many thanks though to Henk Adams for putting me on the right track for this article.

For security reasons, some customers may need to exclude some managed devices from the patch management feature in Ivanti EPM.

For instance, this could be required for some critical computers where the patches need to be applied manually.

Here is a tutorial on how to achieve this result:

Step 1

In the Ivanti EPM console, Select "Agent settings" and then "Distribution and Patch"

Step 2

Create a new "Distribution and Patch Settings" set.

Step 3

In the "Scan options" tab, make sure that the "enable autofix" option is not checked.

Additionally, if you have some patch groups configured, make sure that "Immediately install (repair) all applicable items" is not checked.

Otherwise, this option will override the "never autofix" agent setting if checked.

Save the settings.

Step 4

Create a new agent configuration

Select the "Standard Ivanti agent" tab and make sure that the "never autofix option" is enabled.

In the "Distribution and Patch" tab, select the settings that you created in stage 3.

Save the settings.

Step 5

The last step will be to deploy the new agent configuration to all the managed devices that are supposed to be excluded from the patch management.

This article demonstrates how to troubleshoot High CPU usage from the W3WP process that is tied to the LDAppVulnerability application pool.

This article assumes that the user is running Server 2012 R2 which includes IIS 8.5.

General IIS troubleshooting information from Microsoft: Troubleshoot : The Official Microsoft IIS Site

Basic process for troubleshooting the CPU usage issue is the following:

1. Review the running W3WP processes.    (See What is the W3WP process?)
2. Review the IIS logs and look for what is causing the volume of traffic and for errors. (See Troubleshooting IIS logs)
3. Check the WSVulnerability.core.dll log for methods being called and their related information.  Information about the traffic going through the WSVulnerabilityCore web application.
4. Check the database performance.

Processes using the WSVulnerabilityCore web application

WSVulnerabilityCore is responsible for much of the information traveling from the managed client to the core server especially during the Patch and Compliance scan process, and then written to or retrieved from the database.   Among these are:

• Getting hash information for files
• Retrieving patch install and uninstall information
• Receiving DeviceID to retrieve computer information from the database
• Retrieving results of vulscan scan and repair
• Retrieving Antivirus information such as licensing, pattern file dates, quarantine, and infection information, etc.
• Supplying File Reputation information.

What is the W3WP process?

W3WP.EXE processes are windows worker process that run Web Applications for IIS.  Each of these processes is responsible for handling requests sent to a Web Server for a specific application pool.

Several different W3WP processes can be found in Task Manager.  By default, there will be at least two.  One servicing the LDAppMain application pool, and one servicing the LDAppVulnerability application pool.  The LDAPPVulnerability application pool services the WSVulnerabilityCore web application.

This can be seen by looking at the Advanced Settings for the WSVulnerabilityCore application in IIS.

(Click for full size)

In order to identify what the WP3WP process is assigned to, you will need to add the "Command Line" column to the Task Manager columns.

As an alternative, you can open an Administrative Command Prompt, switch into the %windir%\System32\inetsrv folder (cd %windir%\System32\inetsrv) and run appcmd list wp. This will show the process identifier (PID) of the w3wp.exe process in quotes. You can match that PID with the PID available in Task Manager.

If more than one W3WP process exists tied to LDAppVulnerability, it means that more than one worker process has been assigned to the LDAppVulnerability pool in IIS.

Many performance issues can be related to an incorrectly configured application pool in IIS.  The default settings as installed by Ivanti EPM are the recommended settings.  Outdated information exists that recommends adding worker processes, adjusting timeouts, etc.  This is not recommended.

The following screenshot demonstrates the default settings, click for full size:

(If the server is a NUMA capable server, additional options will exist. These should be left at default as well)

Troubleshooting IIS

Two types of IIS logs exist:

• W3SVC1: These logs show all IIS traffic.  These are by default  stored in C:\inetpub\logs\LogFiles\W3SVC1.  Particular attention should be paid to looking at the requests that are coming in:
  • Are they repetitive in excess?
  • Do they contain error status codes?  (403, 500, etc)

Troubleshooting HTTP 400 Errors in IIS : The Official Microsoft IIS Site

• HTTPERROR: The following list identifies the kinds of errors that the HTTP API logs:   (Further information: https://support.microsoft.com/en-us/kb/820729
  • Responses to clients The HTTP API sends an error response to a client, for example, a 400 error that is caused by a parse error in the last received request. After the HTTP API sends the error response, it closes the connection.
  • Connection time-outs The HTTP API times out a connection. If a request is pending when the connection times out, the request is used to provide more information about the connection in the error log.
  • Orphaned requests A user-mode process stops unexpectedly while there are still queued requests that are routed to that process. The HTTP API logs the orphaned requests in the error log.

Troubleshooting Failed Requests Using Tracing in IIS 8.5 : The Official Microsoft IIS Site

IIS log files store the date and time using GMT (Greenwich Mean Time).  You will need to convert that to the local time of the Core Server in order to correctly interpret when the log file entries occurred. 

How to troubleshoot IIS using Log Parser Studio from Microsoft

Using the Debug Diagnostics Tool to troubleshoot High CPU Usage by a process in IIS

Microsoft has the following article that details using their tool to troubleshoot high CPU usage.

Troubleshooting: Debug Diagnostics Tool to troubleshoot high CPU usage by a process in IIS

Microsoft Article for troubleshooting high CPU in an Application Pool

Additional article for troubleshooting High CPU in an IIS application pool:

Troubleshooting High CPU in an IIS 7.x Application Pool : The Official Microsoft IIS Site

Troubleshooting SQL Server Performance Issues

Database maintenance plans should be set up, regular indexing of the database should help keep performance up to par.

Evaluate SQL Performance by reviewing this Community Article: How to create a perfmon trace to analyze Ivanti EPM database performance

According to database performance, the following registry key can be modified to increase or decrease the number of threads that are available from the Web Service to the database:

Increasing the Number of Web Process to Database Threads

You can increase the number of threads the web service uses to talk to the database. This is by default set to "10". Be careful when setting this number, as you can overwhelm the database with web service requests. This number can be set to 40 or 50, however after doing so, monitor to make sure we are not overrunning the database.

The number of threads can be changed by adding the following registry key:

HKLM\Software\LANDesk\ManagementSuite\PatchManagement

       

Add a string value of "WebServiceMaxThreads) set to "40" or so. (This number may need to be adjusted)

(Caution: Be careful when modifying this registry key, and document changes to it)

The current value can be seen by looking in the \LANDESK\ManagementSuite\log\WSVulnerabilityCore.dll log.

The following line shows this information:

"----------WSVulnerabilityCore initializing with semaphore count: {0}----------“. 

Verify schedules for Inventory Scans, Patch and Compliance Scans, Software Distribution Jobs, etc.

If a lot of scheduled activities are scheduled to run at the same time, this can overwhelm the core server or the database resources.

Periods of excessive traffic can be pinpointed by gathering IIS logs and running the "Requests per hour" query in Log Parser Studio.

This very much can reflect scheduled activities.

How to troubleshoot IIS using Log Parser Studio from Microsoft

• Issue
• Cause
• Resolution
  • Step 1
  • Step 2
  • Step 3
  • Step 4

Issue

Despite a valid LANDESK antivirus subscription, Security and Compliance Manager is not able any more to download the newest antivirus definition.

Instead the LDMS Security and Compliance Manager displays the following error:

Verifying access to site US West Coast (https://patch.landesk.com)

Verification complete

Processing LANDESK Antivirus Updates

Checking for updates...

Invalid XML file 951_updates.xml. There is an error in XML document (2, 2).

No updates found.

Completed updating definitions

Rebooting the core server or switching to another update source site doesn't help.  Additionally the vaminer.log shows the following entries:

Cause

This issue appears because one or more antivirus configuration files got corrupted on the core server.

Resolution

Step 1

Close the LANDESK Console

Step 2

On the core server, open Windows explorer and locate the following files:

C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Mac\basesEP\LdBasesInfo.xml

C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Mac\pre.basesEP\LdBasesInfo.xml

C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Win\bases8\LdBasesInfo.xml

C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Win\basesEP\LdBasesInfo.xml

C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Win\pre.basesEP\LdBasesInfo.xml

Step 3

Rename each file - for instance, you can add the ".old" extension to each filename.

Step 4

Launch the console - this will recreate the configuration files renamed in step 2.

Try again to download the newest LANDESK antivirus definition.

This should fix the issue.

Issue

You have some Windows 2012 servers managed by Ivanti EPM.

After running the Patch and Compliance Manager, you notice that very few patches are detected for these client machines.

However, if you run Windows Update manually on one of these servers, a lot of missing patches are detected.

Cause

This issue can have several roots.

Here are the steps to troubleshoot this specific issue.

Resolution

Patch Manager doesn't automatically install all the patches that show up in Windows Update.  This topic is covered in more details in this article :

Issue: Microsoft Hotfixes aren't included by default in Ivanti EPM Security and Patch Manager

To find out which patches are included by default in the Patch and Compliance, please see the Ivanti EPM Security Bulletin:

Security and Patch Bulletins

1. Make sure that your core server has a valid Patch Management subscription.
   
   
2. Check also that the Patch Management subscription matches the current version of your core server (for instance 9.5 or 9.6) and is not shown as "expired".
   
   
3. Make sure that the "Windows vulnerabilities" option is checked in the Patch Manager configuration window and that no error is displayed while downloading the latest definitions
   
   
4. Ensure that "Update 1" is installed on the Windows 2012 server-managed clients.

Otherwise, the most recent patches for Windows 2012 servers will not be detected by the Ivanti EPM Patch Manager.

Note: Windows 7 requires SP1 in order to install IE11.

Description

With Microsoft's recent End Of Support for versions of IE older than 11, its important to get up to date in order to receive technical support and security updates for workstations.

This document covers the procedures and expectations for installing Internet Explorer 11 using Ivanti EPM Patch and Compliance Manager.

Identifying Workstations that need to upgrade to Internet Explorer 11

We will be using a Query to identify what workstations currently have a version of Internet Explorer less than 11 installed.

To get the most accurate results, we'll want to identify all versions of Internet Explorer 11 that are currently installed on workstations, and exclude any device running those versions. This query will vary between networks, but the following screenshot should give a rough idea:

Be sure to Include Computer > Browser > Version in the result columns so the different versions can be seen in the results.

Now that we have our list of devices that need to upgrade, we know what devices we can apply to the upgrade process.

Creating a Custom Group to include Internet Explorer 11 Patch and Prerequisites

For the sake of Simplicity, we'll want to gather all necessary patches for the Internet Explorer 11 upgrade to one area. To do this, create a custom group and name it something related to Internet Explorer 11.

Search the "Scan" folder for patch ID IE11, and drag it to the new Custom Group just created. A prompt will open asking if the 9 prerequisites should be included.

These prerequisites are needed in order for Internet Explorer 11 to be detected and installed on the machine. Click Yes.

Another prompt may be generated warning that not all patches are downloaded. Be sure to download all associated patches for these 10 IDs as the job will fail otherwise.

Now that we have all necessary patches grouped together, its time to apply them to machines using either Manual Installation or Autofix.

Using Autofix to apply Internet Explorer 11

Assuming that Autofix is not enabled globally, you will need to useutilize scopes for the Internet Explorer 11 autofix upgrade. To create the appropriate scope, simply browse the Network View. right-click Scopes and select New Scope from Query.

Select the Query created above and click OK. This will create a new Scope with the same name as the Query created earlier.

Highlight all 10 of the patches in the Custom Group created above, right click and select Autofix> Autofix Settings.

Select the checkbox next to the Scope created earlier and click OK. 

The devices that qualify for the scope created will now upgrade to Internet Explorer 11 as they scan for definitions.

Apply Internet Explorer 11 manually using Scheduled Repair jobs

The manual installation of Internet Explorer 11 will be using theQuery and Custom Group created earlier in this document.

To begin, highlight all patches in theCustom Groupand selectRepair. This will create a scheduled task window.

There are a number of ways to assign devices to this scheduled task. The first being to associate the Query created earlier to the scheduled task.

This is done by selecting Target Devices > Targeted Queries > *Query Name.* This will add all devices associated with the Query to apply to this scheduled task. Furthermore, the devices will fall out of the query as the patch is applied via policy.

A different method would be to stagger the devices within the Query and add them in increments to the scheduled task.

Click Save. A new task will be added to the Scheduled Task Window.

If the task was associated with a Query, Right-Click the task and select Start Now> All. Otherwise, devices will need to be added to the task before starting.

What to Expect

1. When using Autofix to upgrade Internet Explorer 11, the device will automatically fall out of the Query created as they upgrade. By association, they will fall out of the scope. There's no need to worry about devices running the upgrade more than once.

2. This upgrade will often require 1 or more Reboots. Plan accordingly with Reboot behavior. In this lab, a Windows 7 x64 install with Internet Explorer 8 was used. A total of 3 Reboots was required to fully upgrade.

3. The install script for Internet Explorer 11 includes a /norestart command. This means the final reboot needed will not immediately prompt the user.

4. Internet Explorer does NOT need to be closed before the patch is applied. It can be done silently in the background, and the install will complete on the next reboot.

Issue

The problem typically occurs when the core is trying to patch a newly imaged machine. The error message is "String not found: PatchAction.39"

The reason for this error is because the Core & Client machine are on different versions of Ivanti EPM.

Resolution

The solution for this error is to patch both the core and client to the same version.

Ivanti recommends that you update to the latest publicly available component patch.

This is available in the Ivantiupdates category within the Security and Patch Manager tool in the Ivanti EPM console.

Purpose

This article will provide a step by step in creating recurring Patch and Compliance Content Download Tasks.

Step by Step:

1. Navigate to Tools>Security and Compliance>Patch and Compliance on your Ivanti EPM Console.

2. Open the Download Updates window from within Patch and Compliance.

3. Select the applicable Content for recurring downloads (this is configurable and dependent upon the needs of your environment; selections chosen are for examples).

4. Select "Schedule Downloads

5. Name your Task and select OK.

6. Utilize the Start Later: Date; Time and Repeat functions to automate your downloads.

7. Select 'Save' and your task will populate within your Scheduled Tasks window.

Problem:

When performing “Download Updates” in the console, error message “Waiting for file lock” appears.

Cause:

This can happen when more than one instance of downloading updates is running simultaneously. For example, if you try to manually download patches while a scheduled patch download task is already running.

Solution:

• Kill all running VAMiner.exe processes.
• Log off the console and log in again.
• Reboot core server.

If none of the above works, try executing the following query against your Ivanti EPM database to remove the lock.

SELECT * FROM PatchSettings WHERE Name LIKE '%LOCK.UpdVulnLock%'

DELETE FROM PatchSettings WHERE Name LIKE '%LOCK.UpdVulnLock%'

This document illustrates the files, registry, settings and other information necessary to effectively troubleshoot a vulnerability scan.

In addition, this document walks through the steps that a basic Patch and Compliance scan (otherwise known as a vulnerability scan) takes.

This article will not describe every single step that the Vulnerability Scanner takes, but those steps where a failure can occur.

For the purposes of this document a simple scan is performed by running the following at the client command line:

vulscan /scan=0 /showui

This command tells the vulnerability scanner to scan Windows vulnerabilities (type 0) and to show a user interface.

The name "LDMS2016" and "LDMS2016_v###" will be seen throughout this document.   This refers to the Core Server name of "LDMS2016" which is the name of the core server that the author had when creating the document.

Settings

The settings that control how the vulnerability scanner will behave are stored in the Distribution and Patch Settings within the Agent Settings tool.

These settings control behaviors such as user input options, Cloud Services Appliances patch options, scanner CPU utilization, etc.

These settings are stored in the Ivanti EPM Database in the AgentSettings table and physically on the core server in the

\Program Files\LANDESK\ManagementSuite\ldlogon\AgentBehaviors folder.  The Distribution and Patch Settings are stored in the AgentBehavior_(Corename)_v###.xml file within this folder.

                                                                            Example

Product Licensing

The categories available to scan and repair are controlled by the Product license that has been purchased and activated on the core server.

The following graphic shows the categories available within the Download Updates function within the Patch and Compliance tool for those with a license for all categories.

Click for full size

Registry Keys

Core

HLKM\Software\LANDESK\ManagementSuite\PatchManagement\WebServiceMaxThreads

This key does not exist by default and should only be created with an understanding of how this key works and the full ramifications of creating this key and changing the default value.  This changes the number of default threads

This key is documented here: https://community.landesk.com/docs/DOC-36027#jive_content_id_Increasing_the_Number_of_Web_Process_to_Database_Threads

Client

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\WinClient\Vulscan

This registry key contains the following information:

Note: The populated "Data' entries are provided as an example.  Yours will differ.

Gathering information for Ivanti Support

The vulnerability scan log files are located in the C:\ProgramData\LANDESK\log folder.

When in doubt just .ZIP up the entire folder and send it.

Otherwise, the following logs should be gathered:

• vulscan*.log
• statusdlg*.log

It is very useful to turn on Xtrace with the following enabled from the registry key prior to duplicating the problem and gathering logs:

From HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\LogOptions:

How To: Enable XTrace Diagnostic Logging for the Ivanti Core and Clients

Tips and Tricks

Vulscan can be used as a shortcut to open various folders.  The following should be run on the client command line:

Vulscan e - Open the folder where Vulscan resides

Vulscan c - Open the LDClient folder,

Vulscan log - Open the ProgramData\LANDESK\Log folder

Issue: Cannot open vulscan logs folder from the command line using "vulscan e"

Ivanti Patch and Compliance (vulnerability) Scan Process Flow

It is important to note that the following must all be able to take place:  Client contact to core through IIS and several web services.  Core contact to Database Server  Core Contact to client  Correct permissions on core ManagementSuite\Incoming directory and \ManagementSuite\LDLOGON\VulnerabilityData and VulscanResults folders.

Note that issues can come and go during a vulscan.  This would indicate intermittent issues.  Most of the time this occurs when the server or database has connectivity issues or are too overwhelmed to respond to requests.

• About Java Patches
• Java patches within Ivanti Patch and Compliance Manager content
• Download, rename and place patch in the patch location
• Custom Variables Tab within the Java definitions
  • Force Mode
  • Disable Java Update
  • JRE Installation
  • Remove Old Version
  • Expiry Date of JRE

About Java Patches

Java patches are available for the Java Runtime Environment (JRE) or Java Software Development Kit (JDK).

JDK is a super-set of JRE, and contains everything that is in JRE, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language.

Java patches within Ivanti Patch and Compliance Manager content

• JREJDKv#U###_Manual   (JRE and JDK installation that requires a manual download)
• JREv#U###_Upgrade   (JRE upgrade that can be downloaded automatically)
• JREv#U###   (JRE installation that can be downloaded automatically)
• JDKvU###_Manual   (JDK installation that requires a manual download)
• JDKv#U###_Manual_Upgrade   (JDK Upgrade that requires a manual download)

Some examples:

JREJDKv7U111_Manual - Manual update for updating both JRE AND JDK Version 7 to the 111 update.

As you can see the name specifies if it is a JRE or JDK update or both.   It then says what version the patch is for, and then the patch number.

Some simply upgrade the existing installation to the newer version.  These are denoted by the word "Upgrade" in the title.

Others perform an upgrade by uninstalling the old version and installing the new version.

                                                               Example List

Download, rename and place patch in the patch location

The following website typically is the location to download Java SE JDK and JRE patches:

Java SE - Downloads | Oracle Technology Network | Oracle

The patches that end in _Manual require the following

1. The user to accept a license agreement and/or require a user to log in.
2. Download the patch.
3. Rename it as required (this is listed in the description of the patch, which you can get to by right-clicking the vulnerability, selecting properties, and going to the second tab).
   
   Example Description
   

   Java™ SE Runtime Environment 8 Update 102 (JRE 8u102)
   Java SE 8u102 includes important security fixes. Oracle strongly recommends that all Java SE 8 users upgrade to this release.
   Please download the install packages manually from http://www.oracle.com/technetwork/java/javase/downloads/index.html
   Oracle re-releases Java SE 8u102, so please rename patch file as below list, then put them in the "patch" folder.
   jre-8u102-windows-i586.exe
   jre-8u102-windows-x64.exe

4. Place it into the patch directory that will be used to deploy the patch.
5. Run "Download Updates" again to update the Downloaded status of the patch within Patch Manager.

Custom Variables Tab within the Java definitions

Within the Java definitions there is a Custom Variables tab.  A custom variable is a configurable setting used to extend the usability of the definition.

There are typically up to 5 options that can be adjusted

Force Mode

The "No" option is the default value. If the Java application or browsers are running the repair task will fail and an error will be reported and you will be prompted to close the Java application and/or browsers.

If you chose "Yes", you will proceed to install the Java update with following actions, the installation process will terminate your Java application and/or close any open browsers.

Disable Java Update

The "Yes" option is the default value. When the default value of "Yes" is selected, the Java auto-update feature is disabled. If "No" is selected, the Java auto-update feature will be enabled.

If you intend to manage Java Updates solely through Patch Manager this option should be set to "No".  The Java auto-update feature is Java periodically checking to see if there are new updates and auto-applying them itself.

JRE Installation

The patch-in-place mode implies that when a version of the JRE exists on a machine, any updates belonging to the same JRE family will be done in place, meaning, the existing JRE will be patched with changes. A JRE is installed in patch-in-place mode by default. When a JRE is installed in static mode, it will not be updated in place by later versions. A later version from the same JRE family will be installed in a separate directory. This mode ensures that vendors, who require a specific version of the JRE for their product, can be certain that the JRE will not be overwritten by a later version.

For more information: Patch-in-Place and Static JRE Installation

Remove Old Version

The "No" option is the default value. When the default value of "No" is selected, Old version Java will be skipped. If "Yes" is selected, the old version Java will be removed.  This is in case you need to have multiple versions of Java installed to maintain backward compatibility.

Expiry Date of JRE

The expiration date is calculated to end after the scheduled release of the next Critical Patch Update. After this date, Java will provide additional warnings and reminders to update to the newer version.

The "No" option is the default value. When the default value of "No" is selected, the Expiry Date for JRE feature is disabled. If "Yes" is selected, the Expiry Date for JRE feature will be enabled.