This video shows you how to get started with Application Blocking.

If this video has helped you please like or leave a comment, Thank you.

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 LANDESK Management Suite 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 LANDESK Management Suite 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.
   
4. Give the task a name and select whether you want it to be a Scheduled Task or a policy.
5. Click on "Keep agent's current settings" to bring up a drop down menu of available settings.
6. Select the new setting.
   
7. Click "Save".
8. Add computers to the task and run it.

Purpose

This article explains the behavior of optional and recommended Patch Repair tasks as they relate to the LDMS Portal

.

Symptoms

When creating a patch repair task as a policy, and setting the task to be optional or recommended in the LDMS Portal, the task may:

• Take multiple refreshes to show in the portal
• May not show in the portal at all

Cause

When a patch repair task is set as a policy, and is made optional or recommended in the LDMS Portal, the following occurs:

• The policy is made available to the client
• The client runs policy sync (clicks refresh in the portal)
• The policy is downloaded and triggers vulscan to scan for the patches in the repair task
  • A patch must be detected as 'missing' to be displayed in the portal.
• A secondary policy.xml file is created on the client containing a list of which patches were found as missing
• The client runs poilcy sync (clicks refresh in the portal)
• The second policy.xml file is parsed, and any patches listed within it are published to the portal

If 'show one portal entry with the following title:' is selected, a single entry will be created in the portal which when ran will repair all detected patches.

Note: If no patches were found as missing, no items will be shown in the portal.

If 'show each definition seperately' is selected in the scheduled tasks properties, patches will be contained per definition within the portal.

Example: Definition MS15-020_MSU contains patch kb3039066 and kb3032323.

In our test scan, both of these patches were detected as missing, but since they belong to the same definition (MS15-020_MSU), only the definition is advertised in the portal.

Because vulscan checks patches listed for repair first, and only offers those needed through the portal for repair, policysync (refresh in the portal) is required to be ran a second time after vulscan finishes its scan.

Running policysync (refresh in the portal) prior to vulscan completing its scan will not populate any items in the portal.

If policysync (refresh in the portal) is not manually ran, it will be ran on its scheduled interval as defined in the agents settings.

Overview: The ability to schedule and start a patch content download is limited to administrators. A non-administrator can schedule the download but they cannot start it.

Resolution: This is by the current design.

Issue

After scheduling a repair task or policy, clients complete with a status message of “Successful” a result of "No Patches Available"

Cause

This is caused by patches in the repair task not being detected as needed on the client.  Patches can only be applied if the vulnerability definition being scanned for shows the computers as affected.

Typically this is because a security scan has not been run recently.

Resolution

1. Make sure the vulnerability is in the Scan folder in the Patch Manager window.
2. Run a Security Scan, verify that the Distribution and Patch Settings are configured to scan for the type of definition desired. (vulnerability, LANDesk update, etc.)
3. Verify that the scan completed successfully.
4. Add the machine(s) to the repair task and restart the task.

Alternatively, when repairing against a group of definitions in Security and Patch Manager, both the Scan and Repair take place during the repair job

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

This issue can also be indicative of a failure for the Core Server to access the database to get the patch information.  This is typically done through the GetAllPatches web call from client to core.  The core then generates an XML that gets downloaded to the client that contains the data about the patches that need to be installed.   Failures to parse the XML on the client can cause the issue as well.

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

The following details this issue:

Getting errors in the vulscan log that reflect:

Warning:  AddPatchesToPatchList - Failed to parse xml data or there were no patches 0x80004005

No patches found for vulnerability="Vulnerability ID".  Returning PATCH_NO_PATCHES_AVAILABLE

Cause

This is due to an incompatible Vulscan.dll version causing the .XML data for the patch information to be parsed incorrectly.

After the Vulnerability Scanner has run on a client, it will report back the vulnerabilities found to the server.   If autofix is enabled, or the vulscan task is a repair job, it will also request the corresponding patch details from the core server.

An .XML file containing the patch data will then be downloaded to the client.

Typically this .XML file will have a name like the following:

If repairing against a group: GetPatchesForGroup.CoreNameAndRevision.patchlist.xml

If repairing a particular vulnerability: GetPatchesForVulnerability.PatchName.CoreNameAndRevision.patchlist.xml

The client then attempts to parse this XML and pass the information over to the Software Distribution portion of the repair process.

Resolution

Check the Vulscan.dll version on the core in your LDLogon directory.  If the DLL version is does not match what should exist due to your current patch level, manually copy the vulscan.dll from the service pack install or component patch and see if this resolves the issue.

Applies to LANDESK Management Suite 9.0 Service Pack 2 and earlier

LANDesk provides a large number of vulnerability definitions for a large number of products going back quite some time. Because newer patches sometimes replace older patches, LANDesk provides this information as part of the definition. When a newer patch or vulnerability becomes available, the previous version will be marked as replaced, either partially or completely. This information can be used to improve the performance of Security Scans on client machines as well as provide more accurate information about the vulnerability status of machines. Some other symptoms that are seen and can be resolved include:

• Vulnerabilities keep getting detected on computers and the patch will not install
• Patches are stuck in loop continually trying to install on the clients

While this process will not resolve all cases with the above symptoms, it can resolve some issues. It is recommended that all customers review this information to help keep the Patch Content up-to-date.

Issue

• Vulnerabilities keep getting detected on computers and the patch will not install

• Patches are stuck in loop continually trying to install on the clients

• Security Scans (VULSCAN.EXE) takes a long time to run

Solution

Quick Reference

The general overview of the steps required is outlined below. Continue reading for more detailed information, or select the step in question for more details.

1. Download the latest patch content
2. Make sure all neccesary vulnerabilities are in the Scan folder
3. Sort the items in the Scan folder by the Replaced column
4. Move superseded vulnerabilities to Do Not Scan
5. Verify vulnerabilities were correctly moved to the Do Not Scan folder
6. Disable replaced detection rules
7. Delete superseded vulnerabilities from custom groups
8. Run deleteOldPatches.exe on the Core Server

Download the Latest Patch Content

The Download Updates tool is accessed from the Patch and Compliance window.

LANDesk® Management Suite 8.8

To get to the Download Updates tool, select Tools > Security > Security and Patch Manager. Then select the Download updates button from the toolbar. It is the first button on the left.

