Hi

I am very new to the forums and Landesk in general

I have a problem upgrading windows 10 from 1511 to 1709 using patch and compliance.

Here is what I've done so far

I followed the below guide, downloaded the ISO from our Microsoft portal, we have both Enterprise and Pro in our environment so I created a file for both of them and  Landesk accepts them both as downloaded

How to upgrade to Windows 10 Creators Edition using Ivanti Patch Manager

Then I distributed the ISO's to our preferred server and created a repair job

this job I sent to a specific machine and within 2 minutes it showed Success

now for my stress factor..

Noting happened on the machine itself, I cannot see the package on the machine and it does not patch.

I have created several software packages and set up PXE booting for the environment but this one I cannot solve

I sent a package to the machine to check if I could install to it, and that works as it should

I hope you guys can point me in the right direction

Looks like is a service pack but when i open that it says it is a manual download

Hi

I am having problems with the Patch-in-place setting on the Java 8 definition updates in Patch Manager. The setting is not working and appears to be installing the Java 8 updates in Static mode

I am therefore seeing multiple instances of Java on each device:

Has anyone else experienced this problem with Java 8? We did not experience this issue with Java 7 updates in Patch Manager and have not done anything differently in 8.

We are using LANDesk 9.5 (not service packed)

Thanks

Joe

I've got patches piling up.

the repairs are failing due to "Status marked as detected because pre-req check failed."

not sure how to go about troubleshooting this. its started with the new patching process this year.

I do have the MS registry key set on the computer I am using to try and get patched first.

example:

I am seeing some strange issues with the March 6th MS Office 2016 patches. We have multiple computers showing that the patches are getting installed 3-4 times. When looking at the installed updates on Windows 10 it shows that the MS Office patches are installed 3 or more times on the same computer. If I go into Security and Patch Information it shows that the patches were only installed once. I haven't seen this issue before and was wondering if anybody else is having the same issue? If not is there something that I should be looking for when these patches are installing? We are currently on EPM 2017.3 SU1.

Here is a pic of 3 different updates being installed 3 times on the same computer on the same day.

Here is a pic of the same computers Security and Patch info for those patches

Login to a client device. Press the Windows + R keys to open the Run dialog, type eventvwr.msc, and press Enter.

If prompted by UAC, then click on Yes (Windows 7/8/10) or Continue (Vista).

In the left pane of Event Viewer, double click on Windows Logs to expand it, click on System to select it, then right click on System, and click on Filter Current Log.

Standard Shutdown Events

Click on the drop down arrow to the right of Event Sources, check the USER32 box.

In the Includes/Excludes feild, type: 1074, then click on OK.

This will give you a list of power off (shutdown) and restart Shutdown Type of events at the top of the middle pane in Event Viewer.

You can scroll through these listed events to find the events with power off as the Shutdown Type. You will notice the date and time, and what process was responsible for shutting down the computer per power off event listed.

You can see in this example highlighted that vulscan called the reboot.  If Endpoint Manager calls a reboot this is typically what you will see.  Any other process that calls a reboot is not being controlled by Ivanti.

To See the Dates and Times of All Unexpected Shut Downs of the Computer

These are typically crashes, while the information might not be complete, it can be useful to troubleshooting unexpected shutdowns.

Click on the drop down arrow to the right of Event Sources, check the USER32 box. 

In the Includes/Excludes field, type: 6008, then click on OK.

This will give you a list of unexpected shutdown events at the top of the middle pane in Event Viewer. You can scroll through these listed events to see the date and time of each one.

When finished, you can close Event Viewer.

I checked the Detected and found about 20 updates, but they show nothing downloaded. I click download update. everything runs fine but nothing downloads. The updating definitions windows shows no updates found.  Why is this if the detected shows updates for this last month.

Purpose

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

Explanation of Severity

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

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

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

Explanation of Supersedence

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

Additional Information

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

Description of Update Types

Security update

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

Update

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

Critical update

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

Security-only update

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

Monthly Rollup

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

Hello,

