What is Patch Supercedence?

Patch supercedence is when a newer patch completely replaces an older patch.  It is usually the best practice to only apply the latest patches rather than all of the patches.  This is mostly due to the time needed to scan for older patches, install, reboot, and re-scan if you were to install all the patches.

Why scanning only for the latest patches is a good thing

It is much quicker and easier to only apply the latest patch that will contain all the fixes in the replaced patches.  In tests, disabling replaced rules has cut the scan time in half.  Another benefit is that you will have fewer patch install failures if you only install the latest patch.  Many Microsoft patches will fail to install if there has been a newer patch installed.

Viewing replaced patch definition rules

To view which patches have been replaced or replace other patches:

• In the LDMS Console go to Tools - Security and Compliance - Patch and Compliance
• Expand Scan
• Click on Replaced

The Replaced group shows patches that have been replaced by a newer patch.

You will see which patch replaces it by looking at the "Replaced by" column.

It is also possible that the replaced patch itself had replaced a previous patch.  You will see that by looking at the "Replaces" column.

For example, in the above screenshot the patch 2661254v2 replaces patch 2661254 and all of it's rules are replaced by MS13-095.

You can move all of these rules to the "Do Not Scan" group and this would be the as effective as disabling the individual rules inside these patch definitions.  Be aware however that the Replaced folder is a subfolder of the Scan group.  Vulnerabilities that are replaced will only show up here if they are still set to Scan status.  If you move them to Do Not Scan, they will no longer show up in the replaced folder.

Partial Replaced patch definition rules

It's also possible that only some of the rules in a definition have been replaced.

To view the partially replaced patches, click on the "Partially replaced" group

In the above screenshot you will see that the "Replaced by" column now says "Some:" instead of "All".  This indicates that only some of the rules in the definition have been replaced.

Viewing rules inside a patch definition

If we double-click MS14-035 it will open and we can view the rules inside the patch definition.

Here we can see the three rules have not been replaced and six rules have been replaced by MS14-037.

Until all the rules are replaced it would be best to leave the patch definition for MS14-035 in the scan group.

Manually Disabling replaced rules

There are two ways to manually disable replaced rules.

First, you can open a definition and right-click on the replaced rule and disable it.

Right-click on the replaced rule and click "Disable Scan"

This will change the Icon on the rule to a red cross on it.

You can also multi-select the rules and disable them all at once.

Using the Disable replaced rules tool

The other way to manually disable rules is to use the disabled replaced rules tool.

Click on the icon highlighted in red.

This brings up the Disable replaced rules tool as seen in the above screenshot on the right.

You can either select patch definitions or have the tool run against all rules.

How To: Use the Disable Replaced Rules Tool in Security and Compliance Manager - Video

Automatically replacing disabled rules

It is also possible to disable all replaced rules when a new patch definition is downloaded.

Click on the Download Updates icon from the Patch and Compliance toolbar.

1. From the Download updates tool, click the "Definition group settings" button.
   
   This will open up the Definition group settings tool.
2. Click on New.
   
3. Set the Definition Type to Vulnerabilities
4. Set Severity to Any
5. On the "Scan" tab select "Assign scan status" and "Disable any rules this definition replaces"
   
6. Click OK.

This rule will cause any replaced rules to be disabled when their replacement is downloaded.  This way the replaced rules are automatically handled and only the latest patch definitions are used.

Microsoft has ended support for Windows XP and Server 2003

LANDESK Software continues to support Windows XP as an LDMS client up until LDMS version 2016.0.  That version and newer do not support Windows XP as a managed client.

Supported Platforms and Compatibility Matrix for LANDESK Management Suite

Information about supporting Windows XP on environments running versions newer than LDMS 2016.0: How to Build a Legacy Agent for Windows XP and Server 2003

What is the LANDESK Custom Patch Content program?

Microsoft Windows XP completed extended support on April 8, 2014 and Windows 2003 on July 14, 2015. Large customers have had the option to purchase custom support for continued security patch updates. LANDESK likewise provides a custom support offering that enables customers to receive patch content to assess and remediate patches received directly from Microsoft.