For more information about updating defintions see: Getting started with Patch Manager in LANDesk® Management Suite 8.8

LANDesk® Management Suite 9.0

To get to the Download Updates tool, select Tools > Security and Compliance > Patch and compliance. Then select the Download Updates button from the toolbar. It is the first button just to the right of the drop-down menus.

For more information about updating defintions see: Getting started with Patch Manager in LANDesk® Management Suite 9.0

Verify Vulnerabilities are in the Scan Folder

After the Patch Content has downloaded, move any new vulnerabilities that should be scanned from the Unassigned folder to the Scan folder. Only put vulnerabilities in the Scan folder that should be scanned for on the computers to help speed up the security scans on clients.

Sort Items in the Scan Folder by the Replaced Column

1. Open the Patch Manager tool in the LANDesk Console
2. Select All Types in the Type box
3. Select All Items in the Filter box
4. Click the Scan folder under All Types on the left pane
5. Click the Replaced column to sort by the Replaced value

Move Superseded Vulnerabilities to Do Not Scan

There are 2 methods to complete this step. One is using a SQL query and the other is through the LANDesk Management Console. Only one of the options needs to be completed for this step.

SQL Query Method

For LANDesk® Management Suite 8.8, run the following SQL statement against the LANDesk database:

/* This Query will move vulnerabilites that have
 "All" in the "Replaced" column to the "Do Not Scan" folder.
*/
UPDATE Vulnerability SET Status = 0
WHERE Vulnerability_Idn in (
SELECT Vulnerability_Idn FROM Vulnerability WHERE SupercededState = 2 AND Status != 0
)

For LANDesk® Management Suite 9.0, run the following SQL statements against the LANDesk database:

/* This Query will move vulnerabilites that have
"All" in the "Replaced" column to the "Do Not Scan" folder.
*/
INSERT INTO PatchTask (TaskType, RequestDate, param1, param3, message)
SELECT 2, GETDATE(), Vul_ID, 'False','Remove scan status for vulid: '+ Vul_ID +' , patch'
FROM Vulnerability WHERE SupercededState = 2 AND Status != 0

UPDATE Vulnerability SET Status = 0
WHERE Vulnerability_Idn in (
SELECT Vulnerability_Idn FROM Vulnerability WHERE SupercededState = 2 and Status != 0
)

Note: The SQL statements have only been tested on Microsoft SQL server. They may require modifacation to run on Oracle. The SQL statements can be added to the database maintenance run by your DBMS so that they run on a regular basis. Contact your DBA for help with this.

If you use the SQL statement(s), continue to the next section titled "Verify only superseded vulnerabilities moved to Do not Scan".

LANDesk Management Console Method

1. Click on the first vulnerability in the list that has All in the replaced column It should be the first item in the list.
2. Scroll down the list to the last item in the list that has ALL in the Replaced column.
3. Hold the shift key down and click the last item with All in the Replaced column. This should highlight all vulnerabilities with All in the Replaced column.
4. Click and drag the selected items to the Do Not Scan folder.

For LANDesk® Management Suite 9.0, if the "Update dependent or prerequisite definitions as well" box comes up, click No.

For LANDesk® Management Suite 8.8, if the "Update dependent or prerequisite definitions as well" box comes up, click Yes.

Verify Only Superseded Vulnerabilities Moved to Do Not Scan

1. Click on the Do Not Scan folder under All Types
2. Click the Replaced column to sort by it
3. Verify that all vulnerabilities have All in the Replaced column

Note: This assumes that no other vulnerabilities had already been moved to the Do Not Scan folder. If there were already definitions in the Do not Scan folder only move back definitions that may have been moved inadvertently.

Disable Superseded Detection Rules

Sometimes only part of a vulnerability will be replaced. For example, only the Windows XP part of the previous definition will be replaced by a newer definition. In this case, the Replaced column will indicate Some. In these cases, you can disable the scanning of each replaced detection fule inside the vulnerability

There are 2 methods to complete this step. One is using a SQL query and the other is through the LANDesk Management Console. Only one of the options needs to be completed for this step.

SQL Query Method

For LANDesk® Management Suite 8.8 and 9.0, run the following SQL statement against the LANDesk database:

/* This Query will disable individual detection rules
if they have been superseeded and if the vulnerability they belong to
has "Some" in the "Replaced" column.
This only disables detection rules for vulnerabilities currently in the Scan Folder
*/
UPDATE Patch Set Ignore = 1 WHERE Patch_Idn IN (      SELECT p.Patch_Idn FROM Patch p, Vulnerability v WHERE      p.Vulnerability_Idn = v.Vulnerability_Idn      AND SupercededByVulID IS NOT NULL      AND v.SupercededState = 1      AND v.Status NOT IN (0, 2)
)

Note: The SQL statement has only been tested on Microsoft SQL server. It may require modifacation to run on Oracle. The SQL statement can be added to the database maintenance run by your DBMS so that it runs on a regular basis. Contact your DBA for help with this.

If you use the SQL statement, continue to the next section titled "Delete superseded vulnerabilities from custom groups".

LANDesk Management Console Method

Once you have moved all of the definitions that have been entirely replaced (All) to Do not Scan, some definitions will remain in the Scan folder that have been partially replaced. To deal with these, you can disable any superseded detection rules.

1. Click on the Scan folder under All Types
2. Click the Replaced column to sort it so vulnerabilities with Some in the column show up at the top of the list
3. Right-click the first vulnerability in the list and select Properties.
4. Right-click each detection rule in the list that has an entry in the Replaced by column and select the Disable scan option.
5. Repeat this process for all vulnerabilities that have Some in the Replaced column. This will disable the detection of rules that have been replaced by newer vulnerabilities.

Delete Superseded Vulnerabilities from Custom Groups

Now that superseded detection rules have been disabled, it is time to delete the superseded vulnerabilities from custom groups.

1. In the Patch Manager window, expand Custom Groups.
2. Click on each custom group and sort the vulnerabilities by the Replaced column.
3. Select all of the vulnerabilities that have ALL in the Replaced column and delete them.
4. Repeat this process for each custom group under My custom groups and Public custom groups.

Run deleteOldPatches.exe on the Core Server

This tool will delete all patches from the patch folder for the Core Server that are not associated with a vulnerability in the Scan folder.

