Hello,

for your information (ivanti support is working on it,Case 01399373)...

we've recognized, that the patch Definition of MS18-01-SO81_INTL replaces some rules by itself (s. pictures) instead by another definition,

I fear, the deployment will not work in this way any longer correct...

Last week the patch was deployed on test clients without problems, but without a replacement entry...

BR

Axel

EndPointManager 2017.3 10.1.30.401

Hello, I think I already asked this before but can't seem to understand.

1. Everything under Detected(current scope) is/are (I assume) vulnerabilities found for the Selected Scope

2. If I schedule a repair task for a particular vulnerability, and the task is successful, when are the vulnerabilities removed from the Detected(current scope) Folder?

After point 2 I manually ran on the Client:

a) PolicySync

b)Security Scan

c) Gather Historical Information on the Core

d) restarted the client

e) PolicySync

f)Security Scan

g) Gather Historical Information on the Core

But the vulnerability is still listed there.

What M I missing?

Any help is appreciated.

Best

Hello community,

I have a problem since 3rd January and th new Generation engine. I use Landesk 2016 Version 10.0.0.271

For Download update, I have only Vulnerabilites / Microsoft Windows Vulnerabilties which are checked

For exemple, the MS18-01-MR7_INTL

If I want to install this package, at every time, the install failed

The correctif is downloaed in my patch folder on our server

but the timber folder is empty !

Has someone has the same problem ?

Where is the problem ?

Thanks a lots ! Have a good day !

stéphane

We have noticed that a lot of our newer machines that are Dell 5480's and Win10 1703 Enterprise that they are not showing as vulnerable at all for the windows10.0-kb4056891-x64-RS2_tw1154910.msu patch. On the ones that are not showing in EM as vulnerable when you run the powershell ( get-speculationcontrolsettings) everything is red and the reg key is present. However you can then install the patch manually and update the BIOS and get all green on the powershell. Is anyone else seeing this on any machines from any vendor? What is the Ivanti detection logic that these machines are not showing as vulnerable when they clearly are?

Hi!

At our company we have around 1500 OSX computers.

The only patch available for Spectre and Meltdown vulnerabilities so far is to upgrade to OSX High Sierra 10.13.2

We have around 80% of those OSX computers running Capitan or Sierra.

I would like to make the 10.13.2 installer available to all those computers using LANdesk and our preffered server architecture (we have over 12 offices all around the world with preffered servers configured at each one so all files are downloaded locally).

Is there any way to do this with this software?

Provisioning is not the answer for us since we need the users to upgrade when they want to and keep all their software and files as if they were upgrading directly from apple update.

Thanks!

Cheers.

Francisco.

Has anyone run into issues patching Dell Latitude BIOS or drivers with patch manager? We are looking to start patching Dell Latitude BIOS and possibly drivers, as well. Do you see any downside to using Ivanti patch manager? I'm a little wary patching the BIOS or firmware because the computer needs to restart. How Ivanti know the patch is complete?

We are running Ivanti 2017.3.

Hello everyone,

Recently I noticed that the Microsoft December 2017 patch rollup detection rules disappeared from Patch and Compliance. The MSU files have also gone. Another person who works on patching says he noticed a couple others missing as well. I am currently re-running the Definitions Download to see if it gets picked up again, but has anyone else ever seen this? Is there a log to see if someone removed the rule (might have been an accident somewhere)? We are under some specific regulations where we need to push out certain things, and only those things, for some critical systems, and having something disappear really causes a TON of paperwork.

Any insight would be greatly appreciated.

(The patch that disappeared for me is 4054518_MSU. It has not been pulled by MS from what I can tell).

Thank you,

~Kevin Brooks

Anyone else seeing this patch that as was downloaded only a few days ago with a published date of 2005!

This is now showing up in our xtraction reports.

I assume this is an oversight in the definition rules somewhere.

Seems to be the same for MSFT-DN15_intl as well but not quite as bad as only 2017.

Hello,

We have problems with different users in our organization. When you start VulScan, the PCs are blocked with excessive memory usage and in some cases 100% disk usage creating a system lock.
In our infrastructure is installed McAfee antivirus, and reading some thead we have seen that there could be an inability between the two.
We have taken steps to exclude the entire Landesk folder from the virus scan, but unfortunately the problem still occurs.
Do you have any advice to give me to try to permanently solve this problem?

Landesk Software 10.1.10.287

Best regard

-Alex

Hi,

We are running on Endpoint Manager 2016.

This week we noticed that for all clients in our local site the last Vulnerability Scan had been almost over a week ago. Clients from other locations have still been updated regularly (every day) as scheduled.

