Hello -

I am having one query related to Autofix. As shown below,when I Autofixed the chrome patch its showing multiple entries on a single machine. Anybody have idea about it?

Appreciate your response.

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

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

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

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

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

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

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

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

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

INTRODUCTION

The detection logic of a vulnerability can be based on Files, Registry Settings and Custom Script.

Using Custom Script in the detection logic will extend the detection capability: instead of only looking to files and registry you can, for example, query the WMI or match more complex conditions.

DESCRIPTION

The custom script language used for Microsoft Windows platforms definitions is VBScript.
The VBScript used in the vulnerability definition is VBScript 5.5. Some functions and procedures (Sub) as Log and Report are internally defined (pre-defined) and they are not native part of VBScript 5.5 specifications.

The scope of the Detection Logic section is to decide it the device is affected or not and report back to the Core Server this information optionally supplying a reason as well why it was found vulnerable.

There are two procedures (Sub) predefined in the VBScript engine used in LANDesk:

• Report
  

  Sub Report(Boolean IsVulnerable, String Expected,
  String Reason, String Found)
• Log
  

  Sub Log(String LogString)

  *VBScript is not a 'strongly typed' language but the definition used above is only to clarify the data type to use for the parameters.

Report will report back to the core server if the definition applies or not.

It accepts four parameters and all of them are mandatory:

• IsVulnerable: is a boolean value. It is set to True the vulnerability has been detected, it is set to False the vulnerability is not detected.
• Expected: is a string value. This parameter needs to contains a description of the condition why the vulnerability believes that is detected.
  For example "The WMI property xxx should be at least 3" or "The file alpha.exe version should be at least 3.A.3"
• Reason: is a string value. This parameter needs to contain the reason why the vulnerability is detected
  For example: "The WMI property xxx is minor than 2" orThe file alpha.exe version is minor than 1.K.9"
• Found: is a string value. This parameter needs to contain what the rule found out.
  For example: "The file long.test.exe is version

Example:

Report True, "Expected to find arax.exe bigger then 2Mb",
 "arax.exe is too short", "arax.exe is 10Kb only"

The only parameter that is interpreted by the core server is IsVulnerable. All the other parameters are only string used to give the end user an explanation about the vulnerability findings.

These values will appear in the Affected Computers GUI (right click on a vulnerability that appears in the Detected folder and choose 'Affected computers...' option)

Log will simply write a line of text in the local vulscan.log on the device and can be useful for debugging purposes.

Example:

Log "Vulnerability XXX-KK successfully detected"

CONCLUSIONS

In some particular situations, when the detection of the vulnerability is quite complex (Example: "The last modified date of file xxx.log should not be less than than the last modified date of klmx.dat") the usage of a Custom Script logic will facilitate and greatly enhance the ability to detect complex situations.

NOTE

To have more information on how to use the scripting in the Patch Installation & Removal (repair) section of a Custom Vulnerability please refer to this community article:

http://community.landesk.com/support/docs/DOC-6518

To have more information on how to use the scripting to download a file through a detection or remediation script in a custom vulnerability please refer to this community article:

http://community.landesk.com/support/docs/DOC-6644

Description

This article illustrates how to create a custom vulnerability definition in Patch and Compliance Manager.  Creating custom definitions is not part of the regular support that Ivanti offers, so this Community article will serve the purpose of assisting customers in creating these definitions.

In Ivanti Security and Compliance Manager the ability to create a "user-defined" vulnerability definition provides an extremely flexible and powerful tool that can be used to implement and maintain computers in your environment.

Create Custom vulnerability definitions (and detection rules) to scan managed devices for any operating system, application, single file, registry condition, or use custom VBScript for various conditions to have the client be detected in order to implement various solutions.

Possible implementations

Implementations of the custom vulnerabilities are almost limitless. It can be used to update any application on managed devices. It can be used to apply any single file executable to a managed device based on detection rules defined by the Ivanti LANDESK administrator.

The following step-by-step example shows how to create a custom vulnerability to update or install a fictitious "in-house" application.

Assumptions

