Hello,

Some of my clients are reporting this issue (all are Windows 7 and all worked fine for years till now)... i have looked at the article with the same title written by Ivanti and all the ISS settings they ask to check are as they are supposed to be. Anything else i can try to figure this out? Again, out of the sudden 10 of 150 clients are exhibiting this behavior.

Thanks!

How to troubleshoot Core Server patch content download issues

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

Log Locations

Patch content download activity

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

Antivirus content (pattern files) downloads

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

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

Proxy Configuration recommendations

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

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

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

Typically the first thing that should be checked is the Proxy Configuration.  If possible it is best to configure the Proxy Server to allow the Core to bypass it entirely. 

The Proxy Information must be filled out in the Proxy tab within the Download Updates tool if a Proxy is to be used.

In addition, it may be necessary to configure the Proxy information within Internet Explorer:   (Internet Options --> Connections tab --> Lan Settings --> Proxy Server)

Again, connectivity issues to the Ivanti Patch Servers are almost ALWAYS the issue.  Proxies, Internet Caching appliances, etc are quite often to blame.

Patch Content Servers - DNS Resolution

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

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

DNS on the core server must be able to resolve these hostnames.  Ideally *.landesk.com and *.shavlik.com should be reachable in both directions.

• *.landesk.com
• *.shavlik.com
• Various vendor patch URL's as detailed in this article.

Windows Certification Authority URL's

These URL's should be reachable by the core as well to make sure the certificates are kept up to date:

• *.digicert.com,
• *.geotrust.com
• *.verisign.com
• *.symcb.com,

Ivanti Antivirus URL's used

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

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

Open Ports

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

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

- DOMAIN\username

    - username

- username@domain.com

Vulnerability content category not showing up in the Download Updates window

The following steps should be followed:

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

If anything is missing, incorrect (such as product version is wrong), or shows as expired you should reactivate your core server.

From within the Core Server Activation Tool, make sure the Contact Name and Password are correct and click "Activate".

If you have reactivated and the information still does not appear correct, contact Ivanti Support to investigate further.  If either is expired, contact your Sales Representative or the Licensing Queue at Ivanti Support for further assistance.  This can be done through the Self Service Portal or via Telephone.

A screenshot of the Licensing screen from the Core Activation Utility would be advised to give to Ivanti Support.

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

If a particular vendor's updates fail to download (for example Adobe, Java, etc), this is most likely due to a proxy or other internet appliance configuration.

The proxy or Internet appliance must be configured to allow the core server access to various vendor download sites, both on HTTP and FTP.

For a complete list of the URL's used by Ivanti patch content, consult this article.

How to exclude scanning of patches from a certain vendor

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

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

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

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

Patch storage folder resetting back to defaults

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

How to change the default patch download location

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

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

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

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

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

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

When this error occurs, there is likely another update process that is still taking place, possibly from a scheduled task, or a previous download process has hung.

Another possible cause is another user logged into the core server using Remote Desktop in a separate session.

Typically closing and reopening the Management Suite console will resolve this error.

If a Remote Desktop session is not being used or is being used in an Admin Session, and the Core Server has been rebooted and the error still does not go away, it is possible that there is a lock entry in the database that needs to be cleared.

Within SQL Management Studio, connect to the Management Suite database, open the Query Tool, and do the following:

select * from PatchSettings where Name like '%LOCK.UpdVulnLock%'

If entries, as pictured below, are returned, those rows should be deleted:

In order to delete the rows, run the following query:

delete from patchsettings where Name like '%LOCK.UpdVulnLock%'

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

When trying to download updates for definitions through Patch and Compliance Manager all patches and of the following errors is given:

"Object does not match the specified SHA-256 hash" or "Signature is not valid, failed to download platform information"

To resolve this, uncheck the box "Verify definition signatures/hashes before downloading" on the Content tab of the Download Updates window.

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

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

Hello!

We're having some frustrating behavior when trying to schedule repair tasks to push windows updates.

When we create these tasks, they default to policy supported push. We leave the frequency under Task Settings as Run Once, Check Ignore Subsequent requests. Under Schedule, Start now, Repeat every Day, Schedule devices that did not succeed.

In this case, we're seeing Successful devices go back to active randomly over the next few days, when no changes to patch groups were made.

We tried changing this task to push, same settings, but after 20 minutes or so, the task changes to Leave Unscheduled and it does not re-run next day.