We then found out, that two Vulnerabilies caused the vulscan to crash: MSRT-001_INTL (The Microsoft Windows Malicious Software Removal Tool) and APSB18-01_INTL (Security updates available for Flash Player)

After moving those vulnerabilities to "Do not scan", all of our clients on our local site are working fine again.

When vulscan stops, the last entries within Vulscan.log are like:

Thu, 18 Jan 2018 16:01:30 Running detection script

Thu, 18 Jan 2018 16:01:30 Checking pre-requisite...

Thu, 18 Jan 2018 16:01:30 filesDownloaded: True

Thu, 18 Jan 2018 16:01:30 AlreadyScanned: True

Thu, 18 Jan 2018 16:01:30 Checking detection... (PatchGuid: {0001c647-0000-0000-0000-000000000000}, Lang: INTL)

Thu, 18 Jan 2018 16:01:30 Clearing status...

Thu, 18 Jan 2018 16:01:30 GetLanguageId: 'INTL' ==> Language Id: 0

Thu, 18 Jan 2018 16:01:30 Patch found 116295: {0001C647-0000-0000-0000-000000000000}

Thu, 18 Jan 2018 16:01:30 RegionId '0' belongs to Lang: INTL

Thu, 18 Jan 2018 16:01:30 Missing patch found: BulletinName: APSB18-01, PatchId 116295: {0001C647-0000-0000-0000-000000000000}, Lang: INTL, regionId: 0

Thu, 18 Jan 2018 16:01:30 ----------------- DETECTION RESULT ----------------------------

Thu, 18 Jan 2018 16:01:30 FileTestResult:

Thu, 18 Jan 2018 16:01:30 C:\WINDOWS\SysWOW64\Macromed\Flash\FlashUtil32_28_0_0_137_pepper.exe

Thu, 18 Jan 2018 16:01:30  [File version expected]: 28.0.0.137

Thu, 18 Jan 2018 16:01:30  [File version found]: 0.0.-1.-1

Thu, 18 Jan 2018 16:01:30  [File test action]: [1]: Change - the file is not the correct version

or

Thu, 18 Jan 2018 15:13:22 Running detection script

Thu, 18 Jan 2018 15:13:22 Checking pre-requisite...

Thu, 18 Jan 2018 15:13:22 filesDownloaded: True

Thu, 18 Jan 2018 15:13:22 AlreadyScanned: True

Thu, 18 Jan 2018 15:13:22 Checking detection... (PatchGuid: {000053db-0000-0000-0000-000000000000}, Lang: INTL)

Thu, 18 Jan 2018 15:13:22 Clearing status...

Thu, 18 Jan 2018 15:13:22 GetLanguageId: 'INTL' ==> Language Id: 0

Thu, 18 Jan 2018 15:13:22 Patch found 21467: {000053DB-0000-0000-0000-000000000000}

Thu, 18 Jan 2018 15:13:22 RegionId '1031' belongs to Lang: INTL

Thu, 18 Jan 2018 15:13:22 Missing patch found: BulletinName: MSRT-001, PatchId 21467: {000053DB-0000-0000-0000-000000000000}, Lang: INTL, regionId: 1031

Thu, 18 Jan 2018 15:13:22 ----------------- DETECTION RESULT ----------------------------

Thu, 18 Jan 2018 15:13:22 FileTestResult:

Thu, 18 Jan 2018 15:13:22 C:\WINDOWS\system32\MRT.exe

Thu, 18 Jan 2018 15:13:22  [File version expected]: 5.56.14443.1

Thu, 18 Jan 2018 15:13:22  [File version found]: 5.55.14421.1

Thu, 18 Jan 2018 15:13:22  [File test action]: [1]: Change - the file is not the correct version

Windows System event log records an error with Event ID 1000:

Name der fehlerhaften Anwendung: vulscan.exe, Version: 10.0.1.27, Zeitstempel: 0x56be1c66

Name des fehlerhaften Moduls: TimberHlpr.dll, Version: 11.0.0.369, Zeitstempel: 0x5a305888

Ausnahmecode: 0xc0000409

Fehleroffset: 0x0002878c

ID des fehlerhaften Prozesses: 0x2080

Startzeit der fehlerhaften Anwendung: 0x01d39071735f7fa7

Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\LANDesk\LDClient\vulscan.exe

Pfad des fehlerhaften Moduls: C:\Program Files (x86)\LANDesk\LDClient\timber\TimberHlpr.dll

Berichtskennung: 0b7aae09-f35e-4338-8bec-80a76b4234ef