The administrator should be able to install the Ivanti Endpoint Manager Core Server and clients.  The core and managed devices should be configured with the latest LDMS version and service pack.

Creating a Custom Vulnerability Definition

Vulnerability Definition Help Page

We will now create the custom vulnerability to detect a condition.  In this case, Iwe will use "File Detection" logic to look for a minimum allowed version of "SuperSpecialInHouseApplication.dll".

1. From the Endpoint Manager on the Core Server or a Remote console open the Security and Compliance tool group.
2. Open the Patch and Compliance tool and click on the Create Custom Definition icon. (Green circle with + in the middle)
   
3. The following window will open which shows the General information for your Custom Definition:
   
4. Enter an ID, Title, Severity, and Notes.  This will show up in your Custom Definitions list in the following way:
   

Detection Rules

1. Under Detection Rules click Add to add detection rules.
   Detection Rule Help
   

   Detection rules define the conditions that will cause the computer to be deemed "vulnerable" or simply needing an update, configuration change, installation of an application, etc.
   Sometimes multiple detection rules are necessary to install patches, make configuration changes, based on conditions.
   A common use of multiple detection rules is when you have separate patches for 32-bit patches and 64-bit patches.

The following Properties for Rule # window will appear.

Give the rule a name, title, and comments as depicted below:

Vulnerability definitions are processed from the top down, and the following detection checks are taken:

Selecting Affected Platforms

Affected Platforms Help Guide

The scanner checks to see if the client is running an affected platform (in this case as defined by the user).
This is the operating system that is running on the client computer.  It is possible to differentiate between 32-bit and 64-bit versions of the Operating Systems, Etc.
The following is an example of the Platform pick-list:

If the client computer is not running an affected operating system all other detection criteria is ignored and the computer is not deemed "vulnerable" as it has not met the first detection criteria.
It the client computer is running an affected operating system (platform) the scanning will continue to "Affected Products".

Creating a custom Affected Product

Affected Products Help

The "Affected Products" check is to see if the Product exists on the client computer.  This is a top-level criterion, and will typically check for the mere existence of a file or registry key associated with the product.  Sometimes a VBScript is used.
If writing a custom definition for a product that is already in the EPM database, you can simply click "Configure" and select that product.
Otherwise, in our case of writing a custom definition for "Super Special In-House Application" we will create a new Product based on file detection of "SuperSpecialIn-HouseApplication.exe".

1. Click "Configure" in the Properties for Rule # properties window.
2. Click Add and file in the ID, Name, Vendor, and Version information (as applicable)
   
   Creating a custom product or selecting an already existing product adds another level of detection making other detection processes later in these steps more flexible.
   For example, if the scanner doesn't detect that Super Special In-House Application is installed it will leave the detection process.
3. Move down to the "Files" section of the Detection logic and enter SuperSpecialIn-HouseApplication.exe (or of course your filename you are concerned with).
4. Enter in a range for the Minimum Version the file has to be and the Maximum version.  In this case, we will enter 0.0.0.0 for Minimum version, and 99.99.99.99 so that any version found will be applicable.
5. Click OK to save the newly created Custom Product.
6. Now that the Product has been created, it will need to be included in the Rule.  Select the new  Product from the bottom pane of the Select Affected Products window and then click on Include to move it to the Affected Products pane.
7. Click OK.

Query Filter

Now move down to the Query Filter section.  All detection fields are optional.  Typically the Query Filter pane is used to include or exclude clients from the detection based on EPM queries.
An existing query can be selected or a new query created.  For our example, we will not use a Query Filter.

Files Detection Logic

Files used for detection help

Registry settings used for detection help

Custom script detection help

1. Move to the Files pane. 
   Our example will use "File Version" for detection.  However, there are various methods of detection that exist file Files detection:
   
2. Since SuperSpecialIn-House.dll is used in our detection process, and our new file is version 1.5, we will check to see if anything older than 1.5.0.0 exists.  Note that the top of the window says "Detection will occur if any of these conditions are not met".
   Several different criteria can be added (stacked up) in the File detection section.  If any one condition is not met, the computer will be deemed vulnerable.  However, typically only one criterion will be added here.