How does the LANDESK Custom Patch Content program work?

Licensed customers will provide LANDESK with patches for analysis to develop custom content to assess and remediate. Please note that LANDESK does not have the right to redistribute patches from Microsoft’s customer support programs. LANDESK will only provide content for patches that have been submitted for analysis.

This custom support offering enables customers to receive patch content via the Security and Patch Manager tool to assess and remediate patches they have received directly from Microsoft.

How will a customer receive updates for the LANDESK Custom Patch Content?

Upon purchase, customers will receive instructions on how to receive updates for custom patch content.

How much does LANDESK Custom Patch Content cost?

LANDESK Custom Patch Content is licensed per operating system on a 1-year subscription. The cost per licensed operating system is MSRP $40,000.

What type of patches are covered via the LANDESK Custom Patch Content?

Any Microsoft patches related to the purchased customer support program (Windows XP or Windows 2003) that are submitted to LANDESK will receive content.  Upon receiving the required patches and bulletins, LANDESK will provide the customer with Windows XP and/or Server 2003 patch content that can be imported into their Security and Compliance tool in LANDESK Management Suite

How is LANDESK Custom Patch Content supported?

Customers with an active subscription can use the standard support channels on any content delivered.

───────────────────────────────────

Microsoft Article: Extended Hotfix Support Program

─────────────────────────────────────

Customers must meet the following requirements

• Own LANDESK Patch Manager
• Purchase extended Windows XP and/or Server 2003 Support from Microsoft

For purchasing information, please contact your sales representative.

Your sales representative can be found at the following link through our Customer Portal:

https://support.landesk.com/SupportEntitlement.aspx

Issue

• When running a repair job, an error stating: "Node's reported device ID is not in the database" in the scheduled task window.
• 406 Errors may appear in the IIS W3SVC log
• Error "The core (servername) received the vulnerability info but was unable to process it!" may appear in the Vulscan log
• When running a security or inventory scan from the console you get back the error message "Lost contact"

This is caused by a device ID problem when checking the ID of that agent against the database/core. This can be because of a DB record problem, or it can be caused by a problem in ASP/IIS on the core.

Initial Steps

It may be beneficial to reboot both the SQL server and the Core Server.  Database connectivity is necessary for Device ID lookup

Inventory Related Troubleshooting

Ensure that the client's inventory record is up to date:

1. Setup a scheduled task to run an inventory scan on the machines with /F /SYNC to repopulate the data to the core. This can be done by modifying the inventory scanner script found in manage scripts, adding the /f /sync to the script.   Replace the variable %server% with the core server name.

Example:

REMEXEC1=%LDMS_CLIENT_DIR%\LDISCN32.EXE /NTT=%server%:5007 /S="%server%" /I=HTTP://%server%/ldlogon/ldappl3.ldz /NOUI /NOCD /F /SYNC

    2. After successfully retrieving an inventory scan, re-run the original repair job.

Make sure that the client is pointing to the correct core server.

Check for the core server in the registry:

HKLM\Software\Intel\LANDesk\LDWM\Core Server

Also, check the Inventory scanner shortcut.

Can the client resolve the core servers name?   Look in the above registry key for the core server name, and then try pinging that name from the client.

• Ensure that there are not database performance related issues.  It is a good idea to tune SQL and the Core for the best performance: Recommendations for tuning EPM (LDMS) and MS SQL for large enterprise Core Servers

IIS Related Troubleshooting

1. Is IIS Running?   Restart IIS.   Sometimes this will cause the process to start working.
2. In IIS Manager go to Web Service Extensions and ensure that .NET 2.0 is allowed.   Run IIS Reset from a Run prompt.
3. Ensure that the IUSR account has the proper rights.   If the IUSR account is in the Guest group, ensure that the Guest group is not disabled.