I have three issues with the new next gen patching system.

Landesk version = 2016.3        10.1.0.168

1. Some of the 3rd party applications will not automatically download the patch even though it has been detected on multiple workstations.
   
   
   
2. Custom variables for patch definitions is empty and greyed out. For example there use to be multiple custom variables for Java.
   
   
   
   
3. In the Affected Computers section of the Meltdown patch MS18-01-MR7-INTL I'm seeing a large amount with the "Reason" stating the "Pre-Req Check Failed." I know one of the requirements for this is the reg key that certain Antivirus software needs to place. We have Symantec and I have confirmed that it is placing the reg key in the proper spot. I know there will be some that were missed but Landesk is reporting 4000+ workstations with "Pre-Req Check Failed"
   
   

Wondering if anyone else has these two issues before I open a case with Support.

Thanks,

Andrew

Just wanted to give everyone a heads up, we discovered an issue when we were pushing out patches a couple weeks ago that was causing Ivanti to constantly request reboots. It appears that MSNS18-01-4078130 and IVA18-001 fight each other on enabling and disabling the mitigation against Spectre, which causes Vulscan to prompt for reboots as they cycle installs. You have to pick one or the other (enable or disable mitigation). Just something to be aware of. I couldn't find any information that these two would conflict, though it does make sense as to why they would.

Overview

Ivanti Endpoint Manager’s Patch and Compliance tool now welcomes our Next Generation patch engine. This new architecture enables us to continue optimizing well into the future and is only applicable to the Windows environment. As a preliminary feature, we’re providing the ability to opt-in, allowing for a more controlled introduction of all Next Generation content into your environment. The new patch engine is currently available in the 2017.3 product version.

^Updated We are now offering this feature in ALL supported versions of the product.

Definition Downloads

In the definition download utility, a new definition type exists under Windows | Vulnerabilities | Next Gen Microsoft Windows Vulnerabilities (beta).

^New As of 3 Jan 2018, the Next Gen Microsoft Windows Vulnerabilities (beta) option is no longer applicable. All new Windows Vulnerability (this includes 3rd party software) content has been formatted to use the Next Gen scan engine and is contained under Vulnerabilities | Windows Microsoft Vulnerabilities. Any content downloaded prior to 3 Jan will not be affected by this change.

^New

When selected, all associated Next Gen binaries/vulnerabilities definitions will be downloaded to the core. The binaries (about 30 MB) will be contained in Managementsuite \ Ldlogon \ Timber directory and the definition grouping will be based on your configuration and download filters. Upon definition download, the following can be expected:

Definition Download	Managementsuite \ Ldlogon \ Timber

The Managementsuite \ Ldlogon \ Timber  \ Content folder will contain a WindowsPatchData.zip file and associated Delta zip files. The WindowsPatchData.zip file contains all vulnerability detection rulesand the Delta zip files contain the differences. This content, along with the remaining Next Gen binaries, will be downloaded to the endpoint upon scanning against Next Gen content. The main WindowsPatchData.zip file will only be downloaded once, Deltas are downloaded to the Core if there are differences that aren't in the WindowsPatchData.zip file. Once the endpoint has the main zip file, it will only retrieve the Delta zip files when scanning against Next Gen content.

30

Upon definition download completion of Next Gen Microsoft Windows Vulnerabilities (beta), filtering for this definition type can be done by using the filter string "Next Gen". Every next-gen definition has the filter string hardcoded in the Summary column.

To isolate these definitions, a custom patch group can be created to house these definitions. If you elect to do so, a manual transfer has to take place. To further isolate which devices scan against this custom group, an alternate Distribution and Patch agent setting can be configured to scan against this group. More information on how to configure this is outlined in How to Scan and /or Repair against a custom group and  How to use Custom Groups to repair groups of computers.

Content Changes

Every Next Gen definition will contain a pre-defined fixed script for Detection and Remediation. The pre-defined detection script will evaluate Registry, File and Script logic to determine if a device is vulnerable to a definition. The detection details have been included at the beginning of the script content. The Files and Registry Settings section will be blank for all Next Gen content.

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