3. For path, you can enter in a static directory and filename (C:\Program Files (x86)\SuperSpecialIn-HouseApplication.dll) or use variables.  In order to use variables, right-click the FILEPATH entry and you will be presented with variables that can be used.
   
4. In Min version enter "1.5.0.0".  This will indicate that if the scanner sees any version of the .DLL that is earlier than 1.5.0.0 (the version of the .DLL in the update to be installed) the computer will be deemed vulnerable.
   Note: For our example, we will not use the Registry Settings detection or the Custom Script detection however, if any combination of detection criteria for all three detection types are not met, the computer will be deemed vulnerable.
   Additional important note: There is an important difference between "File must exist", "File must NOT exist" and "File may exist".  "Must" means that the file needs to exist. If it does not exist the computer is deemed vulnerable.  This is important because if you have not defined a product and are simply using detection criteria, the fact that a file does not exist will cause the computer to be detected to be vulnerable, even if an affected product is not installed.  "May" means that if the file does not exist, that is fine - detection will not happen and the computer will not be deemed vulnerable.  However, if the file DOES exist, the detection criteria must be met, in our case the file must be at version 1.5.0.0 or higher or detection will occur.

Patch Information

Patch Information Help

There are three options available regarding Patch Information:

1. "Repairing this issue requires downloading a patch" is used when you want to install a patch, an upgrade file, or an application.
2. "This issue can be repaired without downloading a patch" is used when you intend to use scripting, additions/changes to the registry, copying files, starting or stopping a service, etc to "repair" the computer.
3. "This issue cannot be repaired by Security and Compliance Manager" is used when you simply want to use detection only and do not plan to patch, upgrade or otherwise configure the client.

For our example, we will use the "This issue requires downloading a patch".

1. Select "This issue requires downloading a patch"
2. If you have a source to download from, enter the FTP or HTTP address into the "Manufacturer's patch URL:" section.
3. Select "Auto-downloadable" and set it to "Yes".  If the patch is not downloadable, the patch file will need to be placed in the default patch location.  (Also see this document: How to change the default Patch Location for Security and Patch Manager)
4. Each file that is installed by Patch Manager must be given a unique filename when it is downloaded.  This filename can differ from the original filename that existed on the source for the download.  Enter in a unique filename or the existing filename if manually copying the file into the default patch location rather than downloading from an FTP or HTTP source.
5. Once the file is in place, you will need to generate a hash for the file to ensure that it is secure and cannot be replaced with another file surreptitiously. 
   To do so, click the Calculate Hashes button and you should see the red X's above turn to a green checkmark, you will also see the "File Size" line populated with the file size.