Support has not been helpful on giving us a clear answer on if this is a bug or a mistake on our end, we havent found a concrete "best practice" for this method.

(Using 2017.3 SU3)

Any guidance?

I am attempting to convert an existing WSUS server patching strategy to LanDesk.

My current WSUS Server patching strategy has all approved patches downloaded to the server when available and then each server is part of an AD group telling it when its OK to start Automatic updates.

So we have AD group for say "Sunday - 2AM" and "Monday - 5AM" and servers are members of the groups accordingly.

So in LD I created a bunch of different Agent settings to match my AD patch groups and then I apply the appropriate agent setting to each server.

So now I have a test server with its Agent settings listing the maint windows from 6pm to 7pm each night.

I created a repair task and scheduled it to run once at 5pm.  when the repair task runs at 5pm, it fails with a return code 491 - Some/All actions have been deferred until the next maintenance window.

I understand this message.

What I expect is that the patches have been downloaded to the server via the agent and then when its 6pm, the agent will start up and install the patches.

However, this is not happening and I'm not sure why?

Is it because I need to run the repair task during the maintenance window?  or do I need to have Autofix somehow enabled?

Just not sure why its not doing what I expect it to do.

any insight would be appreciated.

Issue

Gather Historical Information crashes the LANDESK Console.

Gather Historical Information task is failing to run.

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

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

Solution

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

9.6 or 2016 Core Server:

HKLM\SOFTWARE\LANDesk\ManagementSuite\WinConsole

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

We are attempting to install Windows 10 1709 release.  I have followed both steps to install using patching and provisioning, not having any luck.  Both tasks fail.  I have gone over these instructions multiple times and can not figure out what I am missing.  All help is appreciated.

LANDESK Patch News Bulletin: LANDESK has Released Content that will Update Clients to Windows 10 Anniversary Update 04-AUG-2016

patching windows to 1709

Re: anyone been able to push 1709 update to windows 10 in LANDesk?

2016.3 SU5 - I have 3 devices stuck in the Active queue of a scheduled task that was auto-generated by a rollout project. The devices failed because the core couldn't detect an agent. I did a "retry selected failed devices" when they went to the failed queue, which placed them back in the Active queue, but now they're stuck there and I can't find a way to retry them again? I found some of the LANDesk services were disabled on these, so after enabling them I can't find a way to retry them against the task? If I remove them from the task, and then drop them back in, they just sit in the Pending queue, even if I right-click the task and do any of the Start options, the devices just remain in Pending?

Overview:

Ivanti Patch and Compliance now provides support for Office 365 versions 2013 and 2016.  Patch and Compliance administrators can now scan, detect, and remediate client devices that have Office 365 installed. For Office 365 version 2013, Ivanti leverages the Microsoft Office Deployment Tool to perform the remediation tasks for updating Office 2013 installations. For Office 365 version 2016, Ivanti has developed an Office Com API to perform remediation tasks for updating Office 2016 installations. Ivanti provides a utility (Office365Util.exe) for you to use to download the Office installation data and to check the hash for Office 2016 installation data. When the Office patches are downloaded, Ivanti Endpoint Manager will check the hash on the pertinent files to ensure validity.

High Level Process

1. The Ivanti administrator downloads Office 365 definitions from the Ivanti global servers.
2. Once the Office 365 definitions are downloaded to the core, the Ivanti administrator can scan for those Office 365 vulnerabilities.
3. In order to remediate (apply latest patches) detected vulnerabilities, Ivanti administrator have to manually run, on the core machine, a new tool provided by Ivanti (Office365Util.exe). Using this tool, the Ivanti administrator can choose the Office 365 versions that are relevant to the environment. The Ivanti Office 365 utility will download the patch binaries and the Microsoft Office deployment tool from the Microsoft cloud.
4. Once the patch binaries are downloaded to the core, the Ivanti administrator can apply the patches to all vulnerable endpoints using the standard method of applying patches.

Step 1: Download Content

Customers download the Office 365 vulnerability definitions, the O365Util.dll, and the Office365Util.exe from the Ivanti Global Host Content Server by downloading the latest Microsoft Windows Vulnerabilities.

Download Updates (Microsoft Windows Vulnerabilities)	Updating Definitions (Office365Util.exe/O365Util.dll)

Updating Definitions (MSO365)MSOFFICE 365 (Vul_Defs)	MSO365 (Vul_Defs)