Distribution and Patch Agent Setting

^Updated The "Enable security scan debug trace log" UI feature is only available in 2017.3 and newer product versions. To enable debug trace logs for versions 9.6 - 2017.1 run the following cmd locally on the endpoint or distribute a script to the desired device:

 

vulscan /enableDpdTrace=true /showui (the showui switch is optional).

 

This will generate additional logging in the Programdata\Landesk\DebugLog folder consisting of the following (2) files:

• PatchManifestSyncSDK.log
• PatchScanSDKDpdTrace.log

To enhance the log level for all Next Gen content definitions, the following addition has been made to the Distribution and Patch agent settings:

This feature is only intended for troubleshooting purposes and should not be on in your default agent setting. When troubleshooting a Next Gen content issue, please create an alternate Distribution and Patch agent setting, enable this feature and assign this setting to the device during troubleshooting only.

Diagnostic Tool

^Updated The "Get debug logs and zip (patch)" feature is only available in 2017.3 and newer product versions.

To retrieve logging remotely access the Diagnostic tool and select the Logs | Client option to view client-side logs. An additional option "Get debug logs and zip (patch)" is present for debug logging for all Next Gen definitions. This will only function if the Distribution and Patch agent setting has Enable security scan debug trace log selected.

How Does Scanning and Remediation Work

If the endpoints are on a supported version of the product, the agent does not need to be updated immediately to take advantage of the enhanced patch engine. All devices on an unsupported product version will need to be upgraded. Upon initiation of the vulnerability scanner, the self-update feature will update the necessary vulscan files to ensure compatibility between the files on the client and the latest files on your 2017.3 core. For more on the Self Update feature please reference About Patch Manager Self Update. These binaries must be updated in order for the Next Gen binaries to work with vulscan.exe.

Scanning:

A security scan works the same as before for all current content. Whenever the scanner encounters a definition with Next Gen content it will launch the fixed script contained within the definition and perform the following actions:

 

1. Check for definition scan results in memory.
2. If this is the first Next Gen definition encountered in the current security scan, no scan results will be found on the client and the following will occur:
   1. The client will check if it needs to download any Next Gen binary files from the core (ldlogon/timber) and transfer them to the LDCLient\Timber directory:
      1. The detection rules “WindowsPatchData.zip” file (about 14MB) is updated on the content servers every time new content is added and will be download to the client. If WindowsPatchData.zip already exists on the client, the smaller delta files will be used to update this file to the current version.
      2. Additional Next Gen binary files will be downloaded if the current versions do not already exist on the client:
   2. The Next Gen COM object is then registered on the client to allow Vulscan.exe to interact with the Next Gen scan engine
   3. The Next Gen scan engine then scans for ALL vulnerabilities and stores the scan results “in-memory”. A FULL scan of all vul_defs is only completed if this is the first Next Gen definition encountered in the current security scan.
   4. The script then references the in-memory scan results to determine if the current definition is vulnerable.

 

The security scan continues scanning as usual.  For any remaining Next Gen content definitions in the current security scan, the detection script will return the result of the specified definition from the in-memory scan results.

The Next Gen scanner runs (maximum of once per vulscan instance) it checks for everything and stores that information in memory, but that information is only used by Next Gen definitions. Legacy definitions work the same way they always have.

 

Remediation:

 

1. Patch files (Default location - Ldlogon/Patch) uses the existing download mechanism "lddwnld.dll" to transfer the patch files to the sdmcache directory on the client.
2. The pre-defined remediation script calls the Next Gen SDK with a GUID, Language and a unique file name that’s used for patching.

• A temporary “package” is created during the repair and contained on the client (Programdata\Landesk\Timber\Pkgs) which is used by the Next Gen patch SDK.

 

Logging

The vulscan.log file will continue to serve as the primary log for content detection and remediation, however, several additional logs have been introduced to provide further insight on the activity of the Next Gen content.

