Quantcast
Channel: Ivanti User Community : All Content - Patch Manager
Viewing all 1121 articles
Browse latest View live

Custom Vulnerability to Find and Remove AppX packages on Windows 10 - Good or Bad idea?

$
0
0

I've been trying to find a way to remove unwanted AppX packages from our Windows 10 devices.  This has become a problem after our Branch upgrade to 1709.  Until now, we just removed the unwanted packages during imaging.

IEM doesn't really inventory AppX packages, so I've been looking for a good way to find and remove the unwanted apps.

 

Side note, I've put in a feature request to inventory AppX packages.  Please vote on it

 

Originally I tried to have a query find the packages but the only way was to comb through the Package Path data.  These queries ended up being so time consuming that they just didn't work when using them with a task.  The next idea I've had is to write a custom patch to detect and remove.  So far, it looks like it's working very well.  I have one master patch with one Rule per AppX package.  I've exported it and hopefully I can attach it to this post.

 

The only thing I'm not sure about is the detection logic that checks to see if the patch has been installed.  Since my logic for detecting if the patch is needed is a custom script, I don't really know how to do this.  The only options are reg or file detection.  Neither of these will work.  The patch does work, but I want to make sure that not having the patch installation detection logic won't bite me later.

 

Also, I hope others will find this useful.  As a work-around, we're blocking the apps with AppLocker in Group Policy. However, we'd still like these apps removed.


Push a real "forced" reboot

$
0
0

I'm using Ivanti Patch for Windows Servers Standard 9.3.  I'm aware of the reboot option when installing patches but it seems to try to do a safe reboot.  What I mean by this is if you opened a run box and typed:

 

shutdown /r

vs

shutdown /r /f

 

We're using some old computers with windows 7 and if I need to remotely reboot one I've had better luck with shutdown /r /f.  Sometimes the computers will hang trying to shut down if I don't use the /f.  Is there any way I could essentially use the /f switch in Ivanti?

New to Patch and compliance

$
0
0

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

 

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

 

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

How to turn windows updates off

How to patch Office 365

$
0
0

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)
o365downloadupdates.jpgupdates.jpg

 

Updating Definitions (MSO365)MSOFFICE 365 (Vul_Defs)MSO365 (Vul_Defs)
MSO365.jpgMSo365Def.jpg

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

 

2017-10-18_1747.png
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):

There is no Channel support for Office 2013

 

PlatformsDeployment Tools
o365Patform.jpgo365Utility2016.jpg

 

The following channels have changed:

The Current Channel is now the Monthly Channel.

The Defferred Channel is now the Semi-Annual Channel.

The First Release Deferred Channel is now the Semi-Annual Channel (Targeted) Channel.

 

Please see Manage Office 365 ProPlus updates - Configuration Manager | Microsoft Docs  for reference.

 

ChannelsOffice 365 (2013) Product List View
o365_2013.jpgo365Channel.jpg

 

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.

 

 

    STARTo365.jpg 

 

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

 

If you have both 2016 and 2013 products in need of patching, the download has to be completed separately.

 

Office365Tool
Deployment Tool Options
oToolOverview.jpgoToolBothPlats.jpg

 

2016 Content2013 Content
2016View.jpg2013View.jpg

   
      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.

iis.jpgexplorer.jpg

 

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.

 

Sources.jpg

 

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

 

variable.jpg

 

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

 

2016.jpg

 

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

patching windows to 1709

$
0
0

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

Agent Health Dashboard: Total vs. Enabled

$
0
0

EPM 2017.3

Hello, I would like to create a dashboard on the total of devices vs. the tatal of devices with Agent health Deployed. My goal if to have 100% of devices to have Agent health enabled.

I found this: How to create a chart for LANDESK Agent Health in the Dashboard?

But this shows definitions related to Agent health.

 

Any help is appreciated,

Best.

AIX Patch Process

$
0
0

Hi, Can anyone help me on how to determine the patch process for AIX? It needs also a patch repository or can directly download on the core server?

 

Thanks.