Vollständiger Name des fehlerhaften Pakets:

Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

We already deleted both vulnerabilities to let them download again overnight, but still the same.

Anyone else having trouble with those vulnerabilities or any idea why this happens just to our local clients?

Regards,

Robert

Hi,

How is it best to deploy an MSU file? I cannot see it listed in patch manager.

Can I request to have it included? Or is it best to run it as software deployment, if so how?

Many thanks,

Dan.

As the Enterprise Ivanti Endpoint Manager Administrator of a large company that has had over 15 Core Servers with over 12,000 systems and over 20 other Ivanti tech's to support I have found "how should I patch" to come up often at my location as well as on this forum.

Like Windows, there are 3 or more ways to do most anything in Ivanti Endpoint Manager patching being one of those, and I have re-written the way I advocate our techs patch in Ivanti from the way I recommended a few years back and thought I would post it here for other to use as needed. It is not the only way, nor am I saying it is the best way.

Please keep in mind that this is a basic method, simple and effective.  I did not go into Auto-Fix, some of our advanced tech's use it, others don't.  I wanted something a newbie could pick up, read and begin patching in a very short amount of time.

Picking what patches to patch can be a political nightmare depending on your companies policies.  Ours went from 12 groups doing it all differently, some patching critical's only, some not patching, others patching everything possible to a reduced number of groups that all now have a "baseline" that is set from up above that is pretty in-depth and aggressive deadlines to have them patched by.

In short, we patch all security related items with few exceptions that are patchable via Ivanti and we do it aggressively as you must nowadays in this world of exploits.

If you are not patching, I strongly suggest you start.

Attached is the method I recommend, it uses two tasks, one a "Push" the other a straight "Policy".  Why not a "Policy Support Push" you ask?  We were doing that but are finding that some systems will stick in the "active" bin of the scheduled tasks for some reason (being researched) and thus the task will not become a policy.  If you restart the task, some of those systems will clear, but then others will stick... and so on.

It goes over creating a group of patches, creating the tasks, targeting the systems and scheduling the deployment.

I look forward to your feedback and I hope this helps some of you.

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

Hello,

I did tried linux patch in over demo side. But did not security and patch scanning.

Error is belov. I used it IEM2017v3.

I am install agent on Centos7 x64.

Same time i am tried this solution below. But the situation is the same. Can you help me this about?

https://community.ivanti.com/docs/DOC-61722

https://community.ivanti.com/docs/DOC-62816

raxfer.log is attached.

I have confirmed on 2 systems thus far. After installing the January patch set from MS, PowerShell ISE and Cherwell Management Suite both crash on launch. I'm still working on digging further into it, but would like to know if anyone else has been seeing issues. This is on Windows 7 64bit.

Hello.

I'm trying to download associated patches in Patch Management.  I can download the patches for Microsoft but not for other vendors (like Apple, Adobe, Google, Mozilla, etc.).  I have the role for Patch Management in EndPoint.  The other person who does the patches with me has admin rights in EndPoint.  He's able to download them without any issues.  Do I need additional rights on the core server or in EndPoint to allow me to download non-Microsoft patches?

For applications that require IE to be the default browser for applications and you need it for any user that may login, you will need to apply the following attachment for any user logs in. You will also need to apply this after a version change example 1607 - 1709.

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

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

Description

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

Assumptions

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

Process

Step one: Prepare both core servers to have accurate data

In order to download a complete set of data to transfer from the light core to the dark core, the database tables related to Patch Manager must be reset.  This must occur on any core server that has previously downloaded patch data, otherwise a complete set of data will not be downloaded.

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

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

Step two: Prepare the Dark Core folder structure

On the Dark Network Core Server, you will need to have a location for the vulnerability XML files and a location for the actual patches themselves to be stored in. For ease of use, we recommend using the already created patch folder structure that is set up when you install Ivanti EPM. By default, patches are stored in the \Program files\LANDESK\ManagementSuite\LDLogon\patch  folder. If a different location is desired this article can be used to set up the alternative location.

If patches have not been downloaded on the dark core previously the patch folder may not have been created and should be manually created.

Step three: Retrieve content on the "Light Core"

1. Within Security and Patch Manager open the Download Updates window and select all of the categories you want to download.
2. In addition select "Download patches for definitions selected above and also the radio button for "for all downloaded definitions" and click "Apply" and then "Close".
   