1. Download deleteOldPatches.zip attached to this article.
2. Extract deleteOldPatches.exe from deleteOldPatches.zip
3. Copy deleteOldPatches.exe to the Core Server.
4. Run deleteOldPatches.exe on the Core Server.

Note: Adding s to the commandline (deleteOldPatches.exe s) will make it run silently so that it can be scheduled. This tool is provided as-is without any warranty, express or implied and is not supported by LANDesk support. If patches are deleted inadvertantly, they can generally be re-downloaded using the Download Updates tool

Troubleshooting Client Reboot Issues

The purpose of this document is to answer some of the most common questions that are asked in terms of clients being rebooted. LANDesk offers several different methods for rebooting a computer.  A reboot might be caused by a software distribution package or,by selecting the option to reboot in a scan and repair setting or delivery method etc.  Since there are so many possible scenarios that could result in a reboot, finding the exact cause of a client reboot will require a review of some of the log files on the machine.  This document will provide steps necessary to locate the cause of the reboot.

Stopping a Task

Question:  Computers are being rebooted! Is there anyway to stop all jobs from running until I am able to determine the cause of the reboot?

Answer:  If it is a scheduled task that is causing the reboot then stopping the LANDesk Scheduler Service will prevent the core server from sending the task out to any additional clients.  However, if the client has already received the task and is processing it, it will not prevent the client from running the task.  Stopping the Scheduler Service will only prevent the task from being distributed to any machines that have not already received the task.

Stopping a Policy

If it is a policy that is causing the machines to reboot then stopping the LANDesk Policy Server would prevent any further machines from checking back to the core server for a updated list of policies that need to be ran.

Useful Items When Troubleshooting Reboot Issues

What time did the client reboot?  The application and system event logs will tell you the exact time the system was rebooted.

• Are there any error messages in the event logs prior to the machine being rebooted?
• A list of possible jobs that may have been scheduled on the machine that was rebooted.
• Sdclient and vulscan logs from the client that was rebooted.
• Are there any other applications on the client other than LANDesk that may have caused the reboot?

Reboots Caused by a Vulnerability Scan

This section of the document will focus on reboots that were caused by a job that was created in the Patch Manager (LDMS 88 and below) or the Patch and Compliance section (LDMS 9).  The most common cause for a reboot when dealing with a vulnerability scan/repair is that a task was scheduled using a scan and repair setting that had either the Reboot only if needed or the Always reboot option selected. The steps below demonstrate how to verify which scan and repair setting was used during the scan.

Determining What Scan and Repair setting were Used During a Scan

The vulscan logs on the machine will display what scan and repair setting was used during vulnerability scan. The vulscan log files can be located in

• C:\documents and settings\All Users\Application Data\Vulscan.  (Windows XP)
• C:\Program Data\Vulscan (Windows 7)

The vulscan log file will show what scan and repair settings was used during the last scan. Sort the vulscan logs by date and try and locate a vulscan log that took place right before the time that the client was rebooted.  The vulscan log will show what command was actually passed to the client machine to run. In the following example the command that vulscan exacuted is "vulscan.exe /agentbehavior=JN-LD-CORE9_21". This means that a vulnerability scan was ran using a scan and repair setting named JN-LD-CORE9_21.

Clicking on the configure settings button in the Patch and Compliance window and selecting the scan and repair settingsoption will display a list of all of the different scan and repair settings that are available on the the core server.  locate the ID of the scan and repair setting that was used during the scan and double click on it to bring up the properties window.

Reboot Options.

Select Reboot Options from the menu on the left hand side of the screen to view the reboot options for the scan and repair setting. If Reboot only if needed or Always reboot was selected under the reboot options of the scan and repair setting then the client machine would be rebooted after the scan was completed.

Reboot Task

Reboot task can be scheduled from the Patch and Compliance section of the console.  If the client was rebooted because it was inadvertently added to one of these reboot task then the vulscan.log would show that the /rebootifneeded command was ran.

Reboots Caused by a Software Distribution Job

This section of the document will focus on reboots that were caused by a software distribution task.  The most common reason for a client being rebooted after a software distribution task is that the task was ran using a deployment method that was configured to reboot a machine.  The steps below will show how to find out what deployment method was used in the software deployment task.

Determining What Deployment Method Was Used In a Software Distribution Task

The sdclient log files will show what software was installed on the client machine during a software distribution task.

The sdclient logs are located in C:\Program Files\LANDesk\LDClient\Data directory.  There will be a sdclient.log file as well as a sdclient_task#.log file.  Sort the sdclient logs by date and try and locate a sdclient_task#.log file that was created around the time that the client was rebooted.

In the example below the last job that was ran on the client machine created a sdclient_task4.log file.

In this example we can see that the client ran http://JN-LD-Core9/ldlogon/apps/7z465.exe.  The contents of this log file will show what command was executed on the client as well as the results of that command.

The task ID number that is used in the name of the sdclient_task#.log file can be used to view the properties of the task in able to determine what delivery method was used in the software distribution task.

In this example sdclient_task4.log was created.  If the task still exist in the console you can view the properties of the task to determine what delivery method was used. there is a column in the scheduled task window that will show the Task ID.   Once the task has been located double click on the task to view the task properties.

Right clicking on the task and selecting Properties | Delivery Method will display the name of the delivery method that was used for the scheduled task.

Locate the delivery method in the console by selecting Tools | Distribution | Delivery Methods.

Double click on the delivery method that was used during the software distribution task to view it's properties. Click on the Reboot option on the menu to view the clients reboot options.

Setting the delivery method to Reboot onlyif needed or Always reboot will result in the client being rebooted.

* Note:  If the task has already been deleted from the console there is no way to determine what delivery method was used for the software distribution task.

The Sdclient.log file will also show any reboot commands that were passed to the client as a result of the last job and can be helpful in determining if the reboot was caused by a LANDesk task.

Wake On LAN Task

If the WOL option is selected in the scheduled task then core server will attempt to power on the client and run the scheduled task.  Once the task is completed the client will attempt to turn the computer off again.   To determine if this option was selected right click the task and select Properties | Targeted devices to view the properties of the scheduled task.  Click on the Targeted devices option and verify if the Wake up devicesoption was selected.

LANDesk has seen issues where a client was powered on during a scheduled task.  If it is a large package or a task with several clients associated with the task, then there may be a lengthy delay between the time the client is actually powered up and the time it receives the task and powers back down.