Next Gen: Why the Delta vs Cumulative Update is Offered for Windows 10

$
0
0

Purpose

 

This article explains how our detection the Delta or Cumulative version of the patch is offered.

 

Description

 

Our detection logic will verify the  'UBR' value from the registry to determine if the Delta or the Cumulative update will be offered.

HKLM" Key="SOFTWARE\Microsoft\Windows NT\CurrentVersion" Value="UBR" (Update Build Revision)
  • The Delta is offered if build version equals N-1. (N= Latest Build. Current build being offered minus one version level)
  • The full Cumulative update is offered if build version is N-2 or less.

 

You will only be offered one or the other and never both.

There are instances where you may have the latest patch installed but you are still offered the Cumulative patch instead of the Delta. This is because you may have also installed the latest non-security update it causes only the Cumulative to be applicable.

We base our detection on what the installer will allow. We open the installer, and inspect Microsoft's logic. For the deltas, they specify that the delta only applies to exactly one UBR version, and that UBR version is the previous month's security update. You'll also notice that they only offer deltas alongside the monthly security update. They don't offer it with the non-securities.

 

 

Related Documentation

 

Windows 10 release information

Ivanti2017-3_SU5-client.zip does not exist

$
0
0

just like the title folks ... the other three files downloaded automatically, but this one errs out. log of manual download attempt below.

 