Step 2: Launch Office365Util.exe

Upon successful content download, an Office365Utility folder is created under the LDLogon share and will contain the Office365Util.exe file provided by Ivanti.

\\Core_Server\LDLogon\Office365Utility

This utility will allow you to select the specifics regarding the Office 365 product you are patching. Launch this utility directly from C:\Program Files\LANDesk\ManagementSuite\ldlogon\Office365Utility\ by double-clicking on Office365Utility.exe
(do not try to run it via the network share \\Core_Server\LDLogon\Office365Utility or \\localhost\LDlogon\Office365Utility as you will get an error).

Step 3: Select Options from Office365Util

The view provided below displays the available options inside of the Office365Util application (Ivanti Office 365 Utility for Patch and Compliance):

Platforms	Deployment Tools

Channels	Office 365 (2013) Product List View

In order to successfully patch Office 365, select which Office 365 patch product updates to download in order to support client remediation. After selecting the desired product updates from the Ivanti Office 365 Utility for Patch and Compliance application, click START.

Office 365 Tool

The START action will do (2) things:

1. Create an Office365Tool folder under the LDLogon share and process the Microsoft setup.exe file
   
   

   \\Core_Server\LDLogon\Office365Tool

The contents of this folder will contain the Deployment Tool Type (2016 or 2013) selected during the download and all relative installation data applicable to the options selected in the Ivanti Office 365 Utility for Patch and Compliance
application. The display below will outline the contents of both Deployments Tools (2016 and 2013).

Office365Tool	Deployment Tool Options

2016 Content	2013 Content

   
      2. Create an Office365 folder under the LDLogon\Patch share that contains the patch files(s):

\\Core_Server\LDLogon\Patch\Office365

Patch Location

^Updated Office 365 patching is not designed to take advantage of our download technology. The client device will NOT download o365 patch files from a preferred server or peer device. The files will be retrieved from the default or non-default patch location.

Non-Default Patch Location

This section is only applicable to those who have changed the default download location for patches. After downloading the Office 365 patch updates and installation data with the Ivanti Office 365 tool, the following SOURCE will be in the vulnerability definition:

Office 365 (2016)

 

httpSourcesURL="Core_Server/LDLogon/Patch/Office365/DeploymentToolType/Channel/Architecture"

 

Ex: httpSourcesURL=http://2016E/ldlogon/patch/office365/2016/current/x64

Office 365 (2013)

httpSourcesURL=http://Core_Server/LDLogon/Patch/Office365/DeploymentToolType

 

Ex: httpSourcesURL= http://2016E/ldlogon/patch/office365/2013

In order for the Patch Install Commands in the vulnerability definition to interpret the correct patch location, the Custom Variable will have to be set in every MSO365 vulnerability definition.

To do this open the properties on the definition and select the Custom Variables tab. By default the value specified will resolve to the default patch location.

You will need to explicitly set the value to reflect the location your patches reside.

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

References

How to change the default Patch Location for Security and Patch Manager

Microsoft Office 2016 Deployment Tool

Microsoft Office 2013 Deployment Tool for Click-to-Run

Hello,

I am attempting to scan a Windows 10 1709 Machine with the Level 1 Computer CIS-CAT template applied to it. I am getting an error code 106 - Credentials invalid error after applying the policy.

Are there logs of what is happening behind the scenes when you scan a particular machine? If so, where can I review them? Patch for Windows Servers 9.3.0 build 4510

Thank you.

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)

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

               (It has been noted that on LDMS 2017.3 SU3 the file has to be renamed from ENU_PatchSources1013.xml to ENU_PatchSources10132.xml)

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 2017.3 Core server you will likely see three ENU_PATCHSOURCESXXX files:

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

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

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

Modify the Enu_PatchSourcesXXX.xml as modeled below:

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

Before:

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

After:

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

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

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

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

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

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

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

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

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

Symptom

STDeployerCore.log

2018-06-01T11:28:44.2093405Z 171c I Authenticode.cpp:134 Verifying signature of C:\Program Files\LANDesk\LDClient\sdmcache\jre-8u172-windows-i586_tw14468-39207.exe with CWinTrustVerifier

2018-06-01T11:29:03.2302424Z 171c E WinTrustVerifier.cpp:270 Certificate verification failed with error: -2146762748.

Vulscan.log

Fri, 01 Jun 2018 07:29:30 ReportRepairResult returned failure: Repair failed, patch still missing.