On Demand Reboot

It is possible to reboot a client from the LANDesk console by right clicking on a device and selecting the reboot option.  If a client was rebooted using this method the then the servicehost.log file will show that poweroff.exe was executed on the client machine.  The servicehost.log file will be located on the client in C:\Program Files\LANDesk\SharedFiles.

A poweroff.exe.log file will also be created under C:\Windows\System32

Scenario

As needed LANDESK Software will release a Service Pack to add new features to the product or resolve defects that have been discovered.
As part of the Service Pack release a vulnerability definition will be included that will allow LANDESK Patch and Compliance Manager to detect and repair your Management Suite Consoles and Clients.

Instructions

Important Note: The Service Pack must be manually installed on the Core Server prior to following the instructions below.

It is necessary to download LANDESK Updates content within Patch Manager, to obtain the newest product definitions.

Ensure that LANDESK 9.6 SPx Software updates is selected in the Download Updates tool within Patch and Compliance Manager

1. Click on the Download Updates button within Patch and Compliance Manager.
   
2. Ensure that Windows | Software Updates | LANDESK 9.6 SPx Software Updates in the Definition Types column on the left is selected.
3. Click Schedule Download and schedule the download to take place immediately or at a future time if so desired.

Creating a Security Scan task to detect the need to install the Service Pack:

1. From a LANDESK Management Suite Console select Tools | Security and Compliance | Agent Settings.
2. ExpandMy Settings or Public Settings as desired.
3. Right click on Distribution and Patch and select New
4. From the Distribution and Patch Settings screen change the Name to "LANDesk Updates only".
   1. From the Menu on the left select Patch Only Settings | Scan Options
   2. Ensure sure that only LANDESK Updates is selected.
5. Click Save.
6. Click the Create a Task Icon (second icon from left on Agent Settingstoolbar) and select Security Scan.
7. From the Create security scan task screen.
   1. Change the Task Name to "Scan for LANDESK Updates".
   2. Under Task type check Push, Policy, or Policy Supported Push as desired.
   3. Under Distribution and Patch Settings select LANDESK Updates only.
   4. Click Save
8. This creates a scheduled task called Scan for LANDESK Updates.
9. Add computers from network view by doing one of the following.
   1. Drag and drop the computers into the task.
   2. Copy and paste the computers into the task.
   3. Create a Query representing the computers you with to scan and Drag the Query onto the task.
10. Once you have populated the task with computers Right Click on the task and hover over Start Nowclick All Devices.
11. The time for this task to complete will depend on the number of computers that have been added to the task.

Creating a Repair Task to install the Service Pack task

1. From the LANDESK Console go to Tools | Security and Compliance | Patch and compliance.
2. Change Type to LANDesk Updates.
3. Under Patch and Compliance expand LANDESK Updates.
4. Click the Scan folder.
5. Locate the Service pack name, it will typically start with "LD9xSPx" and the description will be "Service Pack X for LDMS 9.x"
6. Right click on the Service Pack and select Download Associated patches.
   1. Click on Show All associated Patches
   2. Select the Client and console.zip files
   3. Right Clickclient and console patches and choose Download Patch.
7. Once patch is downloadedRight Click on the Service pack and select Repair.
8. From the Patch and Compliance - repair taskwindow:
   1. Change the Name to "Repair <name of service pack>".
   2. Under Task Settings select the desired method for the run-time options for the task (Policy Supported Push, Policy, Push, Frequency,Additional Push Options, and Download Options)
   3. Click Save, this will open the Scheduled Tasks window.
   4. Select computers to repair option of your choice.
   5. Under Agent Settingsselect the Distribution and Patch setting called "LANDesk Updates Only."
9. This will create a Scheduled task with the name chosen in step 8a.
10. Add targets.   This can be a variety of methods: Drag and drop single computers, drag a group of computers, or drag an LDAP query to the task.
11. When you are ready to begin repairing the patch Right-click on the Task and choose Start Now.

Additional Information

About LANDESK Distribution and Patch settings

Getting Started with Patch Manager in LDMS 9.6

If you need to deploy multiple patches you can use this article in conjunction with the following to repair all the patches at the same time.

How to use Custom groups to quickly bring a computer up to date.

Reviewed: 9/15/2015

Applies to:  LDMS 9.6+

By default, vulscan writes 7 logs to the ProgramData\Log folder and then begins overwriting existing logs to save disk space.  In LDMS 9.6+ this controlled by a registry key and can be modified.  For x64 clients the key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\LogOptions

For x86 the key is:

HKEY_LOCAL_MACHINE\SOFTWARE\landesk\managementsuite\LogOptions

In both cases, change the "maxbackups" value to the hex number of logs you would like to retain.  Please note, this applies to vulscan logs as well as other logs.  This can be changed manually or via script.

Applies to LANDesk Management Suite 8.8 and LANDesk Managment Suite 9

• • Description
  • Configuring the Patch Download Location
  • How to properly set up a web and UNC share for the new patch location
    • Creating the UNC Share
    • Creating the Web Share
    • Creating the Web Share in Windows 2008

Description

By default, patches are downloaded and stored in the core servers LDLogon\Patch directory. It is often desirable to store the patches on a seperate server, such as a Preferred Package Server.

Configuring the Patch Download Location

1. Open the LANDesk Console and go to Tools | Security | Patch and Compliance and click on the first iconto open the Download Updates window.
   
2. Click the Patch Location tab.
   
3. Enter a UNC path where the patches are to be stored.
   Note: The default location is the Core Server's \LDLogon\Patch directory.
   
4. If the UNC path entered above is to a location other than the core server, enter a valid username and password to authenticate to that location.
   
5. Enter a Web URL where devices can access the downloaded patches for deployment. This Web URL should match the UNC path above.
   
6. Click Test Settings to check to see if a connection can be made to the Web address specified above.
   
   Note: If you want to restore the UNC path and Web URL to their default locations, click Restore to Default.
   

How to properly set up a web and UNC share for the new patch location

Creating the UNC Share

1. Connect directory or through remote desktop to the share server where the patches will be stored.
   