Try to browse to http://coreserver/wsvulnerabilitycore/vulcore.asmx.   If the client cannot reach this page:

1. Click Start, choose Programs, Administrative Tools, and IIS manager
2. Expand Application pools
3. Right-click LDAppVulnerability and choose properties
4. Choose the Identity tab
5. Select predefined and Local System from the drop-down list
6. Reset IIS
7. Test Vulscan, Inventory, and a Scheduled task

Re-Register ASP.NET

1. Run cmd.exe from the start-->run on the pc.
2. Change into the C:\Windows\Microsoft.Net\Framework\v2.0.50727 folde
3. Run aspnet_regiis -i (this will reinstall .NET 2.0)
4. Run IISRESET.

Review IIS Virtual Directory and File permissions

About IIS Virtual Directories and File Permissions for Security and Patch Manager

In particular, the permissions for IncomingData and VulscanResults are important.

───────────────────────────────────────

Defaults for IncomingData:  (R = Read, X = Write)

───────────────────────────────────────

Defaults for VulscanResults: (R = Read, X = Write)

───────────────────────────────────────

Restore IIS settings from backup if available.

If the IIS settings were from before the last applied service pack, reapply the last service pack.

• Ensure that IUSR has not been placed into the Guest group on the core server.

COM+ Objects

Ensure that the COM+ objects have the correct identity set.

1. Specify credentials for the LANDesk COM+ objects by clicking on Start, going to Administrative Tools, choose Component Services, click the plus sign next to Component Services, click the plus sign next to Computers, click the plus sign next to My Computer, COM+ Applications, right-click on LANDesk (you will also perform this task on LANDesk1), click on the Advanced Tab, place the Radial button in “Leave running when idle”, click on the Identity tab, specify a Domain Administrator and password for this user. (This will replace LANDeskComPlus, the new username must be in the domain\username format.)
2. Restart the Core Server. (This must be done because of caching done by IIS, for more information see Microsoft KB Article

       # 326818 http://support.microsoft.com/kb/326818

Issue from import of Scan and Repair settings

If none of the above options resolve this, you may have an issue with some of your scan and repair settings (agent behaviors) that were imported from another core server.

1. Browse to ...LANDesk\ManagementSuite\ldlogon\AgentBehaviors and look to see if you have any agent behaviors that contain the name of a different core in them. If you do, open it up in an editor and check to see what core it is pointing to. If it is pointed to the old core, you imported it with incorrect settings.
2. You need to have imported it using the "Insert items into selected group or owner" and not "Update"
3. The best method is to delete out the old Scan and Repair settings that were imported incorrectly and re-import.
4. Then you will need to update the scan and repair settings on the client machines.

This article describes the content verification feature within LANDESK Patch and Compliance Manager

Content verification can be enabled to cause the LANDESK Core server to add in a hash checking feature when downloading content from the LANDESK Patch Content servers.

The content verification feature applies to the content only, it does not apply to individual patch files themselves.   The patch file hash information is contained within the definition information and is verified as part of the patch installation process.

Content verification is only available for the following content types:

• Microsoft Windows Vulnerabilities
• Microsoft Windows Security Threats
• LANDesk Updates

Note: When content verification is enabled, but content types other than the types mentioned above are downloaded (Apple Macintosh definitions, for example), errors may be thrown.

Example of errors for content types that do not support Content Verification:

Even though an error is thrown, the content is still downloaded correctly.

Content verification can be enabled within the Download Updates tool under the Content Tab:

Verify definition signatures/hashes before downloading

NOTE: When checked, any definitions that do not have a valid SHA256 hash will not be downloaded. Also, any lists of definitions that do not have a valid signature will not be processed. The download progress form will show any download failures due to invalid/missing signatures or hashes.

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

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.  In addition, the Ivanti core server will contact the following addresses:

• community.LANDESK.com
• cswebtools.LANDESK.com
• license.LANDESK.com
• Various vendor patch URL's as detailed in this article.

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/

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)

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?

- 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

Issue