• vulscan.log (Programdata\Landesk\Log folder)
• PatchManifestSyncSDK.log (Programdata\Landesk\Log folder)
• PatchScanSDK.log (Programdata\Landesk\Log folder, only created when debug trace logging is disabled)
• PatchScanSDKDpdTrace.log (Programdata\Landesk\DebugLog folder, only created when debug trace logging is enabled)
• STDeploy.log (Programdata\Landesk\Log folder, but only created when repairing)
• TimberDeployEvents.log (Programdata\Landesk\Log folder, only created when repairing)

Pre-Staging Next Generation Binaries

Pre-Staging Next Generation Binaries

When will this patch be available in Patch Manager. Our Security Team is anxious to get this out to the masses. If it will not be available soon I will need to create a software distribution task to deploy.

Per the Ivanti doc Ivanti Patch News Bulletin: Ivanti has Released Content to Mitigate a Vulnerability in Intel Active Management Technolog… , I was deploying the AMT mitigation patch, but it appears to not "stick" on some windows 7 machines.  The patch installed successfull (green check) but it keeps being detected and then reinstalled.  Anyone else experience this?

Hello,

I have an enviromnet of about 1200 Windows machines. I need to implement a patching solution which would be minimally affecting users. My users complain about prompts to restart a computer. They shut them down when they end their day after 8 hours of work. This way computers are restarted everyday. Whey i deploy patches the percent of installed patches is low. Most of errors are return code 437 "The device must be rebooted first" but computers were already shut down and started so why do these errors happen? I was thinking about setting "ignore pending reboots" Would that be a good idea in my case?

Disclaimer

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

Description

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

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

How to use the DPDTrace GUI

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

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

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

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

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

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

OEM Version: (EPM Customers)

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

Patch Type:

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

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

10. Click Run to start the scan.

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

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

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

          a. The zip file will be named HFCLi_YearMonthDay.zip

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

Additional Information

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

I currently have a case open with Ivanti but I thought I would propose a question to everyone and see if anyone has had this issue on 2017.3 SU2. I don't have the ability to download updates within Patch and Compliance unless I use the Core specifically. This is the error prompted everytime on remote console. Steps I've done already seen from other post.

1. Reactivated the core.

2. Restarted server

3. Restart workstation

4. Checked content tab to see if Verify Hash marker was selected. Apparently by default in 2017 this option is greyed out automatically.

5. Installed core software on separate machine to see if my machine has gremlins. It doesn't, the separate console pulls the same error on downloading updates.

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

MORE INFORMATION

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

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

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

HOW TO TELL WHEN A DEVICE LAST REBOOTED

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

systeminfo | find /i “Boot Time”

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

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

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

PATCH INSTALL & CONTINUATION

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

PATCH DETECTION ERRORS & AUTOFIX

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

LOGS TO REVIEW

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

How to:  Retain more vulscan logs before they are overwritten

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

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

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

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

When I create an operation, select a Deployment Template (which includes a post reboot time) and also schedule an install time for the patches, does a template override the Install the patch(es) option?  I am trying to determine when these machines will actually reboot.  If it would be after installation in any circumstance or only when specified in the template.

I've really noticed this since the switch to the Next Gen patching.  I now have several machines that show under their "missing patches" rules that have "DETECT" in their name but have no repair action.  For example, last months "MS18-02-SO7_INTL" vulnerability has 6 rules in it.  Three appear to be actual patches, while three have no download associated with them and no repair action.  If I scan this vulnerability against machines, they detect the "DETECT" rules, but not the actual installs.  So I end up with something like this:

Why is it not actually installing anything, and how can I determine what needs to be done here?  Here's the actual vulnerability properties:

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

Background:

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

Step by Step:

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

For your reference:

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

LDMS 2016.0 console.exe version is 10.0.XX.

LDMS 9.6 console .exe version is 9.6.XX

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

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

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

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

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

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

Reference:

Troubleshooting Core Server Activation

Utility to activate the core server has stopped working

How to Activate the Core Server

How to activate the LANDESK Core Server