2. Create a new directory.
3. Right-click the newly created directory and choose Sharing and Security.
4. Click the Sharing Tab.
5. Click Share this folder.
6. Verify the Share name is correct.
7. Click Permissions.
8. An account needs Full control permissions to this UNC share. These are the credentials you will use in step 3 of "Changing Patch Location" (In download updates  tool).  Note: You will also need to set up the permissions on the new share to have the same security settings as the original patch location.
9. Click OK.
10. If you click Test settings when you are setting the patch location in the Security and Patch Manager Tool and you get the error "Failed to write test file to UNC path \\ServerName\sharename\TestWritePatchData.txt" it means you have not given the user in the credentials field write rights to the share.

Creating the Web Share

1. Right click on the folder you want to share and select Properties.
2. Click on the Web Sharing tab.
3. Click Share this folder.
4. Check Read and Directory browsing.
5. Click OK once.
6. Click on the Security tab.
7. Add the IUSR_computername account and give it Read & Execute permissions.
   
8. Click OK.
9. Open IIS Manager, navigate to the default web site and expand its contents.
10. Right click on the newly created virtual directory and select properties
11. Click on the Directory Security tab, then Edit... under Authentication and access control.
    

Check Enable anonymous access and apply the changes.

If you click Test settings when you are setting the patch location in the Security and Patch Manager Tool and you get the error "Failed to read test file from HTTP URL http://serverName/shareName/TestWritePatchData.txt" you have not enabled Anonymous access correctly (Steps 7 - 12).

If you click Test settings when you are setting the patch location in the Security and Patch Manager Tool and you get the error "Failed to write test file from HTTP URL http://serverName/shareName/TestWritePatchData.txt" the UNC share permissions have not been set correctly.   The share permissions for the patch share should mimic the permissions assigned by default to the LDLogon share.

If you have moved the patch directory to a new server and receive an "HTTP Error 404 File or Directory not found" when attempting to download any files, open the IIS manager, right click the Web directory, choose properties, click the HTTP Headers tab, click MIME types..., and add .* All File Types to the MIME types. Now at the run line type iisreset and after IIS restarts the files should be available for download.

Creating the Web Share in Windows 2008

1. Go to Start > Administrative Tools > Internet Information Services (IIS) Manager:
2. Right click on Default Web Site and then click on 'Add Virtual Directory'
3. Alias will be the name of the folder in IIS. It should be the same as the actual folder name and should not contain any spaces
4. Browse to your physical path that you created and then hit ok.
5. Test the share by going to http://CORESERVER/PathToHTTPShare

• • How To:
  • Purpose:
  • Steps
    • Create Custom Group
    • Create Distribution and Patch Setting
    • Run Scan - Run Now
    • Run Scan - Scheduled

How To:

How to scan for a specific patch or group of patches.

Purpose:

In some situations it may becomes necessary to scan for a specific patch or group of patches.

Examples:

• One off patching instances
• Verifying baseline compliance

Steps

Note: We will be using JREJDKv8u31_Manual in the following examples.

Create Custom Group

• Begin by creating a new Custom Group in Patch and Compliance.
  • Click Tools | Security and Compliance | Patch and Compliance.

• In Patch and Compliance create a new Custom Group.
  • Right click My Custom Groups or Public Custom Groups | New Group

• Name the custom group according to your needs.
  • Example: Our scan will be for Java 8u31, so the name will reflect this.

• Locate the content to add to the custom scan group, and add it to the custom group.
  • Drag the content onto the custom group
  • Alternatively right click the content, choose copy, right click the custom group and choose paste.

• This provides a custom group to scan against that only contains the desired patch(es).

Create Distribution and Patch Setting

• Open Agent Settings - Tools | Security and Compliance | Agent Settings

• Click Agent Settings | My Agent Settings or Public Agent Settings | Right click Distribution and Patch  and choose New

• Provide the new Distribution and Patch setting a name that indicates what it is used for.

• Double click the new Distribution and Patch setting to open the options, and choose Patch-only settings | Scan options then click the Groupbrowse button.

• In the Group Selectionwindow, choose the custom group that contains the content to be scanned for and click Ok

• The Group field now reflects the custom group that will be scanned for, click Save

Note: If you only want to scan for a patch, uncheck 'Enable autofix' to ensure autofix is turned off. If you want just this scan also repair the vulnerability, check the box 'Immediately install (repair) all applicable items'.

This will take precedence over Autofix settings, and will allow just patches that are found with this scan to be fixed.

Run Scan - Run Now

• Select the device(s) in inventory to be scanned
• Right click and choose Patch and compliance scan now...

• In the Patch/compliance scan nowwindow,
  • Select Security and Patch scan
  • Click the drop down list and select the Distribution and patch settingpreviously configured.

• A status window will appear indicating the state of the current scan.

• Once the scan completes, repairs and reporting can occur as needed.

Run Scan - Scheduled

In the event the scan needs to happen at a different date/time, or be recurring, it can be scheduled.

• In the LDMS Core click Tools | Security and Compliance | Agent Settings
• Click the Create a Task button(calendar icon)
• Click Security scan...

• In the Patch and Compliance - scan task window, click Agent Settings
• Click the drop down list for Distribution and patch, and select the previously configured setting.

• Configure other settings as needed (Scheduled times, dates etc).
• Save the task

Issue

The following error may be observed when downloading Security and Compliance Manager definition content:

VulnerabilityTOC.SaveToDBThread.2 : Vulnerability.UpdateVulnerabilityLeanXML failed: The statement has been terminated.

Length of LOB data (635145) to be replicated exceeds configured maximum 500000.

Cause

The download updates tool is attempting to download a definition that exceeds the limit imposed by the "max text repl size" as configured in the database.

The max text repl size option specifies the maximum size (in bytes) oftext, ntext, varchar(max), nvarchar(max), varbinary(max), xml, and image data that can be added to a replicated column or captured column in a single INSERT, UPDATE, WRITETEXT, or UPDATETEXT statement. The default value is 65536 bytes. A value of -1 indicates that there is no size limit, other than the limit imposed by the data type.

To check your SQL server current maximum Text Repl size:

1. Right-click on your LANDESK Database and select "New Query"
2. Enter the following text into the SQL Query Analyzer:
3. Hit "Ctrl-E" or click the "! Execute" icon in the toolbar.
   

EXECsp_configure 'show advanced options', 1 ;

RECONFIGURE ;

GO

EXECsp_configure 'max text repl size';

GO

This will show the currently configured options.

Resolution