6. If your application requires a reboot, enter the appropriate choice in the "Requires Reboot" section.
7. If your application can be installed silently select the appropriate choice in the "Silent Install" section.
   (Note: These fields are used for purely informational purposes.  The "Patch Install" section of the rule controls the silent switches, and the Distribution and Patch Settings control the reboot options.

Detecting the Patch

Various criteria can be used to detect whether the patch is installed.  Both File Detection and Registry Detection can be used.  This detection criterion is the opposite of the detection criteria to detect the vulnerability.  Note that this section says "The patch will be detected if all these conditions are met, along with all registry and script conditions".    The Detection Logic section says if the criteria is NOT met.  This is an important distinction.  Due to this, the exact same criteria can possibly be used both in the Detection Logic section and in the Detecting the Patch section.

Patch Installation and Removal

Patch Install and Uninstall Help

Stop Processes

If processes need to be stopped prior to your install, update or configuration change, you can list the process name as it would appear in Task Manager in windows.  Several entries can exist.

This will cause any of these processes to be "killed" (stopped) prior to the patch install actions.

Additional files

This will allow you to specify additional files that will be downloaded to the client along with the main file that is listed under the Patch Information section.    Enter the HTTP and/or UNC path, then click the blue arrow to browse to that location and then select the file(s) you wish to include from the "Available files" listing. After adding the files you will be presented with options to hash the files.

Patch Install Commands

Various combinations of actions can be added to the Patch Install commands section:

   
These actions will be run in the order that they are listed.  You can re-arrange them with the Move Up and Move Down buttons after they are entered.

As in other areas of the Rule properties, variables can be used, this is typically displayed by right-clicking an appropriate field such as "Path".

Patch Uninstall Commands

Path uninstall commands are the same as the Patch Install commands.  A combination of actions can be defined to uninstall a patch, undo a configuration change, etc.

Tips and Tricks

In order to see examples of vulnerability definitions and rules, you can right-click any existing definition (custom or not) and select "Clone".   This will create a duplicate of the definition that will show up in the Custom Vulnerabilities category and can be edited.

This is a great way to learn how to create detection logic and installation commands.

• Question
• Answer
  • Change Client Cache (SDMCACHE) Retention Period

Question

How can I push a large patch out to my different locations and force the clients at those locations to use a locally cached copy and not download the file from the core?

Answer

You can use the staging task which is part of a repair task to first push the patch to a specific number of computers. Then push the repair task to all of the computers with the "Download patch only from local peers" option selected.

The following assumes that a full vulnerability scan has been run on the clients you wish to stage the patches to.

1. Open the Ivanti Endpoint Manager Console
2. Go to Tools | Security and Compliance | Patch and Compliance
3. Change the selected types in the top left to "All Types" if you wish to view all detected vulnerabilities in any category, or select another type if you are only staging and repairing for a particular vulnerability type.
4. Click on theDetected folder
5. Ctrl-Click or Shift-Click the desired definitions
6. Right-click on the definitions you wish to deploy the patches for.
7. Select Download associated patches.
   
8. Make sure that you have the patch(es) downloaded.
9. Close the window
10. Select and right-click on the vulnerability definition(s) you wish to repair.
11. Select Repair.
    
12. Select Task Settings in the left-hand pane.
13. Select the "Pre-cache (download for a future task or portal initiated action" radio button.
14. Select Repair Settings in the left-hand pane and then tick the box next to Override Preferred Server / Peer Download options
    • If you wish to allow the computer to download from its local cache or peers, only check the "Attempt Peer Download" option  (Recommended)
    • If you wish to allow download from cache, local peers, and/or preferred server, select both "Attempt Peer Download" and "Attempt Preferred Server"
      

Note: By default a patch that is pre-cached by the method above will only stay in the SDMCache on the local machine for a default of 7 days. If you would like the patch(es) to remain in the SDMCache folder for a longer period of time do the following:

Clients can use their own cache to install files, or their cache is used in the peer-download concept to supply the patches to other computers on the same subnet, thus saving bandwidth and traffic back to the preferred server and/or source.

Change Client Cache (SDMCACHE) Retention Period

1. Open the "Agent Settings" tool under the "Configuration" tool group.
2. Select "Client connectivity" under the groups of settings.
3. Double-click an existing setting to edit, or right-click select "New" to create a new setting.
4. Click the "Download" section in the left-hand pane.
   
5. Set the "Number of days to stay in the client Cache" option to the desired amount.
6. Click OK

Note: Ensure that the computers added to the pre-cache task are vulnerable for the patches included in the task, otherwise the pre-cache process will not work correctly.

Description

How to create a Custom Definition in Patch and Compliance Manager that will check for the presence of a registry setting and make a change if detected.

Example

In our example, we will be detecting for a registry setting that controls the Ivanti Remote Control security type (HKLM\SOFTWARE\Intel\LANDesk\WUSER32 | Security Type)

1. In the 32 bit console go to Tools | Security | Security and Patch Manager
   
   
2. Change the Type drop-down menu to Custom Definition

1. Click the button "Create Custom Definition"
   
2. Enter a definition ID and Title.
3. Click "Add" underneath "Definition Rules" to start creating a rule
   
   
   
4. Click on Affected Platforms and select the operating systems that will be scanned for the definition
5. Under Detection Logic click on Registry Settings and click Add
   

   NOTE: The detection logic will detect vulnerable if the registry setting here is different from what is listed on the machine.

6. Enter registry key information
   

   NOTE: HKLM has already been entered and represents HKEY_Local_Machine. Detection can only take place under HKLM.  For 64 bit devices you may need to check the box labeled "Use 64 bit registry view on 64 bit windows".  This will automatically populate HKLM64.

7. After entering the registry setting click the button Update to commit the change
8. Click on "Patch Information"
9. Under Detecting the Patch click on Registry Settings and click Add
10. Enter the registry setting that will be changed to so you can detect when the change has occurred on a device (Don't forget to click the button labeled Update when you are finished entering the key)
11. Click on Patch Install Commands
12. Click the button labeled Add
13. Select "Write a value to the registry"  (Note: If you want to DELETE a registry key, you can use the Execute a Program option and then put in "CMD /C REG DELETE <Keyname> /v Valuename, etc"
    See Reg delete for further information.
14. Double click the value column by Key and enter the full key path (ie: HKEY_Local_Machine\System\...
15. Enter the value name
16. Enter the value data that you want to write
17. Click OK
18. Click OK
19. Run a security\compliance scan on a computer then verify that the detected column has detected that the computer has detected as vulnerable
20. To execute the custom definition and make the change to the registry create a repair task from the custom definition or set the definition to auto-fix

This article describes how to change the default Distribution and Patch settings.

Distribution and Patch Settings

How to locate and modify the Distribution and Patch Settings

1. Open the Ivanti Endpoint Manager console on either the core server or on a remote console.
2. Select Tools | Security and Compliance | Agent Settings
3. Under Agent Settings  you will select "Distribution and Patch" under "My agent settings" or "Public agent settings" depending on whether you want to create the setting for only you to Manage or if you want it to be accessible to others with the correct RBA rights.
4. Either modify an existing setting in the right hand pane, or right-click the right-hand pane and select "New"

Changes made to a setting that is already set as the default will automatically take affect on the computers next Security Scan. This is the simplest way to globally update your agents with new Settings.

If you would like to change a specific computer or a group of computers settings you will have to create a new setting and then push that change out.

After creating a new Setting you can use a "Change Settings" task to change the default settings on computers.

Change Settings Task

1. Open the Ivanti Endpoint Manager console on either the core server or on a remote console.
2. Select Tools | Security and Compliance | Agent Settings
3. Click Create a Task and select Change Settings.
   
1. Give the task a name and select whether you want it to be a Scheduled Task or a policy.
2. Click on "Keep agent's current settings" to bring up a drop-down menu of available settings.
3. Select the new setting.
   
4. Click "Save".
5. Add computers to the task and run it.

Issue

The PatchHistory table is very large and causing a strain on SQL resources

Solution

The PatchHistory table contains the date/time of each patch installation, removal, spyware removal and Antivirus action that Ivanti EPM Patch and Compliance has performed.  This information can be purged and would not affect your Installed, Vulnerable/Detected data for devices.  This would only remove information from the Clean/Repair History section.

To purge the data that is no longer needed please use the following steps:

1. Ensure you have a recent backup of the database
2. Right click on any device
3. Select Security and Patch Information
4. On the left-hand side select Clean/Repair History
5. Select the Purge History button
6. Select All Computers and select your date range or all records
7. This would remove data only from the PatchHistory table

Or

The DBA can add the following SQL to the Ivanti EPM Database maintenance plan to remove records that are X days old. In the example below, 90 days is used. Modify that value to the desired range.

Ensure there is a backup of the database before running any delete statements.

DELETE from PatchHistory WHERE dateDiff("d",Actiondate,getdate()) > 90

Description

This article describes how to scan and/or repair based on a custom group that has been created in Patch and Compliance Manager

Resolution

In Patch and Compliance Manager, there is the option to create a custom group.

To create a new group

1. Open the Security and Compliance tool group on the Core Server or Remote Console
2. Go to the Patch and Compliance tool.
3. Expand the "Groups" node in the left-hand pane.
4. Right-click on either "My Groups" or "Public Groups" and select "New".
   

Once you have created a new group, you can drag and drop definitions to the group as you desire. Then, in the Distribution and Patch Settings, you can set the job to scan for GROUP as opposed to TYPES, and point it to your custom group.  Once you have scanned against this, you can then REPAIR the entire custom group at once by right-clicking the group in Patch and Compliance Manager and selecting repair.

To create a repair task open Security and Compliance Manager and follow the steps below

1. Right-click the custom group desired
2. Choose "Repair".
3. Set up the desired options (i.e. scheduled task, stage and repair, policy, etc...)
4. Click "OK" to create the task
5. Now drag the machines or query desired into the repair task created (note; the number of all devices will not reflect the results of the query until the task is started.)
6. You can also right-click the scheduled task and choose properties to adjust the behavior and scheduling of the task.

Subject

Error: 'Core could not find a file' when running vulscan on clients.

Description When running a vulscan on the client side, you see an error message "Warning: Core could not find a file" relating to one of the following files:

• Defaults.txt
• agentbehavior_N.xml (where N is a number)
• av_behavior_N.xml
• cv_behavior_N.xml

Cause

1. The file being looked for has become corrupt.
2. The file being looked for is not in the Agentbehaviors directory.

Resolution

Check the vulscan.log file to see which file is missing. Then take the following steps:

**Defaults.txt**

This file should be located in the Agentbehaviors directory on the core. If it is not, you may find a backup under the Landesk\ManagementSuite\LDLogon\Spyware folder. If you do, COPY this file to the LDLOGON\AgentBehaviors directory. If the file does not exist anywhere, you will need to email the customer a copy from your core server or get one from another core in their environment.

**AgentBehavior**

This file is used for determining the behavior of the client when scanning and repairing. Check the AgentBehaviors folder to see if a filename exists that is matching.

-If the file does exist, try running 'vulscan /reset' on the client and run a new scan to see is this fixes the local file.

-If the file does NOT exist, try recreating the behavior file. To do this, go into Agent Configuration, select 'Security and Patch Scan' and at the bottom of the right hand pane, look to see what "Scan and Repair Settings" name is specified. Then click 'Configure'. From the 'Configure Scan and Repair Settings' window that comes up, select the behavior that was listed in the Agent Configuration and click 'edit'. Once in the behavior, change ANY value and click 'Ok' , and then 'Use Selected'. This will take you back to the Agent Configuration. Click 'Save' to resave the agent. If this works, we should now have an Agent Behavior that matches the one we are looking for. Run the vulscan again and see if it works.

-The new agentbehavior still fails, create a NEW set of scan and repair settings and push a Scheduled Update or a Settings Change task.

**AV or CV behavior**

These files should not keep the LANDesk agent from running a vulscan. If these files cause the error, simply create a new AV Behavior and a new Custom Variable Behavior, and push these out via a Change Settings Task. This is done via the Schedule a Task--&gt; Change Settings button in Security and Patch Manager.

*Note on AV Behavior: If you no longer have LANDesk Antivirus installed and the avbehavior_X.xml is missing and the client is looking for the avbehavior vulscan will return an error in the log and the GUI but will complete sucessfully. To fix this error, go into the database, open the AgentBehavior table and delete the row that has the avbehavior listed. Then resave your agent this will recreate the default behavior in the directory and then patch manager will complete with no errors.

NOTE: In some cases, the entire AgentBehaviors folder may be gone. If this is the case, recreate the folder and try the above steps for Agent Behavior replacement. If that does not recreate the files, you will need to create new Scan and Repair Settings and push them via a Change Settings task.

Overview

When selecting a device and select "Security and Patch Information", one of the expected tabs "All Detected" is not displaying any information of detections and scans.

Problem

When looking for the information in "Security and Patch information" the results return back blank or have filtered results for a specific type of vulnerability outside of what is expected. When running a Vulscan it is shown to have detected vulnerabilities but is not showing in the Security and Patch information

Expected	Found

Cause

This is caused by the "Type" selection at the top of the window being set to a different vulnerability typing then what is expected.

Solution

Simply change the drop down from the current selection to the type of vulnerability of your choice.

This option is defaulted to what is chosen in the patch and compliance window "Type" filter. Whichever option is selected in this list is what the type will be when Security and Patch opened.

Hi there,

I'm trying to set a role so the users cannot move patches into various groups/scan folders.  I've set the Security section all disabled, but these users can still move patches to different folders.

Has anyone encountered this as well?  We're running 9.6 SP3.

Thanks.  Mareesa

LDMS 9.6 SP3

CSA

Hello, finishing some tasks here, I have the following questions regarding Patching and Repairs.

1. Will the Distribution and Patch Settings MAINTENANCE WINDOW overwrite the Reboot Settings Time Frame?

For example I have a Maintenance Window on Mondays from 10:00 PM to 11:00 PM but the Reboot is set to Fridays form 5:00 PM to 6:00 PM.

Which one will it use?

2. When using a Maintenance Window and the Task starts, I get this message:

a) Why the Custom header doesn't show up as configured in Branding under Customize Window Caption and how can I remove or disable the Wait until lock or logoff Button?

3. If Agent has AutoFix enabled and I set the Patches to AutoFix, they will be fixit in the Next Maintenance Window as configured, correct?

    ANSWER: Yes, the process will start at the scheduled time, starting with a vulscan then with a repair task.

Thank you.

LDMS 9.6 SP2

CSA

Hello, after testing the patch KB4012213 if I install this manually, it asks to restart the machine. If I push a repair task t does not.

Why? Do I need to send a restart task after patching?

Best

Overview

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

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

Definition Downloads

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

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

Definition Download	Managementsuite \ Ldlogon \ Timber

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

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

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

Content Changes

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

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

Distribution and Patch Agent Setting

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

 

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

 

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

• PatchManifestSyncSDK.log
• PatchScanSDKDpdTrace.log

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

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

Diagnostic Tool

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

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

How Does Scanning and Remediation Work

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

Scanning:

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

 

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

 

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

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

 

Remediation:

 

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

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

 

Logging

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

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

There are no W10V1709 patch definition for latest creator update installation. Is it still not published or is it problem in our ivanti patch manager?

Thank You

Ivan

Hi all

We are currently trying to control reboots on our estate using the LD Agent. Below are the settings...

Some users are reporting that their machines are not rebooting on the scheduled days. I think this is due to the deferral option allowing them to set a deferral longer than the gap between reboots.

Question is - If I change the deferral options to 1 hour will this mean that the forced reboot will happen on time? When we first rolled it out it seemed that the deferral options only set how long the prompt would minimize before becoming persistent on screen.

Can anyone clarify how the deferral and prompt are meant to work please?

Thanks in advance

James

Hi all, looking for some advice please...

I need to exclude a small number of users from deployment of Chrome updates via Patch Manager due to some automated testing they do.

What would be the easiest way to do this? I thought about using a scope but from what I can see it would mean creating a scope including all assets apart from theirs and would rely on our engineers adding in all new assets to the LD group the scope is based on. This will be quite painful and tedious so was wondering if there is an easier way to do this?

Thanks in advance

James

Information

This document outlines using the ROISCAN.vbs tool. This tool offers debugging level logging for patch content related issues. Should an Ivanti technician request the ROISCAN run on a machine, this document outlines how.

Steps

• Download the ROISCAN.zip that is attached to this document and extract its contents
• Within the extracted contents, locate ROISCAN.vbs
• Run ROISCAN.vbs with Administrator rights
• As ROISCAN.vbs runs, it will show a console window

• The tool has finished running when the console window closes
• Once finished, a file will be created: %temp%\{MachineName}_ROIScan.log

Example: "C:\Users\Nevans\AppData\Local\Temp\NEVANS-PC_ROIScan.log"

• Gather the generated log file, and send it to support (typically the best method is by attaching it to your case in the Self-Service Portal)

Issue

While creating a repair task you are getting the error message:

Error: - The statement has been terminated. String or binary data would be truncated.

Cause

The current column length in the Ivanti EPM database is the cause for this behavior.

Resolution

This issue (199611) is addressed in the latest Ivanti EPM Service Update.