3. From a Command prompt, change to the LANDESK\ManagementSuite folder.
4. From a Command prompt, type "vaminer /noprompt /copy" and hit enter.  (If scripting this action to run regularly please add the /noui" switch to the vaminer command line switches).
5. Select the desired categories to download and click "Download now"
   
   (Vaminer.exe is the executable that runs to download content from the Ivanti patch content servers).
   
   The first time this is run it will take quite a while as it will not only be downloading vulnerability definitions but also all patches.  (Due to this you will need a large amount of storage space on the dark core server).  This will download updates and store them to a to the patch directory.  The default patch directory is \Program Files\LANDESK\ManagementSuite\LDLOGON\patch.
   

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

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

Copy ENU_PatchSourcesXXX*.xml (Where XXX equals the current LDMS version) from \Program Files\LANDESK\ManagementSuite\LDMAIN to \Program Files\LANDESK\ManagementSuite\LDLOGON\PATCH on the source core.  This step is necessary because Vaminer.exe (the program that is downloading the Patch Content) expects that file to be in that location.  Again, this needs to match the version you are running: 9.5 (ENU_PatchSources95.xml), 9.6 (ENU_PatchSource96.xml, 2016.3 (ENU_PatchSources101.xml) and so on.  Modification of the file is not necessary, it just needs to exist in that location.

Step five: Prepare the ENU_PatchSourcesXXX.xml on the Dark Core

In the \Program Files\LANDESK\ManagementSuite\LDMAIN folder there will be several files called ENU_PatchSources and then a numerical ending.  These stand for the current and prior versions of LDMS.   Choose the one that is the latest and matches your version on your core server.

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

• ENU_PatchSources951.XML
• ENU_PatchSources961.xml
• ENU_PatchSources101.xml

We would select ENU_PatchSources101.xml as this corresponds to LDMS 10.1 (2016.3) and begin editing it.

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

Modify the Enu_PatchSourcesXXX.xml as modeled below:

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

Before:

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

After:

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

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

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

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

The following example is for the vulnerability definition category Windows Vulnerabilities  Again, you will modify the path from the patch server location to a local directory. You also will add the tag <Enabled>true</enabled>.  This is the same as ticking the checkbox next to the vulnerabilities category when bringing up the Download Updates tool.

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

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

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

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

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

 

     Before:
     <Source>

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

                   <Description>LANDESK Data Analytics Updates</Description>

                   <ShowInLDSM>true</ShowInLDSM>

                   <ShowInLSM>true</ShowInLSM>

            </Source>

 

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

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

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

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

1. Now you will need to move the data to the dark core for insertion into the database.   Copy the entire Patch directory and all new subdirectories and all contents to an external hard drive, network share or whatever method you prefer.  This will include the .XML files for the Vulnerability Definitions and also any patches that were downloaded to the light core.
   
   If the light core will have access to the dark core this can be done automatically through a file transfer process, automated or otherwise.  The key is to download content on the core server regularly using the "vaminer /noprompt /noui /copy" switch and then copy the updated data to the Dark Core.
   
   
2. When copying the Patch Directory from your Light Core to your Patch Directory on your Dark Network Core, ensure the directories look the same.
3. Run Download Updates on the Dark Core Server, if running via script simply run "VAMINER.EXE" from the main ManagementSuite folder.

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

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

1. "Vaminer /copy /noprompt /noui" is run on the core server.
2. All files from the Patch directory and it's subdirectories are copied to the Patch folder on the dark core.  This can be done using content replication, robocopy or other preferred methods.
3. Vaminer.exe is run on the dark core (without switches).

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

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:

Hi Anyone else having the same problem ?  I am only getting this error for this one patch, others are downloading fine.

Verifying access to site Europe (https://patchemea.landesk.com)

Verification complete

Attempting to download 2 patches

Downloading GoogleChromeStandaloneEnterprise64.msi (49288 KB)...

Hash for patch googlechromestandaloneenterprise6403282119_x64_tw1176320.msi does not match with host.  Discarding.

Deleting C:\Users\byramsadmin\AppData\Local\Temp\3\googlechromestandaloneenterprise6403282119_x64_tw1176320.msi

Downloading GoogleChromeStandaloneEnterprise.msi (48828 KB)...

Hash for patch googlechromestandaloneenterprise6403282119_x86_tw1176310.msi does not match with host.  Discarding.

Deleting C:\Users\byramsadmin\AppData\Local\Temp\3\googlechromestandaloneenterprise6403282119_x86_tw1176310.msi

Download Results - 0 succeeded, 2 failed, 0 overwritten, 0 duplicates, 0 skipped

Failed downloading 1 or more patches

Stephen Byram
Technical Lead
Western Sussex Hospitals NHS Foundation Trust