Run the following statement in SQL Query Analyzer while pointing to the LANDESK database:

sp_configure'max text repl size', 2147483647

Symptom

After applying Application Blocking definitions from 9/24, machines are unable to log into Windows.

• Login attempts may get error:

The RPC Server is unavailable

• The device may enter a reboot loop.

Cause

The defintion DENY-lsm blocks lsm.exe (Local Session Manager Service) which causes this issue.

Solution

• Download latest Application Blocking content
  • This piece of content has been removed
• If DENY-lsm is still in your content, set it toto Do Not Scan
• Run a patch scan against the impacted client so it will update it's blocked apps list to no longer include lsm.exe.
  • The machine may reboot too quickly to do a typical patch scan. To expedite the scan process, create a new Distribution and Patch setting that scans against a Custom group with no definitions in it. This will run a vulscan that scans nothing, but updates the list of blocked applications.

Related Article:

How to Scan for Specific Patches

• Issue
• Cause
  • Key queries to use in Log Parser Studio:
    • For use with W3SVC1 logs:
• Resolution
  • Install Microsoft Log Parser and Log Parser Studio

Issue

IIS is either not functioning or running slow.

Cause

Several situations can be the cause.  Typically traffic to the WSVulnerability web service is the culprit.

Try browsing from a client to http://yourcoreservername/wsvulnerabilitycore/vulcore.asmx

• Database is not keeping up with requests.
• Core server is overwhelmed due to excessive traffic often caused by too many various tasks being run at once.
  • Check the schedule for Inventory, Security and Patch Scan, Frequent Security and Patch Scan, Etc.
• An errant client or clients are spamming the core with information.  The VDIR hits by IP query in Log Parser can be quite helpful to identify any outliers that are causing high IIS traffic.

Key queries to use in Log Parser Studio:

For use with W3SVC1 logs:

By default these logs are stored in C:\inetpub\logs\LogFiles\W3SVC1 by default.

• IIS: HTTP Status Codes by Count - Returns all Status Codes and how many time each one occurred
  • The HTTP Status codes can be helpful in determining the overall issue.  200.x is normal.   300.x - 500.x typically is abnormal.
• IIS: Vdir Hits by IP
  • Check to see if there are certain computers that are hitting the core excessively.   Examine what traffic is coming from those clients.  This can often by Security Activity information from Endpoint Security or LANDESK Antivirus.
• IIS: Request Per Hour
  • This can determine if there are certain times of day that traffic is especially high. 

Resolution

Look in Task Manager on the Core Server, see which W3WP process(es) are causing high cpu and or memory usage.   Turn on "Command Line" in Task Manager by right clicking a column and selecting "Select columns".

Install Microsoft Log Parser and Log Parser Studio

1. Download and install Log Parser

2. Download Log Parser Studio.   This will be in a .ZIP file.

3. Unzip Log Parser studio to a directory.  The executable file will be LPS.EXE.

I suggest you pin LPS.EXE to your taskbar and use it for IIS troubleshooting.

There are a series of IIS queries that can be quite helpful.

How to Analyze IIS logs using Log Parser and Log Parser Studio

Turn off friendly error messages in Internet Options if using Internet Explorer and browsing to the core.   This will give the HTTP error code you may be experiencing.

This article demonstrates how to troubleshoot High CPU usage from the W3WP process that is tied to the LDAppVulnerability application pool.

This article assumes that the user is running Server 2012 R2 which includes IIS 8.5.

General IIS troubleshooting information from Microsoft: Troubleshoot : The Official Microsoft IIS Site

Basic process for troubleshooting the CPU usage issue is the following:

1. Review the running W3WP processes.    (See What is the W3WP process?)
2. Review the IIS logs and look for what is causing the volume of traffic and for errors. (See Troubleshooting IIS logs)
3. Check the WSVulnerability.core.dll log for methods being called and their related information.  Information about the traffic going through the WSVulnerabilityCore web application.
4. Check the database performance.

Processes using the WSVulnerabilityCore web application

WSVulnerabilityCore is responsible for much of the information traveling from the managed client to the core server especially during the Patch and Compliance scan process, and then written to or retrieved from the database.   Among these are:

• Getting hash information for files
• Retrieving patch install and uninstall information
• Receiving DeviceID to retrieve computer information from the database
• Retrieving results of vulscan scan and repair
• Retrieving Antivirus information such as licensing, pattern file dates, quarantine and infection information, etc.
• Supplying File Reputation information.

What is the W3WP process?

W3WP.EXE processes are windows worker process that run Web Applications for IIS.  Each of these processes is responsible for handling requests sent to a Web Server for a specific application pool.

Several different W3WP processes can be found in Task Manager.  By default there will be at least two.  One servicing the LDAppMain application pool, and one servicing the LDAppVulnerability application pool.  The LDAPPVulnerability application pool services the WSVulnerabilityCore web application.

This can be seen by looking at the Advanced Settings for the WSVulnerabilityCore application in IIS.

(Click for full size)

In order to identify what the WP3WP process is assigned to, you will need to add the "Command Line" column to the Task Manager columns.

As an alternative you can open an Administrative Command Prompt, switch into the %windir%\System32\inetsrv folder (cd %windir%\System32\inetsrv) and run appcmd list wp. This will show the process identifier (PID) of the w3wp.exe process in quotes. You can match that PID with the PID available in Task Manager.

If more than one W3WP process exists tied to LDAppVulnerability, it means that more than one worker process has been assigned to the LDAppVulnerability pool in IIS.

Many performance issues can be related to an incorrectly configured application pool in IIS.  The default settings as installed by LANDESK are the recommended settings.  Outdated information exists that recommends adding worker processes, adjusting timeouts, etc.  This is not recommended.

The following screenshot demonstrates the default settings, click for full size:

(If the server is a NUMA capable server, additional options will exist. These should be left at default as well)

Troubleshooting IIS Logs

Two types of IIS logs exist:

• W3SVC1: These logs show all IIS traffic.  These are by default  stored in C:\inetpub\logs\LogFiles\W3SVC1.  Particular attention should be paid to looking at the requests that are coming in:
  • Are they repetitive in excess?
  • Do they contain error status codes?  (403, 500, etc)

Troubleshooting HTTP 400 Errors in IIS : The Official Microsoft IIS Site