Fri, 01 Jun 2018 07:29:30 Message returned from repair script was Repair failed, patch still missing.

Fri, 01 Jun 2018 07:29:30 ERROR(RunVbScript) Failed to run command  - 80004005

Cause

The OS is unable to verify the digital signature. The specific error is -2146762748 which is a Mircosoft error that translates to "The subject is not trusted for the specified action"

Resolution

1) Update the Root Certificate on the client machine.

2) Usually you can get the cert needed from the Patch itself.

     Right click>go to properties>Digital Signatures

     Highlight the cert and click details, this will bring up the Digital Signature Details, click View Certificate

     From there you can obtain the Certificate

     Also click the certification path on the certificate properties, this will also idicate if you have all the neccessary intermediate certificates also

EMP 2017.X

I can't find the W10V1803 under our detected patches.

Is it listed under a different number?

Best.

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

Issue

Error when downloading content "Hash for patch (Patch Name) does not match with host. Discarding."

You can also be getting the following errors:

Causes and Resolutions

For security purposes, each patch file referenced within a vulnerability definition contains a hash value to ensure that the file referenced is the authentic patch file.

After downloading the patch, if the patch does not match, Patch Manager will discard the file.

There are various causes that can contribute to this issue.

Vendors use static URLs

This issue occurs because the update contains a static URL for the vendor file. This means that the vendor uses the same URL for thier files and they only make the latest patch available to download.

Often this is seen with Adobe and Google Crome updates.

A web caching or other networking appliance within the environment is causing the contents of the file to change or is serving up a deprecated version of the file

This is especially when getting the "Invalid XML file TOC_Product.xml" error.

In many environments, web caching appliances are in place.   When Ivanti Patch and Compliance Manager attempts to download the file, the Internet caching appliance intercepts the request and incorrectly delivers an older version of the file.   Once the file is downloaded on the Ivanti Core Server, the hash check fails.

In this instance, the cache for the particular failed file can be cleared on the Internet caching appliance, the entire cache can be cleared, or the Internet caching appliance can be configured to allow the core server to bypass caching.

Manually copying the file to the patch storage directory from a computer that bypasses the Internet caching appliance can verify that this is the issue.

The patch content needs to be updated as the local content is out of date

If the Ivanti Patch Content has been changed since the last time patch content has been downloaded this error can occur.

Download patch content again.   If the error still occurs, try downloading from a different patch content server (US West Coast, US East Coast, or Europe)

Patch definition content is corrupted in the database

If the latest patch content is downloaded, there are no caching appliance is in the environment, the locally downloaded patch file has been deleted from the storage directory, and there is still a failure, the following SQL query can be run to force the content to download again.

This query changes the LANDESKRevision number to "0".   When the core server compares revision numbers with the revision on the Ivanti patch content servers the version on the Ivanti patch content server will be higher, thus the content will download again:

UPDATE Vulnerability SET LANDESKrevision = 0 WHERE vul_id = 'definition name'

A more advanced variation on this is:

select * from VULNERABILITY where VUL_ID IN ('<vul_no1>', '<vul_no2>')

Update VULNERABILITY 
set LANDESKREVISION=0 where vul_id in ('<vul_no1>', '<vul_no2>')

The file has changed after the patch definition was published

If other steps fail, it is possible that the file has changed, and it is necessary for Ivanti to update the patch content.

It is possible that the vendor changed the contents of the file but kept the same filename, and Ivanti has not updated the related vulnerability definition yet.   At times a vendor will make a change to a file but does not publish information regarding the change.

If this is the case, this download should fail regardless of the Core server attempting the download.   This would be a global issue.

In this instance, contact Ivanti Support and request that the patch content be updated.   An Ivanti technician can also verify the file download failure internally.

Manual download patches

It can be difficult to determine if the hash does not match for patches that must be manually downloaded from the vendor.   Typically these require going to the vendor web site, finding the correct file and version, renaming it to the unique filename specified in the rule for the definition, and placing it into the patch download folder.

Hello all,