Need to disable Windows Updates

Need to enable Windows Updates

Resolution

Downloading Updates

A pre-requisite for the following instructions are to download the Security Threat updates.

1. Click the Download Updates icon.
2. Go to the updates tab.
3. Expand the tree to go to Windows -> Security -> Microsoft Windows Security Threats
4. Click "Download Now".

Note you may want to add the Microsoft Windows Security Threats to your list of regularly downloaded content.

The settings for Windows Automatic Updates can be changed using the custom definition settings in LANDESK Security Suite.  The steps below show the steps required to Disable Windows Automatic Updates.

1. Download the Security Threat definitions by going to the
2. From a LANDESK Console go to Security and Compliance | Patch and Compliance
3. Select "Security Threats" from the "Type" drop down menu located on the toolbar.
   
4. Right click on "Custom Groups" and select the option to create a new group.  Give the new group a name such as "Security Threats" and save it.
   
5. In the left-hand pane click Security Threats (all items)
6. In the right hand pane under Find enter "ST00003" and hit Enter
7. Double-click on the ST000003 definition to open the properties.
   
8. Click on the "Custom Variables" tab.  Click on the "Value" drop down menu and select the desired option.  For this example choose the "Turn Off" option. Click "Apply".

6. Highlight the "ST000003" vulnerability from the list of vulnerabilities in the scan folder and drag it to the custom group that was created in step 3.

7. Create a new Distribution and Patch setting and give it a name such as  "Security Threats".

8. In the left-hand pane go to Patch-only settings | Scan options and where it says "Scan for" select the radio button for Group and then select the group created in Step 3.

9. Select the option to "Immediately repair all detected items".

10. Make any other modifications Distribution and Patch settings and click the Save button.

11. Right-click the Custom group created in step 3 and choose Repair

12. Select the Repair settings you would like to use.

13. Under Agent Settings in the left-hand pane select the Distribution and Patch setting that was created in step 7 from the Distribution and Patch Settings drop down menu. Click the Save button to create the task.

14. Drag the clients you want to run this machine into the task and select a start time.

Please note that that there are multiple methods that one could use to disable the Windows Automatic Updates with LANDESK.  The method provided in this article will create a task that scan specifically for the ST000003 vulnerability instead of scanning for all of the security threat vulnerabilities that are located in the Security Suite Scan folder. This will result in a faster scan and repair.

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 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" feature is only available in 2017.3 and newer product versions.

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)

Next Gen Microsoft Windows Vulnerabilities (beta) is not shown in the Patch Manager > Download updates > Windows > Vulnerabilities

To resolve the issue, click on and select "Microsoft Windows Vulnerabilites", click on button "Apply" and click on the button "Download now".

Once the download completes, go back to "Download updates" and the definition type "Next Gen Microsoft Windows Vulnerabilities ( beta ) will be shown.

Overview:

LANDESK 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, LANDESK leverages the Microsoft Office Deployment Tool to perform the remediation tasks for updating Office 2013 installations. For Office 365 version 2016, LANDESK has developed an Office Com API to perform remediation tasks for updating Office 2016 installations. LANDESK 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, LANDESK will check the hash on the pertinent files to ensure validity.

High Level Process

1. The LANDESK administrator downloads Office 365 definitions from the LANDESK global servers.
2. Once the Office 365 definitions are downloaded to the core, the LANDESK administrator can scan for those Office 365 vulnerabilities.
3. In order to remediate (apply latest patches) detected vulnerabilities, LANDESK administrator have to manually run, on the core machine, a new tool provided by LANDESK (Office365Util.exe). Using this tool, the LANDESK administrator can choose the Office 365 versions that are relevant to the environment. The LANDESK 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 LANDESK 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 LANDESK 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 LANDESK.