• HTTPERROR: The following list identifies the kinds of errors that the HTTP API logs:   (Further information: https://support.microsoft.com/en-us/kb/820729
  • Responses to clients The HTTP API sends an error response to a client, for example, a 400 error that is caused by a parse error in the last received request. After the HTTP API sends the error response, it closes the connection.
  • Connection time-outs The HTTP API times out a connection. If a request is pending when the connection times out, the request is used to provide more information about the connection in the error log.
  • Orphaned requests A user-mode process stops unexpectedly while there are still queued requests that are routed to that process. The HTTP API logs the orphaned requests in the error log.

Troubleshooting Failed Requests Using Tracing in IIS 8.5 : The Official Microsoft IIS Site

IIS log files store the date and time using GMT (Greenwich Mean Time).  You will need to convert that to the local time of the Core Server in order to correctly interpret when the log file entries occurred. 

How to troubleshoot IIS using Log Parser Studio from Microsoft

Using the Debug Diagnostics Tool to troubleshoot High CPU Usage by a process in IIS.

Microsoft has the following article that details using their tool to troubleshoot high CPU usage.

Troubleshooting: Debug Diagnostics Tool to troubleshoot high CPU usage by a process in IIS

Microsoft Article for troubleshooting high CPU in an Application Pool

Additional article for troubleshooting High CPU in an IIS application pool:

Troubleshooting High CPU in an IIS 7.x Application Pool : The Official Microsoft IIS Site

Troubleshooting SQL Server Performance Issues

Database maintenance plans should be set up, regular indexing of the database should help keep performance up to par.

According to database performance , the following registry key can be modified to increase or decrease the number of threads that are available from the Web Service to the database:

Increasing the Number of Web Process to Database Threads

You can increase the number of threads the web service uses to talk to the database. This is by default set to "10". Be careful when setting this number, as you can overwhelm the database with web service requests. This number can be set to 40 or 50, however after doing so, monitor to make sure we are not overrunning the database.

The number of threads can be changed by adding the following registry key:

HKLM\Software\LANDesk\ManagementSuite\PatchManagement

Add a string value of "WebServiceMaxThreads) set to "40" or so. (This number may need to be adjusted)

(Caution: Be careful when modifying this registry key, and document changes to it)

Verify schedules for Inventory Scans, Patch an Compliance Scans, Software Distribution Jobs, etc.

If a lot of scheduled activities are scheduled to run at the same time, this can overwhelm the core server or the database resources.

Periods of excessive traffic can be pinpointed by gathering IIS logs and running the "Requests by hour" query.

Versions:

LANDesk Management Suite 8.7 and 8.8

Issue:

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

Resolution:

The PatchHistory table contains the date/time of each patch installation, removal, spyware removal and Antivirus action that Landesk Security and Patch Manager 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 LANDesk 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

Symptom:

Especially for those Users who have a lot of nodes managed by one core server. Their computervulnerability table is extremely big. Any actions running a  query against that table maybe very slow and possibly timeout, and may return some non-relevant errors. We need to reduce the size of that table and prevent it from growing too big/fast.

Actions:

Note: Always backup your database before making any changes to it:

1.Stop all LANDesk and Intel services on the Core Server.

2.Make a full backup of the database.

Reduce the current table size by doing:

Manually Delete all of the nondetected data according these instructions:

Delete top(x) from computervulnerability where detected = 0 and patchinstalldate is null and vul_id in (select vul_id from vulnerability where type in (1,5)).

Note: X is the number of rows you want to delete. Because this statement may be a very large delete and may require limiting the rows deleted per transaction. Otherwise this statement may timeout.

OR

Drop the patch tables in the DB

If agreed to by the LANDesk Administrator by doing the following to reload the patch data:

Warning: All patch data will be removed and reset if you run the following command. This will delete all the Scan and Repair, Antivirus, Compliance, and Windows Firewall settings. Untill those are recreated with the same ID number your clients will not be able to communicate back to the core during a Security Scan.

run "C:\Program Files\LANDesk\ManagementSuite\coredbutil.exe" /patchmanager under command line prompt.

4. Apply patch PAT-202448x.zip and run the following sql statment: This patch is included in SP3.

-INSERT INTO PATCHSETTINGS (Name,Value) VALUES('MaxPublishDaysOldToKeep',X)

-INSERT INTO PATCHSETTINGS (Name,Value) VALUES('MergeVulnerabilityResults',0)

-INSERT INTO PATCHSETTINGS (Name,Value) VALUES('FileThreshold', '0')

Note: MaxPublishDaysOldToKeep will filter out vulnerabilites that have a Published date older than the value you enter. This filter happens when IIS is processing the Scan Results from the client.  This can cause a problem when the value is set to low. It will keep a client from ever showing as detected to a older patch. Setting this to a  value of 0 turns the filter off.

Second one is the one that will be used the most.  This actually does not need to be put in the database to be turned on.  Without the database entry it is on automatically with using the files in the patch.  If the users want to turn it off then run the insert statement with the setting at 0.

Third one is for those users on 8.7 sp2 and there were changes that were in sp3 and later that did not work with the files in this patch and the version of Vulscan they were running.  If the user is on post sp3, this entry does not need to be in the database either.

5. Apply patch PAT-233338x.zip OR upgrade the core server and clients to 8.8 sp3(this patch is included in 8.8 SP3)

Run this command to the LANDesk database:

-INSERT INTO PATCHSETTINGS (Name,Value) VALUES ('DiscardUndetectedBlockedApps',1)
-INSERT INTO PATCHSETTINGS (Name,Value) VALUES('DiscardUndetectedSpyware',1)

Note: These two statements will prevent those Undetected Blocked Applications and Spyware from storing to the Computervulnerability table.

4. Create the following indexes on the database

- Create index ComputerVulnerability_Idn on ComputerVulnerability (ComputerVulnerability_Idn);

- Create index Vulnerability_Idn on Vulnerability (Vulnerability_Idn);

5. Review the SQL Tuning and Performance document: http://community.landesk.com/support/docs/DOC-2356

6. Re-index the database: http://community.landesk.com/support/docs/DOC-4362

7. Extend the query timeout on the core server to a proper time. (HKLM\SOFTWARE\LanDesk\ManagementSuite\WinConsole Create/modify the Reg_DWord 'Query Timeout' with value of X). This allowed VAMiner to deal with the customers Database slowness.

Note: X is how many seconds for every query to excute.

8.We can create some performance counters on the DB server to monitor the performance of the OS and DB:

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

-Kevin

Purpose

This article explains the behavior of optional and recommended Patch Repair tasks as they relate to the LDMS Portal

.

Symptoms

When creating a patch repair task as a policy, and setting the task to be optional or recommended in the LDMS Portal, the task may:

• Take multiple refreshes to show in the portal
• May not show in the portal at all

Cause

When a patch repair task is set as a policy, and is made optional or recommended in the LDMS Portal, the following occurs:

• The policy is made available to the client
• The client runs policy sync (clicks refresh in the portal)
• The policy is downloaded and triggers vulscan to scan for the patches in the repair task
  • A patch must be detected as 'missing' to be displayed in the portal.
• A secondary policy.xml file is created on the client containing a list of which patches were found as missing
• The client runs poilcy sync (clicks refresh in the portal)
• The second policy.xml file is parsed, and any patches listed within it are published to the portal

If 'show one portal entry with the following title:' is selected, a single entry will be created in the portal which when ran will repair all detected patches.

Note: If no patches were found as missing, no items will be shown in the portal.

If 'show each definition seperately' is selected in the scheduled tasks properties, patches will be contained per definition within the portal.

Example: Definition MS15-020_MSU contains patch kb3039066 and kb3032323.

In our test scan, both of these patches were detected as missing, but since they belong to the same definition (MS15-020_MSU), only the definition is advertised in the portal.

Because vulscan checks patches listed for repair first, and only offers those needed through the portal for repair, policysync (refresh in the portal) is required to be ran a second time after vulscan finishes its scan.

Running policysync (refresh in the portal) prior to vulscan completing its scan will not populate any items in the portal.

If policysync (refresh in the portal) is not manually ran, it will be ran on its scheduled interval as defined in the agents settings.

Purpose

This article covers information on how Agents know where to download a patch from when Vulscan is running a vulnerability repair.

Info

When Vulscan runs, it compiles its results of missing patches into a *.vrz file that is posted to the Core. The results are stored in the DB in various tables.

HTTP POST: http://96-CORE3.evdomain.local/incomingdata/postcgi.exe?prefix=vulscanresults\&name=ScanResults_{FE495D5D-404A-234C-9CAB-697F258E8DB7}_96-CORE3_v482.vrz

When Vulscan gets to the point of requesting patches from the core to download, it will first post to a web service method:

http://corename/wsvulnerabilitycore/vulcore.asmx

And it will then post to GetPatchesForGroup(), providing Computer_idn and GroupID.

Example:

Computer_Idn = 2454

GroupID = 96-core3_v482

Note: The above can be simulated with a SOAP test.

When the core receives the request, it will check the DB for for the Computer IDN and Group ID that it received, and compile a list of patches for the scan.

It uses the GroupID to get the CustomGroup:

exec sp_executesql N'SELECT cg.CustomGroup_Idn from CustomGroup cg WHERE cg.Guid = @1',N'@1 nvarchar(13)',@1=N'96-CORE3_v482'

The returned CustomGroup_Idn is then used to get a list of applicable patch information for the Computer_IDN.

exec sp_executesql N'SELECT p.UniqueFilename, p.URL, p.Hash, p.Sha1, p.Sha256, p.Commands, p.Patch_Idn, v.Vendor, v.Lang, v.Type, v.PublishDate, v.Title, v.Vul_ID, cv.Patch, cgv.InstallOrder                                    FROM CVDetected cv (nolock), Vulnerability v (nolock), Patch p (nolock) , CustomGroupVuln cgv                                    WHERE p.UniqueFileName = cv.Patch AND p.Vulnerability_Idn = v.Vulnerability_Idn                                    AND cgv.Member_Idn = v.Vulnerability_Idn AND cgv.CustomGroup_Idn in (176)                                    AND cv.Vulnerability_Idn = v.Vulnerability_Idn                                    AND p.Ignore = 0                                    AND cv.Computer_Idn= @1                                                                  ORDER by cgv.InstallOrder,v.PublishDate,p.Name',N'@1 int',@1=2454

Next the Patch Repository location is pulled from the PatchSettings Table. This is the value stored in Patch and Compliance | Download Updates | Patch Location | Web URL or UNC Path where clients access patches.

Select Value
From PatchSettings
Where Name = 'PatchesURL'

Then the PatchesURL is is appended to the UniqueFile name, which is returned to the Client as a Unique File name to be used to download the patch. This file path is visible in the Vulscan log.

Thu, 01 Oct 2015 11:24:54 Adding default path '\\96-core3\ldlogon\patches\windows8.1-kb3030377-x64.msu' as source for patch: windows8.1-kb3030377-x64.msu

Purpose

This document outlines how to import and export LDMS Patch Content/Definitions. This can be useful to know when moving content between LDMS Cores.

Example:

• Export Custom Definitions on one Core, and import for use on a second Core.
• Import new Content from LDMS when testing for detection issues.

Export Content

• In the LDMS Core select Tools | Security and Compliance | Patch and Compliance
• In the Patch and Compliance window select the Content(s) to be exported
• Right click the Content(s) highlighted, and choose Export

• In the Select Export Filename window navigate to the directory you want to save the file to
• The Filename will automatically show the name of one of the selected Content items. You can change the name as needed. Keep the file extension as *.ldms.
• Choose Save

• The Export Status window will display the progress.
• When the Export Status window indicates Done, click Close.

The content is now available as a single *.ldms file that can be copied to other LDMS Cores and imported for use.

Note: If multiple Content items were exported together, they will all exist within a single *.ldms file.

Import Content

• In the LDMS Core select Tools | Security and Compliance | Patch and Compliance
• In the Patch and Compliance window right click the Scan folder and choose Import

Note: Content can be imported into any folder or group by right clicking, but must be set to 'Scan' to be included in a patch scan.

• In the Select File to Import window, set the filter to match your content file's extension.
• Next select the content file to be imported and click Open.

Note: Content Exported from an LDMS core will typically have the extension *.ldms. Content received while troubleshooting a content detection issue will typically have the extension *.xml.

• In the Import Options window select Update and click Import.

• When the Import Status window displays Done, click Close.

The imported content is now available for use within the LDMS Core.