Verifying access to site US East Coast (https://patchec.landesk.com)

Verification complete

Attempting to download 1 patches

Failed to download file Ivanti2017-3_SU5-client.zip

Trying alternative source at patch.ivanti.com

Failed to download file Ivanti2017-3_SU5-client.zip

File https://patchec.landesk.com/LDPM8/ldvul.php?KEYWORD=filename&FILENAME=patches/Ivanti2017-3_SU5-client.zip does not exist

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

Failed downloading 1 or more patches

How to I update/patch Adobe Creative Cloud products?

$
0
0

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

 

I have a handful of computers that need it.

patching to Windows 10 - 1803

$
0
0

I wanted to share a bit of behaviour I noticed with the service pack definitions for Windows 10 1803.

 

I am currently testing an update process for moving our clients from v1709 to v1803. We have a multi lingual environment, so I have created a custom definition using a clone of the standard patch W10V1803 definition in Patch Manager.

 

I have customised my ISO image by adding the language packs we require in our build using DISM. I then tested the upgrade by mounting the custom ISO manually and then using the standard setup commands as included in the patch definition, minus the /noreboot switch:

 

setup /auto upgrade /quiet /dynamicupdate disable

 

Every time I run this patch manually on a client it works first time.

 

However, when I try to push the patch out using the custom definition (bearing in mind the script has not been modified from the original W10V1803 definition) I am getting very intermittent results. In many instances, the update appears to run but when the system reboots, nothing happens and it just reboots back in to Windows 1703 with no error prompts or failed update warnings. As far as Ivanti is concerned, I am getting a report that the patch has been successful.

 

On further investigation I have found that the definition script appears to be finishing before the upgrade has actually completed, causing Ivanti to request a reboot. I monitored one client and could clearly see that the setup.exe and setuphost.exe files were still running in the background.

 

I notice in the definition there is a time out script:

 

Option Explicit

Sleep 1800*1000

SetRebootRequired

ReportRepairResult True, "Restart successfully."

 

I am guessing I will need to modify this script, but I am curious does anyone know why this is included in the definition?

 

 

 

Mozilla FireFox ESR

$
0
0

Good Morning, We currently have a vulnerability for FireFox ESR 52.8.1 in our environment and to mitigate it I published ESR 60.2.0. SCCM shows the machines as compliant with a successful install of the update. However after a Tenable scan and a check of the machine the vulnerable version is still installed. I launched FF and was going to let it update itself but it said that 52.8.1 was the up to date version. Has anyone seen this or know what might be causing the issue? Thanks in advance for the help we have never really had an issue out of FF updates and can't seem to figure out what is causing it to not update.

 

Thanks,

Chris Watson

Patch Definitions with Detect in the name

$
0
0

Problem

Patches are being detected as Vulnerable but there is no associated patch to download and remediate

 

Example of Affected patch(s):

MS18-06-W10-4284880

 

Solution

Ivanti has released a DETECT_ONLY definition that will show it is vulnerable on the applicable systems. Being a detect only definition is informational only and cannot be used to repair the system. In order to repair the system there are prerequisites that must me met before attempting to repair the  DETECT_ONLY definition. The prerequisite can usually be found in the properties of the DETECT_ONLY definition in the description. Once the prerequisite has been met the standard definition will be offered.

 

Ensure that the prerequisite has been met.

 

In our example If KB4132216 has been installed then we will detect MS18-06-W10-4284880 as missing, if KB4132216 is not installed we will detect MS18-06-W10-4284880_DETECT as missing so you know the vulnerability is present but it cannot be remediated  until the prerequisite is met.

Detect.PNG

Ivanti2017-3_SU5 detected number not going down despite successful patching

$
0
0

had an earlier issue with one of the downloads for this not downloading, downloaded it manually fixed that, but now, even though a vast majority of the installs show as successful and I have done reboots and rescans, the affected machines still show as detected even though they were patched.

 

just looking at the history, the reason for those machines is "the client file rainstall.exe is below the minimum version"


Scanning a Virtual Machine with 2 IPs (NIC)

$
0
0

Hi All,

 

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

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

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

 

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

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

 

Thanks in advance.

How to set up a dark network Core Server (without outside network access)

$
0
0

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

 

 

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

 

Note: Due to current changes to the Ivanti Patch and Compliance Definitions, the Dark Core will need to have period access to the internet.  If you do not have periodic access to the internet, please follow only Step Six and then the steps in "Additional information for Dark Cores with no internet access"

 

This issue is being reviewed by our Development team and more communication will follow.

 

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".
      SelectCategories.gif
    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.

    EditXML.gif

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


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

 

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

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

 

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

 

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

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.

 

If you are using a 2017.x or newer you will need to import the Landesk Secure Token Server from the light core to the dark core

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

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

LightCoreCert.PNG

     3. Export this certificate.

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

CertImportedToDarkCore.PNG

 

    

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.

Error: "signature is not valid" when tring to download patch defintion throught patch manager

$
0
0

Description:

When trying to download updates for definitions through Patch Manager, the  errors as below is given:

license.png

 

 

As the verification option is now greyed out and enabled by default, we could not uncheck this verification to ignore this.

vertification.png

 


Reason:

Can't get to the site http://Cacerts.digicert.com to download the certificate from core server

The website was blocked

 

Resolution:

Check if Internet Explorer Browser Security setting block the certificate downloading

Check if local network firewall block the target address

How to Effectively open a patch related Support ticket

$
0
0

Introduction

When facing a Patch Manager issue while using Endpoint Manager there are a few tips you can follow to make it as effective as possible and reduce the amount of time it takes to resolve a support ticket. Providing accurate and detailed information can help your support engineer identify and resolve a patching issue quickly and efficiently. This document will outline best practices on how get all the necessary information to fixing patch related issues. Also, the hope it can provide some information to our customers to identify issues on their own.

 

Quick reference for support tickets:

Log.zip - Support will request the full 'Log' folder located on the client C:\Programdata\Landesk. For more effective logging and information see the Logging section

Vulnerability ID(s) - If we are dealing with a specific patch, having the Vulnerability ID(s) will help support identify the problem patch faster without the need to inquire for that information. When dealing with 10+ vulnerabilities provide 2-3 examples.

The behavior of the patch when manually run outside the Ivanti product - This is important to know the behavior outside the product to know the expected behavior the OS takes. You'll want to inform the engineer of this behavior.

The following sections are for information and self troubleshooting. When opening a support ticket the support engineer will require for the information in the Quick Reference.

 

Logging

Logs are the most important information you can sent your support engineer when opening a ticket. This gives detailed information of the patch process so you or the support engineer can identify the cause of the issue. There are a few things to keep in mind when raising a ticket with support.

 

Vulscan.log - Make sure that the issue resides in your vulcan.log(s). You'll want to make sure the issue resides in those logs in order for support to follow the process flow leading up to the failure and completion. It is important that, if possible, the vulscan process completes this provides a return code support can use to identify the general issue. For more information on return codes take a look at About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes. It is always a good idea to send logs from a client that has very recently been able to replicate the issue.

 

STDeployerCore.log - Since the introduction of our Next Gen patches this log has been added to identify the results of the patch installation attempt. One of the most important pieces of information contained in this log is the windows return codes that the client returned when attempting to install the patch. If a patch is failing this is an excellent place to start in determining what reason for failure is. Here is an example of a unsuccessful patch install

 

2018-07-16T10:41:08.0014620Z 044c V UnScriptedInstallation.cpp:30 Executing (C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows10.0-kb4343669-x64-1803_tw15004-40546.msu /quiet /norestart), nShow: true.
2018-07-16T10:41:11.2981195Z 044c V ChildProcess.cpp:140 Process handle 00000730 returned '2149842967'.
2018-07-16T10:41:11.2981195Z 044c W DeployerImpl.cpp:106 Patch state is 'Failed'. Registry bread crumb patch state not updated.

 

Here you can see '2149842967' this is the windows return that the patch returned. A quick web search will assist you in determining what that return means and how to handle it. In this example it is a return of 'Not applicable for this machine' this is a detection logic issue from Ivanti and should be brought to the attention of support. It is helpful to run the patch manually to see if you get a similar result, support will want to know this.

In some/most cases if the OS fails to install the patch outside of the Ivanti product then it may be an issue with the OS and not Ivanti. You'll need to use your own discernment when it comes to this. If you're not sure, support will be able to help you.

Your Support engineer may request other logging if they find it applicable.

 

Helpful Links:

About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes

System Error Codes | Microsoft Docs

How to create a basic Repair task using EPM

$
0
0

Purpose

The purpose of this document is to teach you how to create a simple repair tasks using Ivanti Endpoint Manager, formally Landesk. In some situations you may find you have an employee or yourself who doesn't have the training or knowledge with the product enough to perform a basic repair task on a specific vulnerability when asked to. This document is a step by step guide to create a single repair task for one or more vulnerabilities.

 

 

Assumptions

If you are reading this they it is assumed that your licensing and vulnerabilities are already setup and you are ready to repair a client. You also know the name of the vulnerability that you are wanting to patch.

 

For additional information on assumed expectations please visit these links:

How to get Started with Patch and Compliance Manager

About Ivanti EPM Distribution and Patch settings

 

 

Step 1: Creating the repair task

The first step to creating a repair task is locating the patch in question. Once the patch you desire is found simply right click on the vulnerability and select "Repair..."

repair.PNG

 

Selecting this will bring up the scheduled task window where we configure the parameters for the task.

You can select more than one patch at a time.

Step 2: The Scheduled Task Window

In this step I will go over a basic overview of the settings for a simple repair task, I will not go to far into detail. For and in depth understanding of the different options and configurations selecting the "Help" button at the bottom of the scheduled task window will give more information on what those options do or visit our community for more information. I will make important notes for settings to be aware of.

 

Repair settings

This is the first window that you'll see when the window opens. This contains options to add target clients, overrides to the Preferred Server and Maintenance windows. This is also where you can name the task that is about to be created.

"Ignore maintenance window if specified" This is an important setting to take note of, if your client fails the repair with a 491 "Deferral until next maintenance window." Selecting this option will bypass that maintenance window and attempt the repair.

For this example we are going to leave everything here blank. We are also going to leave the name of the task as the default name.

window 1.PNG

 

Task Settings

Next you'll see Task Settings, it is here you will see the Task type, Action type (Opens Portal settings window), Frequency, Additional Push options, And Download option.

 

Task type: This will change how the task will interact with the clients.

Frequency: This will change how often the task will run.

Additional Push options: These are additional parameters the task will apply to the task.

Download options: Changing this option will allow for different methods of download and execution for the task.

 

For this example we are going to use the default settings

window 2.PNG

Portal settings

This is an optional setting, for more information please visit our community on Portal Manager here.

 

Agent Settings

This is one of the more important windows in the process. Here you will configure the Distribution and Patch and Reboot settings the task will use. Configuring these will alter how the task behaves when it comes to scanning and reboots.

 

You can alter what setting is used by selecting where it says "Keep agent's current settings" this will bring a drop down that will allow to you to select which setting will be used for the task. Keep agent's current settings refers to the setting that is applied to the client by default. After selecting an alternative setting you can select "Edit.." to look more in depth at what that particular setting and it's behavior.

 

For the example I will use the default settings.

window 3.PNG

 

Definitions

 

This window gives an overview of the definitions that have been selected for the task. There is nothing to change in this window so we can move on.

window 5.PNG

 

Patch list

Here you will be able to get an overview of the list of patches that will be used in the task. Looking at this you can double check the amount of patches and download status of the patches. In this example, I have not downloaded the patches yet as indicated by the "Downloaded" column. I know I am able to download because the "Can Download" column indicates that I can.

 

I can download the required patch by highlighting the patch and this will allow for the "Download" button to become available. Selecting this option will download the patch.

There are other methods to downloading the patch, we are using this option as an example.

window 4.PNG

 

Targets

Here you can assign what clients will receive this task. There are many options to choose from which option will depend on the method of choice. Most of these options are for groups that once the specific group or query is selected for the task it will pull all clients in those groups into the task.

 

Targeted Devices: Selected individual clients in the environment.

Targeted LDAP objects: Clients that are associated with an LDAP objects.

Targeted queries: Clients that are assosiated with a custom built Landesk Query.

Targeted LDAP quries: Clients that are assosiated with an LDAP query.

Targeted device group: Clients that have been placed in a custom device group in the Network View.

Targeted scopes: Clients that have been placed in a scope in the network view.

Targeted email addresses: Clients who have had an email address associated with the machine.

Targeted time zones: Informational only. Displays clients time zone as well as how many of those clients in that zone.

 

Simply select the option you want and press "Add" this will bring up a list of options available that fall under that particular group.

For this example I have selected Targeted devices. Notice the PC "Elexi" under Targeted Devices.

window 6.PNG

There are other methods to adding clients to the task, such as dragging the clients into the task from the Network view right on top of the task in the Scheduled task window.

 

Schedule task

Now that we have our clients selected and the task configured it is now time to schedule it. Here you are given 3 options, Leave unscheduled, Start now, and Start later.

 

Leave unscheduled: This will leave the task unscheduled for you to either come back later to reschedule or for you to manually start later at a time that works best.

Start now: Once the "Save" button is selected the task will begin processing.

Start later: Allows you to schedule it to start the task at a specified time. This has additional options for clients in different time zones as well the option to make it repeat at certain intervals.

 

For the example we will leave it unscheduled.

window 7.PNG

 

Step 3: Launching the task

Now that we have the task configured how we want, and assuming we haven't already started it, you will see that the application has taken you to your scheduled tasks window. Here you can monitor the status of the task. The display shows 4 different statuses, Active, Pending, Successful, Failed. When a task is left unscheduled the clients will be in a pending state. In order to launch the task from the console simply right click on the task and select "Start Now" this will give you options on what you want to start we are going to select "Devices that did not succeed." From there the task will start and Endpoint Manager will do the rest. The console will periodically update with it's status.

 

window 8.PNG

 

Now that the task is started, simply wait for the return which will display. If it is successful congratulations you just launched your first repair task. If you're getting failures, take a look at the pane on the right side and it will give a brief report of the reasons for failure in the form on an associated return code. Some may require Technical Support to assist you with but our community is full of troubleshooting steps.

 

Useful Links:

Ivanti Endpoint Manager and Endpoint Security - Security and Compliance Frequently Asked Questions

How to Effectively open a patch related Support ticket

How to use Reboot Settings

About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes

Viewing all 1121 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>