\\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 (LANDESK 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 LANDESK 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 LANDESK 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 LANDESK 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-Ru

Note: As of LDMS 9.6 the Scan and Repair Settings are known as Distribution and Patch Settings.   For the latest information on this subject see article: About LANDESK Distribution and Patch settings

The Scan and Repair settings are at the core of the patching process. All configuration is set here. These settings are stored on the core server and are updated automatically when vulscan runs. That means if you change the Scan and Repair settings that are configured for a device, the next time it runs vulscan it will update and use the new settings.

Each client machine has an "installed" Scan and Repair settings. That means that it is the default configuration that will be used on any tasks that don't have an assigned Scan and Repair settings. The currently "installed" settings can be found in the client machine inventory at: Computer - LANDesk Management - Vulnerability Scan - Settings - Scan and Repair Setting Name. The "installed" settings can be changed using a "Change settings..." task found the the "Create a task" drop-down in the Patch Manager tool.

Each of the settings and it's effects can be found below. The settings described are from LANDESK Management Suite 9 so previous versions may be missing some options or present them differently.

Settings

General Options

• Name: The name of the settings. If these are descriptive, or have names that make them easy to know where/how they apply it helps.
• Show progress dialog: This determines if the vulscan GUI will appear. Possible settings are always, never and only when repairing
• Hide if user is showing a presentation: This will hide the GUI if the client machine is running a full-screen presentation. Currently we only detect this condition with Microsoft PowerPoint. This WILL NOT prevent the scan or repair job from running, it will only hide the GUI.
• When no reboot is required: These settings apply when there is not a reboot. You can choose to wait for the user to close the GUI, or time out after a certain period of time and close.
  Recommendation: Always set this to "Close after timeout". Usually you are not required to wait for the user to just close the dialog, and it can cause tasks to timeout and return a bad/incorrect status.
• CPU utilization when scanning: This will attempt to control the CPU level when scanning. When set to low, the scans will take longer, but should have a reduced impact on the general computer use. High will result in the fastest scans.
• Scheduled task status: This determines how much information is sent back to the core for a Scheduled Task run on the device, such as a repair job. Possible options here are: Send standard information, Send nothing, and Send debug information (not localized)
• Set as Default: If this option is set it will set this scan and repair setting to the default Scan and Repair setting.

Scan Options

• Scan for: This pane allows you to set what should be scanned for when vulscan is run with these settings
• ...Group: A custom group of vulnerabilities can be set here. Groups can be created in the console and vulnerabilities can be added as needed. Vulnerabilities can be members of more than one group. Groups can have sub groups as well. If a parent group is selected here, all the child groups and vulnerabilities will be scanned.
• Immediately repair all detected items: This option can only be set if scanning for a group. It has the same effect as autofix. Vulscan will scan for all the vulnerabilities in the group, then immediately request and install the patches for any detected items.
• ...Type: If this option is selected, vulscan will scan for all definitions in each category checked below. It will only scan vulnerabilities that are in the Scan category on the core server. It WILL NOT scan for anything in the Do not scan, or Unassigned categories.
• ... Vulnerabilities: This will scan for all definitions in the Scan group that are of the Vulnerability type. This is the most common definition. All of the Microsoft general, or "Patch Tuesday" patches will be this type.
• ... Spyware: This will use the spyware engine to scan for any definitions in the Scan category that are Spyware definitions.
• ... Security threats: This scans for Security threats definitions in the Scan category. These are things like firewall enabled, or telnet enabled.
• ... Blocked applications: This scan will update the list of blocked applications that are blocked in real-time by softmon.exe when vulscan isn't running. You can select to put All blocked apps in the block list on the client or Only apps in group: and select a group of blocked apps.
• ... Antivirus Updates: This will scan for needed AV updates. It can scan for updates on a variety of AV products besides LANDESK AV.
• ... LANDesk Updates: This scans for any LANDESK updates in the scan group. This is limited to patches released by LANDESK, usually roll-ups and Service Packs. This is the only option available to customers that have not purchased LANDESK Patch Manager or Security Suite. All LANDESK customers can scan for and repair LANDESK vulnerabilities.
• ... Software updates: This category is for a limited number of Software updates. Generally Lenovo ThinkVantage or Intel software.
• ... Driver updates: This contains hardware and driver updates from some vendors such as Dell. It allows vulscan to scan for driver updates, BIOS updates and the like.
• ... Custom definitions: This category is for Custom definitions made by the end user. They can be used to do a number of things, including installing customized patches, patches for internal software, or software that LANDESK doesn't provide vulnerability data for.

Repair Options

• Before repairing, installing, or uninstalling a patch: This setting determines when the patch will be installed. Once the job is run and started on the client, these options will be used to determine when the patch will be installed. The options are:
  • Immediately begin: The patch job will begin immediately, as soon as the client receives the job.
  • Notify user with message: The patch job will still begin immediately, but a message will be presented to the user indicating that the patching is happening.
  • Notify user, also allowing defer: The message is presented to the users. They can select to begin the patch installation, or they can defer it until the machine is locked or logged out. There is only one option and the user can't choose lock or logout, so the patch job will occur as soon as either condition is met.
  • Notify user, also allowing defer or cancel: This options presents the message to the user with the deferral option above, but also allows the user to cancel the job. If this option is selected the patches will not install and the console will report that the user canceled the job.
  • Wait to repair until machine is locked or screen saver is running: This will put the repair job on hold until the machine is either locked, or a screensaver starts. The patch job will continue after the machine is unlocked or the screensaver is canceled.
  • Wait to repair until user is logged off: This option will wait to install the patch until the user logs off. If the same user, or another user logs on during the repair job, it will continue patching until the job is complete.
• Message: This is the message that will displayed if an option is selected to notify user.
• If no end user response: This is what to do if a message is presented to the user and there is no response.
  • Wait for user response before repair, install or uninstall: This will leave the message there until there is a response. As noted, this can cause scheduled tasks to timeout and/or fail.
  • After timeout, automatically: If this option is selected, the message prompt will wait the specified time and then proceed with the action selected. The options are:
    • Start install: This will just proceed to the patch installation.
    • Close: This will close the notification and not run the patch job.
    • Defer install till machine locked: This will defer the installation until the machine is locked or logged out.
• Start repair even if: This tells vulscan to start the repair job even when certain conditions are true.
  • User is running a presentation: This will start the repair job even if a presentation is running. If this is unchecked the job will automatically be delayed until the machine is locked or logged out. Note:This only detects the machine as "running a presentation" for MS PowerPoint, full screen presentation at this time.
  • Reboot is already pending: A reboot is deemed to be already pending if there are any entries in the PendingFileRenamekey in the registry. Other applications can modify this key so if the machine is pending a reboot for ANY reason we will detect it and either continue or fail the job depending on this setting. Some AV applications are known to always set this key.
• Max bandwidth when downloading from source: This is the maximum bandwidth to be used when downloading files from the source (the core or preferred server).
• Max bandwidth when downloading from peer: This is the maximum bandwidth to use when downloading from a peer through the LANDESK Peer-Peer download technologies.

MSI Information

• MSI Information: Some patches require access to the install MSIs and this allows them to find the correct MSIs.
  • Original package location: This is used to specify a network path containing original MSIs.
  • Credentials to user when referencing the original package location
    • User name: The user name to use when accessing the MSIs. This should be in the form domain\username.
    • Password: The password for the user name listed above.
  • Ignore the /overwriteoem command-line option: Indicates the command to overwrite OEM-specific instructions will be ignored. In other words, the OEM instructions are executed.
• Run as information: This allows you to configure a user to run the patches as. This will override the default use of the Local System account
  • Domain\User name: Make sure to specify the user as domain\username. This user MUST have admin rights on ALL client machines.
  • Password: The password to the above user.

Reboot Options

These are the options used to configure when and how the machine is rebooted by vulscan. It can be configured to present a message, allow delays or cancels or to not reboot at all.

• When deciding whether to reboot
  • Never reboot: Once vulscan completes, regardless of what patches were installed the machine will not be rebooted by vulscan.
  • Reboot only if needed: Once vulscan completes it will check the PendingFileRename key on the machine registry to determine if a reboot is needed. If it is the machine will be rebooted using the options configured.
  • Always reboot: When vulscan finishes, regardless of what it did, it will reboot the machine according to the reboot options configured.
• When rebooting
  • Prompt user before rebooting: This will prompt the user before the reboot happens to let them know that it will happen.
  • If no one is logged in, reboot immediately without prompting or delay: This allows vulscan to bypass the prompt if no one is logged in.
  • Allow user to defer (snooze): These settings can be used to allow the user to defer or snooze the reboot for a period of time if needed.
    • Snooze time: This is how long the reboot will be delayed. Once the time is up the prompt will re-appear.
    • Max deferrals allowed: This is the maximum number of times that a reboot can be delayed. Once met, the Snooze button on the client will no longer be available.
  • Allow user to cancel reboot: When selected the user can cancel the reboot and it will not be re-attempted.
  • Reboot message: This is the message that is presented to the user in the vulscan GUI when prompted to reboot.
  • Wait for user response before rebooting (This can cause scheduled tasks to timeout): If this option is selected, the prompt to reboot will wait until there is a user response. If it takes too long, the scheduled task will timeout and report a failure to the core server.
  • After timeout, automatically: If this option is selected, vulscan will automatically perform the selected action after the specified timeout period without user interaction.
    • Snooze: This will snooze the reboot as configured.
    • Reboot: This will reboot the machine.
    • Close: This will close the dialog and cancel the reboot.

Network Settings

These settings can be used to allow the machine to communicate with an alternate core server.

• Communicate with alternate core server. If this is enabled, vulscan will attempt to communicate with an alternate core server as specified below.
  • Server name: Put the alternate core server name here. It MUST be resolvable by the CLIENTsystems.

Note:The syntax for the Server Name field should be ServerName:PortNumber where port number is the secure port 443 for SSL transmission. If you enter only a server name, without specifying port 443, it defaults to port 80 which is the standard HTTP port. By default vulscan operates on port 80.

Pilot Configuration

This setting can be used to tell machines using this Scan and Repair settings to additionally scan a certain group. This is used to test patches or vulnerabilities before general release. For example new patches can be added to a custom "Pilot" group and through these pilot settings be rolled out to a test group to make sure the new patches don't cause any problems with business applications.

• Periodically scan and repair definitions in the following group. This enables the client machines with this setting to scan and AUTOMATICALLY repair all definitions in a custom group. Make sure to select a group
• Schedule This is the schedule that the machines will scan the pilot group on. This is configured the same way as other locally scheduled tasks on the client machine.

Pro Tip:You can use this as the opposite of pilot group. If you have a set of patches that MUST be installed on client machines, you can add them to the a custom group, then specify it as the 'pilot' group. You can then set an independent schedule for it to run. Another example would be to have a normally scheduled scan that scans everything during the day, then set the 'pilot' group to run at night or during maintenance periods. Patches added to the custom group will be repaired. As you work through approving patches, simply add them to the custom group and you know that the next time the 'pilot' scan runs they will be installed on the clients. Be careful and test this to make sure it works the way you expect, because any patches in the 'pilot' group will be AUTOMATICALLY repaired when the scan runs.

Spyware Scanning

These settings can be used to override and modify the settings set in the client configuration for real-time spyware scanning. That means you can use it to enable or disable real-time scanning on a device. Normally this setting is part of the client setting, but if a Scan and Repair setting is set on a machine that has the Spyware override set, then it will change to whatever the Scan and Repair settings is configured to.

• Override settings from client configurationSelect this if you want to override the real-time spyware scanning settings configured in the client configuration
• Settings
  • Enable real-time spyware blocking Set to enable real-time spyware scanning and blocking
    • Notify user when spyware has been blockedSetting this will notify the user that spyware has been blocked. If it is not set, the spyware will still be blocked, but the user will not be notified. The core server will still have a record of the block
    • If an application is not recognized as spyware, require user's approval before it can be installed If this is enabled, any application that attempts to install must be approved by the user even if it is not recognized as spyware.

Note: In order for spyware blocking to work, the definitions on the core must be set to autofix. For more information see the following articles:

• Using LANDesk Antispywareand Best Known Method for Spyware Scanning

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

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

Description

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

Assumptions

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

Process

Step one: Prepare both core servers to have accurate data

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

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

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

Step two: Prepare the Dark Core folder structure

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

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

Step three: Retrieve content on the "Light Core"

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

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

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

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

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

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

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

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

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

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

Modify the Enu_PatchSourcesXXX.xml as modeled below:

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

Before:

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

After:

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

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

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

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

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

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

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

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

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

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

 

     Before:
     <Source>

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

                   <Description>LANDESK Data Analytics Updates</Description>

                   <ShowInLDSM>true</ShowInLDSM>

                   <ShowInLSM>true</ShowInLSM>

            </Source>

 

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

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

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

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

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

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

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

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

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

Issue

Need to disable Windows Updates

Need to enable Windows Updates

Resolution

Downloading Updates

A pre-requisite for the following instructions are to download the Security Threat updates.

1. Click the Download Updates icon.
2. Go to the updates tab.
3. Expand the tree to go to Windows -> Security -> Microsoft Windows Security Threats
4. Click "Download Now".

Note you may want to add the Microsoft Windows Security Threats to your list of regularly downloaded content.

The settings for Windows Automatic Updates can be changed using the custom definition settings in Ivanti Endpoint Manager.  The steps below show the steps required to Disable Windows Automatic Updates.

1. Download the Security Threat definitions by going to the
2. From an Ivanti Endpoint Manager Console go to Security and Compliance | Patch and Compliance
3. Select "Security Threats" from the "Type" drop-down menu located on the toolbar.
   
4. Right click on "Custom Groups" and select the option to create a new group.  Give the new group a name such as "Security Threats" and save it.
   
5. In the left-hand pane click Security Threats (all items)
6. In the right hand pane under Find enter "ST00003" and hit Enter
7. Double-click on the ST000003 definition to open the properties.
   
8. Click on the "Custom Variables" tab.  Click on the "Value" drop down menu and select the desired option.  For this example choose the "Turn Off" option. Click "Apply".

6. Highlight the "ST000003" vulnerability from the list of vulnerabilities in the scan folder and drag it to the custom group that was created in step 3.

7. Create a new Distribution and Patch setting and give it a name such as  "Security Threats".

8. In the left-hand pane go to Patch-only settings | Scan options and where it says "Scan for" select the radio button for Group and then select the group created in Step 3.

9. Select the option to "Immediately repair all detected items".

10. Make any other modifications Distribution and Patch settings and click the Save button.

11. Right-click the Custom group created in step 3 and choose Repair

12. Select the Repair settings you would like to use.

13. Under Agent Settings in the left-hand pane select the Distribution and Patch setting that was created in step 7 from the Distribution and Patch Settings drop-down menu. Click the Save button to create the task.

14. Drag the clients you want to run this machine into the task and select a start time.

Please note that that there are multiple methods that one could use to disable the Windows Automatic Updates with LANDESK.  The method provided in this article will create a task that scan specifically for the ST000003 vulnerability instead of scanning for all of the security threat vulnerabilities that are located in the Security Suite Scan folder. This will result in a faster scan and repair.

If there is an application update that you would like to see included in Patch Manager content you can submit a request to Ivanti support to have the content added.

A list of current Patch Manager content can be located here: Products and Applications available through Ivanti Security and Compliance content delivery. 12/Oct/2017.

To increase the chance of the content being added and the speed that it is added, collecting the following information for the Support case will be helpful.

1. Name of the application including version.
2. Name of the update.
3. Link to the update.
4. A short business justification for adding the content.

It is recommended to use the Support Portalto submit this information.

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