I have a large number of PHYSICAL machines on network with VMWare Tools installed -- The VMWare Tools update through LANDesk does not work (actually, it can't work at all since VMWare Tools executables simply throw an error on physical machines)

So I tried to uninstall VMWare Tools via VMware Tools "setup.exe" /s /c on a test machine. As far as I can tell, VMWare Tools is removed completely -- I've run several inventory scans since, and Inventory doesnt show VMWare Tools under Add/Remove Programs or Software Products.

Nevertheless, VMWare Tools seems to be detected by vulscan, and it still attempts (and fails) to run the fix.

Can anyone provide any insight as to why it's still detecting?

Hi,

I have an Environment where initial configuration of Windows agent scan option was enabled with auto fix. Which normally take much more time when user run Security scan or policy run the Security scan on the Windows Machine.( Endpoint Manager 2017.x)

What is the impact if we disable auto fix on windows agent configuration settings?

1. Do I need to update all client with the latest installer or

2. I can just disable the option and create new client for new install or

3. Does it automatically detect of disable auto fix so it don't try auto fix when first time scan or consecutive scan?

• • Vulscan Switches for Windows Agents
    • Vulscan switches to control scan types
      • Example: "Vulscan /scan=0 /showui" will scan the type "Vulnerabilities" while showing the Ivanti Vulscan UI.
    • General Switches
    • Reboot related operations
    • VBScript related options
    • Disable certain behaviors
    • Manipulate Data Files
    • Ivanti Endpoint Security Related Commands
    • Shortcuts to open folders or logs:
    • Vulscan switches used for content replication

Vulscan Switches for Windows Agents

This document describes the various switches that can be used on the command line to manipulate the vulscan behavior.   It is recommended to use the different available settings (Distribution and Patch Settings, Reboot Settings, etc) to control the Vulscan behavior otherwise unintended consequences may result.

Vulscan switches to control scan types

Number	Type	Description	Example
0	Vulnerabilities	This category is for security-related releases by 3rd-party vendors such as Microsoft,            For a detailed list of available content click here
1	Anti-Spyware	Definitions and engine updates for the Anti-spyware component within Security and Patch Manager (This differs from the Anti-virus component and is based on the Lavasoft engine and targets spyware and adware)
2	Security Threats	This differs from the Vulnerabilities category in that this is not to address vulnerabilities in vendor code, but simply facilitates configuration changes to tighten down security.
3	Ivanti Updates	Ivanti Patches and Service Updates (not including Ivanti Antivirus which is in category 8)
4	Custom Definitions	Custom-user made definitions, including custom definitions that have been imported.    This will also include other definitions that have been cloned.
5	Blocked Apps	Includes both pre-configured content downloaded from Ivanti Content servers, and any custom blocked application content that has been created.  Some of the Summary information in the blocked applications definitions are provided from http://www.sysinfo.org    (Blocked application legal disclaimer) Click graphic for an example of these definitions:
6	Software Updates	Non-Security related updates for Intel, Ivanti, and Lenovo.    (Click graphic for an example)
7	Drivers	This category includes Dell, HII, HP Client, and Lenovo definitions if they have been downloaded as part of the download updates process.
8	Antivirus	Downloads Ivanti Antivirus definitions, and if selected also downloads updates pattern files for both Ivanti Antivirus and 3rd party antivirus products

Example: "Vulscan /scan=0 /showui" will scan the type "Vulnerabilities" while showing the Ivanti Vulscan UI.

General Switches

Reboot related operations

VBScript related options

Disable certain behaviors

Manipulate Data Files

Data Files	Result	Example
/O=Filename (including full path)s	Send vulscan output to a file as specified in the command line rather than back to the server in the form of a SOAP response.  (Click graphic for an example)
/Log=Filename (including full path)	Sends the vulscan log files to a different location than the default as specified.
/Reset	Removes the client side settings and files (leaves log files intact if you want to delete the log files as well you can simply delete the ProgramData\Vulscan directory)
/Clear or /ClearScanStatus	Will clear the scan and repair status for the client on the core server (blanks out the history)

Ivanti Endpoint Security Related Commands

Ivanti Antivirus related commands

Shortcuts to open folders or logs:

Vulscan switches used for content replication

2016.3 SU5: Why do some patches appear with the word "DETECT" in the name and why aren't they downloadable?

LDMS introduced SSL Validationfor Client Certificates when communicating with the core via Vulscan. This can sometimes cause errors when clients attempt to verify using the Client Certificates its been given.

This issue is often caused by those who have upgraded their core to 2016 from an older version, or a side-by-side installation with a database import.

Issue

Vulscan hangs on "Contacting Server..." and never proceeds:

Troubleshooting

In order to identify if Vulscan is failing due to Certificate issues, a number of items can be referenced/tested on the Core and Clients.

Disable Client Certificate Validation for WSVulnerabilityCore

1. Open Internet Information Services (IIS) Manager on the core.
2. Drill down to WSVulnerabilityCore under Core Name> Sites > Default Web Site.
3. Double-Click SSL Settings.
4. Set Client Certificates to Ignore and click Apply.

   After this change has been made, attempt to run a vulscan on the client machine. If successful, then the issue is indeed involving Client/Core Certificates.

Reference Core Logs

Logs under C:\inetpub\logs\LogFiles\W3SVC1 can be reviewed for HTTP status return codes when workstations attempt to contact WSVulnerabilityCore.

2016-08-26 19:23:34 10.25.26.50 POST /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 358
2016-08-26 19:23:34 10.25.26.50 POT  /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 358
2016-08-26 19:23:34 10.25.26.50 POST /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 421
2016-08-26 19:23:34 10.25.26.50 POST /WSVulnerabilityCore/VulCore.asmx - 443 - 10.25.26.55 Microsoft-ATL-Native/11.00 403 16 2148204809 405

Things that can be derived from this information:

• IIS is returning a 403.16 Status Code which indicates "Client Certificate is Untrusted or Invalid."
• There is also return code 2148204809.This translates to HRESULT 0x800b0109, which is defined by Microsoft as CERT_E_UNTRUSTEDROOT.

Reference Client Logs

ProxyHost.log under C:\ProgramData\LANDesk\Log on the client will show errors when attempting to reach WSVulnerabilityCore.

2016-08-26 18:49:28(5144-148) proxyhost.exe:IsProcessSigned succeeded - returning: 1
2016-08-26 18:49:28(5144-148) proxyhost.exe:Made direct (non-proxy) connection to LDCORE2016:443
2016-08-26 18:49:28(5144-148) proxyhost.exe:Call UpdateCSAROIFile() with numberofDirectConnectSuccess = 1 numberofDirectConnectFailure = 0  csaName =  bCsaSuccess = 1
2016-08-26 18:49:28(5144-148) proxyhost.exe:127.0.0.1:57652 Connection close 0 0 0 0
2016-08-26 18:49:28(5144-148) proxyhost.exe:127.0.0.1:57652 - - [26/Aug/2016:11:49:28 -0800] "POST http://LDCORE2016:443/WSVulnerabilityCore/VulCore.asmx HTTP/1.1" 403 651 469

• ProxyHost verifies what is already known - a 403 is returned when attempting to reach WSVulnerabilityCore from the client.

Cause(s)

As the resolution for this issue isn't reserved to one cause, a few things will need to be verified:

Verify Core Certificates in the Trusted Root Authority Folder

According to this Microsoft KB Article, any Non Self-Signed certificates installed in the Trusted Root Certification Authority certificate store on the IIS Server may cause an error when users attempt to authenticate when using a Client Certificate.

Non Self-Signed Certificates will show in the CertMgrtool as having different information in the "Issued To" and "Issued by" columns.

You can easily determine if this folder contains any non self-signed certs with this PowerShell command:

Get-Childitem cert:LocalMachineroot -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\certlist.txt"

This command compares the "Issuer" property and the "Subject" property of each certificate in the store and then outputs details of certificates that do not meet the criteria of a self-signed certificate to c:\certlist.txt.

Remove any Non Self-Signed Certificates in the Trusted Root Certification Authority Folder, if found, and attempt running Vulscan again. If the issue persists, continue to next steps.

Verify Core Certificates and Keys in the Shared Keys Folder

The certificates in the C:\Program Files\LANDesk\Shared Files\keys and/or C:\Program Files (x86)\LANDesk\Shared Files\keys need to be valid and not expired as well. You can double-click the .CRT and open the .0 file in notepad to verify the information:

If there are expired certificates in that folder, back them up and remove them from that folder, including any keys and .0 files associated with that cert.

Verify Client Certificates

The certificates on the clients will need to be checked in this issue. Certificate information on the client is stored under C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs.

In this directory, there are usually one to several ".0" certificates. Its possible one or many of these certificates are not trusted by the core, causing the issue. To verify each certificate:

1. Make a copy of each ".0" certificate in a separate location.
2. Change the extension of each certificate to ".crt" and double-click on them.
3. Verify that the LANDESK Trusted Certificate they correspond to exists within the Trusted Root Certification Authority on the core.
   

If a ".0" certificate(s) is found to correspond to a LANDESK Trusted Certificate that does not exist within Trusted Root Certification Authority:

1. Remove the offending certificate(s) from the C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs directory, leaving only the "good" certificates.
2. Delete the contents of C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker. (This folder contains the Broker Certificate, which is the certificate used when communicating with the core).
3. Run "C:\Program Files (x86)\LANDesk\LDClient\BrokerConfig.exe /r" on the client CMD Window. This will generate a new Broker Certificate.

Attempt running Vulscan again. If all steps have been correctly followed, Vulscan should successfully verify with the core and begin scanning.

Resolution

If the issue was found to be a client-side issue, a couple of more steps will need to be taken in order to fully resolve the situation. One of two options can be executed:

Import "Old" LANDESK Certificate into the Trusted Root Certification Authority

If a ".0" certificate was found on the client that didn't correlate with a trusted LANDESK Certificate on the core, its likely due to the client being managed in the past by a core that has since been decommissioned.

The LANDESK Certificate(s) from the old core can be imported into the Trusted Root Certification Authority on the core. This will enable the clients to validate with the core using their existing certificates, provided its the right certificate.

If for whatever reason this is not an option, move on to the next step.

Update Client Certificates to Match Core

Changes will have to be made to the LANDESK Agent Configuration in order to ensure that clients aren't attempting to connect to the core with Untrusted Certificates.

This is configured through the Client Connectivity Agent Settings on the Core under Configuration > Agent Settings > Client Connectivity.

Ensuring that the correctly configured Client Connectivity Settings are included in the Agent Configuration will ensure that all future agent installs will get the correct certificates.

There are a couple known methods to address the existing clients that already have the untrusted broker certificate on them:

Reinstall agent with updated Client Connectivity Settings

• Since Vulscan is not able to connect to the core, reinstalling the agent will ensure the new Client Connectivity Settings are applied to the client and new Broker certificates are generated.

Use a script/batch file

• A script or batch file can be used to clear out the contents of the "certs" and "broker" directory. It can then download the correct ".0" cert and run "brokerconfig.exe /r."
• This script/batch can be deployed via LANDESK Software Distribution. For more information on deploying Batch Files, please see this Community Document.

Check Default Web Site Bindings

The Default Web Site configured by the LANDESK install will utilize the LANDESK Secure Token Server SSL Certificate for the Site Binding within IIS. This is the recommended configuration.

To verify the SSL Certificate being utilized, open Internet Information Services (IIS) Manager and go to CoreName> Sites > Default Web Site.

From there, click Bindings.

This will bring up the Site Bindings window. Highlight port 443 and select Edit.

In the Edit Site Binding window, the SSL Certificate: dropdown will show the currently assigned binding. Click to expand the dropdown list and verify there aren't any Untrusted Certificates in the list.

• Note: Ignore the WMSVC, LANDESK Secure Token Server and LANDESK_CommandsWS here.

If there aren't any Untrusted Certificates found in the drop-down, the Site Bindings are good. No other work is needed here. If there are, a couple options are available.

(1) Remove the Untrusted Certificate from Server Certificates

This is the recommended resolution to this issue as it ensures simplicity and eliminates the possibility of old certificates becoming a problem again in the future.

Open Internet Information Services (IIS) Manager and select Corename. Under the IIS section, double-click Server Certificates.

Within the Server Certificates window, select the Untrusted Certficate(s) and click Remove and select Yes when prompted.

Run IISReset in an Administrator Command Prompt on the core and Re-attempt vulscan to verify the issue is resolved.

(2) Install the Untrusted Certificate in the Trusted Root Folder so it is Trusted

If a copy of the Untrusted Certificate shown IIS is available, it can be imported into the Trusted Root Certification Authority folder so it becomes Trusted.

LANDESK Certificates exist under C:\Program Files\LANDesk\Shared Files\keys on the core by default. They may have been moved to other directories by users for various reasons.

Right-click the currently Untrusted Certificate and select Install Certificate. Follow the configuration detailed below:

Re-attempt vulscan to verify the issue is resolved.

Overview

The Ivanti EPMpatchengine allows binary updates through definition downloads. At times it is necessary to make changes to some of the binary files to remediate issues.

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

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

We will update the list before every expected change to binaries. However, in some cases more urgent fixes are required, and in such cases, we will post the change to this list a short time after the release.

Updated Binaries