Issue

Error: "Failed. Cannot Interpret Data" or "Unable to process vulnerability data stream" occurs while running a Security and Compliance scan (vulscan)

If running a "Security/Compliance scan" task from the Core or Console, the result column may show "Unable to get vulnerability definitions from the core"

The Vulscan.log may show the following:

240 Getting definition data from core <coreservername>
Wed, 23 Sep 2009 13:19:20 HTTP POST: http://<coreservername>WSVulnerabilityCore/VulCore.asmx
Wed, 23 Sep 2009 13:19:26 Success
240 VulnerabilityData::GetData: Unable to process vulnerability data stream
240 Skipping repair step because scan errors occurred.
Failed

Cause

This is due to a failure in the process of creating, compressing, transferring, or parsing the .XML data the client uses to determine what to scan for, or the details of what to repair.

The following basic process occurs:

1. Vulnerability scan runs on the client.

2. The client requests vulnerability data from the core server (basically a set of instructions of what to scan for).    (This depends on IIS connectivity)

3. The server receives client information such as operating system, and what type of vulnerabilities the client is configured to scan for.  (This depends on IIS connectivity)

4. A lookup to the database occurs and the XML data is written to XML based on the database lookup.  (This depends on database connectivity and performance)

5. The XML data is compressed to an .XMLZ file  (This depends on LDZIP.DLL functioning properly)

6. XML data is transferred to the client.  (This depends on IIS connectivity, and proper sharing and NTFS permissions on the VulnerabilityData folder)

7. The XML data is unzipped and parsed at the client and utilized by the vulnerability scanner.

Any one of these steps can be a failure point.

Troubleshooting

Log Files Used for Troubleshooting

There can be various causes for this issue.  The following sections will list the various causes and possible resolutions:

Reset Internet Information Services

As vulnerability data information is processed by IIS, it is a good first step to do an "IISRESET" from the command line on the core server.  There have been instances where IIS is either not functional, or has gotten into a bad state where it hands out stale data.

Core Server Reboot

Often rebooting the core server will clear up an issue like this.  This should be attempted before changes are made.

Incorrectly configured Application Pool in IIS or faulty .NET Framework Installation

LANDESK client computers utilize the WSVulnerabilityCore web service for various Vulnerability Scan functions, including retrieving Vulnerability Data information.  This depends on the Application Pool being configured properly.

The Default application pool used by the WSVulnerabilityCore web service is called "LDAppVulnerability".  The identity (account) used by the LDAppVulnerability application pool should be set to "Network Service".

If the identity is incorrect for the LDAppVulnerability Application pool, this can be modified by highlighting the application pool and selecting "Advanced Settings"  It will then be listed under "Process Model" and then "Identity"

Anonymous access should also be enabled for the WSVulnerabilityCore application in IIS.  To verify this, highlight "WSVulnerabilityCore" within the IIS Connections tree and then double click "Authentication" in the right-hand pane and verify that "Anonymous Authentication" is set to "Enabled".

Additionally, the .NET Framework may need to be re-registered and IIS reset as pictured below (Note: The directory for the .NET Framework version may vary)

For core servers running on Windows Server 2003, it is also important that the Core Server was not renamed after IIS installation.  Verify that the IUSR_<coreservername> and IUSR_<coreservername> accounts truly match the current name of the core server.  (Check account names in IIS Manager or Computer Management vs. what is returned by running "hostname" in a command prompt" window.

Additional information regarding the Optimization of IIS can be found here.

Due to the WSVulnerabilityCore web application utilizing the "Network Service" account to write data to the VulnerabilityData folder, the permissions for the LDLogon folder (and VulnerabilityData as a child folder) must allow "Full Control" to the "Network Service" account.

If writing of the Vulnerability Data to the VulnerabilityData folder fails due to permissions, the following error may appear in the WSVulnerabilityCore.dll.log file on the core server:

RollingLog : System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\LANDESK\ManagementSuite\LDLogon\VulnerabilityData' is denied.

  at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

  at System.IO.Directory.InternalGetFileDirectoryNames(String path, String userPathOriginal, String searchPattern, Boolean includeFiles, Boolean includeDirs, SearchOption searchOption)

  at System.IO.Directory.GetFiles(String path, String searchPattern, SearchOption searchOption)

  at LANDESK.ManagementSuite.PatchBiz.XML.StreamHelper.DeleteOldFilesExcept(String p, String wildcard, Int32 ageInMinutes, String[] filesToIgnore)

  at LANDESK.ManagementSuite.WSVulnerabilityCore.VulnerabilityData.Serialize(String type, String platform, String language)

  at LANDESK.ManagementSuite.WSVulnerabilityCore.VulCore.GetVulnerabilitiesOfTypeInternal(String type, String platform, String language, Int32 lastUpdated)

INFO  772:3    RollingLog : System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\LANDESK\ManagementSuite\LDLogon\VulnerabilityData' is denied.

  at LANDESK.ManagementSuite.WSVulnerabilityCore.VulCore.GetVulnerabilitiesOfTypeInternal(String type, String platform, String language, Int32 lastUpdated)

  at LANDESK.ManagementSuite.WSVulnerabilityCore.VulCore.GetVulnerabilitiesOfTypeCompressed(String type, String platform, String language, Int32 lastUpdated)

The default permissions for the VulnerabilityData folder are inherited from the parent LDLOGON directory and are as follows:

Note: Permissions should be verified for BOTH the LDLogon and VulnerabilityData folders

In addition the following share permissions for\Program Files (x86)\LDLOGONmust be present and inherited by VulnerabilityData:

Note: Permissions should be verified for BOTH the LDLogon and VulnerabilityData folders

For detailed information on the proper permissions that should be applied to directories, seethis article.

Local Security Policy "Adjust memory quotas for a process" user rights assignment

Open the Local Security policy editor by going to Start --> Run and type "secpol.msc".  Then browse to "Local Policies" and User Rights Assignment

Within the Local Security Policy editor, check that the "Adjust memory quotes for a process" user rights assignment is assigned to the following accounts:

Administrators

LOCAL SERVICE

NETWORK SERVICE

SQLServer20XXMSSQLUser$ServerName$DatabaseInstanceName

Note: The SQL Server account name will vary based on SQL version, server name, and Database instance name.

Client cannot connect to \\CORESERVER\LDLOGON\VulnerabilityData or browsehttp://coreserver/wsvulnerabilitycore/vulcore.asmx

The LANDESK client needs to be able to access the\\CORESERVER\LDLOGON\VulnerabilityData folder on the core server to download the Vulnerability data .XMLZ files.

A basic connectivity test can be done by browsing from a web browser on the client to\\Coreserver\LDLOGON\VulnerabilityData.  This should result in a directory listing displaying various .XML and .XMLZ files.  If this does not appear, a note should be taken on any HTTP errors that appear.

In order to see detailed information about errors in Internet Explorer, "Show Friendly HTTP Error Messages" should be disabled.  (Tools --> Internet Options --> Advanced --> and then uncheck "Show friendly HTTP error messages")

In addition the client should be able to browse tohttp://coreserver/wsvulnerabilitycore/vulcore.asmx from a web browser.  If this fails, permissions for the "Everyone" group and for "IUSR" should be verified on the LDLOGON and VulnerabilityData folders.

The LANDESK vulnerability scanner calls the WSVulnerabilityCore web service and uses a SOAP request for "GetVulnerabiilitiesOfType" and requests vulnerabilities for the type of definition (Windows Vulnerabilities, LANDESK Updates, etc) and for the Platform (operating system) the client computer is running.

On the core server, The IIS log file on the core server can be useful for troubleshooting:

Run a vulnerability scan and then check the following log on your core server:

C:\inetpub\logs\LogFiles\(latest log file)

Within this log file there will be lines similar to the following:

2009-12-02 17:58:21 W3SVC1 192.168.0.69 GET /ldlogon/VulnerabilityData/0_win2k3_ENU.1259766918.xmlz - 80 - 192.168.0.1 3200-LANDESKDownloader 206 0 0

If the HTTP result code (A red "206" in the example above) is in the 400's or the 500's, this can indicate a server-side error.

An internet search of "HTTP ERROR CODES" can aid in diagnosis.

Vulnerability Data corrupt on the core server

The vulnerability data may be corrupt on the core server.  This can be suspected if all clients are experiencing the same symptom, as opposed to a smaller group of the whole.

Delete all files \\CORESERVER\LDLOGON\VulnerabilityData and then reset IIS (or recycle the LDAPPVulnerability application pool)  When the next client runs a vulnerability scan this data will be rebuilt.

Note: Running an IISReset or recycling the application pool is necessary because IIS caches requests.

Vulnerability Data on client is corrupt and client is not updating to new data

Run a "vulscan /reset" on the client.  This will delete all settings and vulnerability data on the client and will force the settings and data to be re-downloaded.

A definition within a particular category is corrupt

1. Run a "vulscan /scan=0 /showui", "vulscan /scan=4 /showui", etc.  Does it fail for any one type of definition?

(/scan=# tells the vulnerability scanner to scan only one type of definition.  Example: 0=Windows Vulnerabilities, 4=Custom Vulnerabilities)

See this article for further information on Vulscan switches.

It is possible for a particular definition within the database to be corrupt. 

1. Run a "vulscan /scan=0 /showui", "vulscan /scan=4 /showui", etc.  Does it fail for any one type of definition?

(/scan=# tells the vulnerability scanner to scan only one type of definition.  Example: 0=Windows Vulnerabilities, 4=Custom Vulnerabilities)

See this article for further information on Vulscan switches.

If it is found that the scan fails for only a particular definition type, it may be necessary to force a redownload of content for that type.

In order for this to occur, the revision for the definitions must be set to 0.  Once this is done, the next time patch content is downloaded to the core server, the core will compare it's revision to the revision on the patch content server and redownload the definitions.

The following SQL query must be done against the database:

update vulnerability set revision = 0 where type = type#

    Note: type# refers to the type of definition and should be replaced with a numerical value - (0 - vulnerabilities, 1- Spyware, 2 - Security Threats, 3- LANDESK Updates, 4 - Custom Definitions, 5 - Blocked Apps, 6 - Drivers, 7 - Antivirus)

After running the SQL query a content download for definition type must be done.

The patch forKB973917has been installed on the Core Server

Refer to the following community article for the fix.

MSXML installation corrupted or missing on client

In order for the VulnerabilityData .XML files to be downloaded and properly parsed by the client, the MSXML installation must be functioning properly on the client.

Obtain the latest MSXML version and install on the client.

The LDZIP.DLL in \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin on the core server is missing, has incorrect permissions, is corrupt, or not up to date.

The vulnerability data is compressed by the core and saved in the form of a "compressed XML" file.  If anything interrupts the proper operation of LDZIP.DLL, failure can occur.

If this is the case, the WSVulnerabilityCore.dll.log file (In the ...\LANDESK\ManagementSuite\log\ direcotry ) on the core server will likely show the following error:

System.EntryPointNotFoundException: Unable to find an entry point named 'LDCompressFile' in DLL 'ldzip.dll'.
at LANDESK.ManagementSuite.WSVulnerabilityCore.VulnerabilityData.LDCompressFile(String fileIn, String fileOut)
at LANDESK.ManagementSuite.WSVulnerabilityCore.VulnerabilityData.SerializeToFile(String filename)
at LANDESK.ManagementSuite.WSVulnerabilityCore.VulnerabilityData.Serialize(Int32 type, String platform, String language)
at LANDESK.ManagementSuite.WSVulnerabilityCore.VulCore.GetVulnerabilitiesOfType(Int32 type, String platform, String language, Int32 lastUpdated)
System.EntryPointNotFoundException: Unable to find an entry point named 'LDCompressFile' in DLL 'ldzip.dll'.
at LANDESK.ManagementSuite.WSVulnerabilityCore.VulCore.GetVulnerabilitiesOfType(Int32 type, String platform, String language, Int32 lastUpdated)
at LANDESK.ManagementSuite.WSVulnerabilityCore.VulCore.GetVulnerabilitiesOfTypeCompressed(Int32 type, String platform, String language, Int32 lastUpdated)

1. Compare the Version of the LDZIP.DLL in \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin with the one in \Program Files\LANDESK\ManagementSuite.

2. If the LDZIP.DLL in \Program Files\LANDESK\ManagementSuite is newer than the one in \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin, copy the LDZIP.DLL from \Program Files\LANDESK\ManagementSuite to \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin

3. From the command prompt run "IISRESET".

The permissions on the LDZIP.DLL file should match the permissions of the VulnerabilityData folder in the table earlier in the article, with the exception that "Everyone" should not be in the list.

Patchbiz.dll in \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin on the core server is missing, has incorrect permissions, is corrupt, or not up to date.

1. Compare the Version of the LDZIP.DLL in \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin with the one in \Program Files\LANDESK\ManagementSuite.

2. If the PatchBiz.dll in \Program Files\LANDESK\ManagementSuite is newer than the one in \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin, copy the LDZIP.DLL from \Program Files\LANDESK\ManagementSuite to \Program Files\LANDESK\ManagementSuite\wsvulnerabilitycore\bin

The permissions on the PatchBiz.dll file should match the permissions of the VulnerabilityData folder in the table earlier in the article, with the exception that "Everyone" should not be in the list.

Remove the /3GB switch from the BOOT.INI file on the Core Server

BOOT.INI is a hidden system file at the root of the system drive.

Reboot the Core Server after removing the switch.

• • Issue
  • Resolutions
    • The identity of the application pool does not have the Replace a process level tokenuser right.
    • Incorrect alternate Core Server name specified in Scan and Repair settings
    • Core Server Reboot
    • IIS Configuration and/or Permissions Issue
    • Modifying the Identity used by the WSVulnerability Application Pool
      • ASP.NET and CBA_anonymous accounts
    • Database credentials are incorrect
    • GPO Policies on Core Server
    • IP Address or Domain Name Restrictions in IIS
    • Ensure that the proper Web Service Extensions are enabled
    • Patchbiz.dll versions not in sync with other patch manager related files

Issue

The error "Server Busy... retrying" or "Server Busy... Failed." appears when running a vulnerability scan.

The Vulscan.log (Located in C:\Documents and Settings\All Users\Application Data\Vulscan) may contain lines similar to the following:

Thu, 03 Dec 2009 16:45:57 Action SOAPAction: "http://tempuri.org/ResolveDeviceID" failed, socket error: 0, SOAPCLIENT_ERROR: 5.  Status code: 503, fault string:  616   Retrying in 9 seconds...

Resolutions

There can be various causes for this issue.  It mainly centers around connectivity from the core to the client to the proper web services and web pages.

The identity of the application pool does not have the Replace a process level tokenuser right.

This cause usually results in an HTTP 403.19 error. If you are seeing this error in the IIS logs please review this Microsoft KB Article.

http://support.microsoft.com/kb/942048

Incorrect alternate Core Server name specified in Scan and Repair settings

Verify what Scan and Repair Settings the client is using.

Open that Scan and Repair setting and check the server name under "Communicate with alternate core server" on the Network Settings tab.

Core Server Reboot

Often rebooting the core server will clear up an issue like this.  This should be attempted before changes are made.

IIS Configuration and/or Permissions Issue

At this stage in the Vulnerability Scan process, the Vulnerability Scanner attemps to contact the core at http://<coreservername>/WSVulnerabilityCore/VulCore.asmx.

A basic connectivity test can be done:

1. In Internet Explorer go to Tools --> Internet Options --> Advanced and uncheck the box next to "Show friendly HTTP error messages." 

2. Browse from Internet Explorer on the client to http://<coreservername>/WSVulnerabilityCore/VulCore.asmx.

Take note of any error that appears.  If the page returns normally, it should look something like this:

If this fails, directory and virtual directory missions should be verified within IIS (Internet Services Manager) on the core server.

For information on the proper permissions that should be applied to directories, see this article.

Additionally, the .NET Framwork may need to be re-registered and IIS reset as pictured below (Note: The directory for the .NET Framework version may vary)

The web services log file on the core server can be useful for troubleshooting:

Run a vulnerability scan and then check the following log on your core server:

c:\windows\system32\logfiles\w3svc1\(latest log file)

Within this log file there will be lines similar to the following:

2009-12-03 23:48:59 W3SVC1 192.168.0.69 POST /WSVulnerabilityCore/VulCore.asmx - 80 - 192.168.0.45 Microsoft-ATL-Native/8.00 200 0 0

If the HTTP result code (A red "200" in the example above) is in the 400's or the 500's, this can indicate a server-side error.

An internet search of "HTTP ERROR CODES" can aid in diagnosis.

It is also important that the Core Server was not renamed after IIS installation.  Verify that the IUSR_<coreservername> and IUSR_<coreservername> accounts truly match the current name of the core server.  (Check account names in IIS Manager or Computer Management vs. what is returned by running "hostname" in a command prompt" window.

Modifying the Identity used by the WSVulnerability Application Pool

At times there have been Group Policy changes that have restricted the rights to the "Network Service" that the Application Pool normally uses.  Changing this Identity to use "Local System" has at times resolved this issue.

1 - In the IIS manager, if you have not already create a new application pool then add the wsvulnerability web service to it. If you already have the pool then skip this step 1.
2 - On the application pool for WSVulnerability right-click and select properties.
3 - On the properties window select the Identity tab.
4 - Change the Predefined to "Local System"
5 - Open a Command Prompt and run "IISRESET"

Additional information regarding the Optimization of IIS can be found here.

Description

When running a Security Scan on the clients, vulscan returns the above error and the window closes. This happens on every device. The vulscan.log file reads: "Action SOAPAction: "http://tempuri.org/GetHashForFile" failed, socket error: 0, SOAPCLIENT_ERROR: 7. Status code: 500, fault string:"

ASP.NET and CBA_anonymous accounts

On the core server, make sure that the local accounts ASP.NET and cba_anonymous are created and enabled.

Database credentials are incorrect

1. Ensure that the Core server is pointed to the right database.
2. Ensure that the proper credentials are configured on the core in Configure Services | General Tab | Database

GPO Policies on Core Server

• Go to Start | Administrative Tools | Local Security Policy.
• Expand Local Policies.
• Highlight User Rights Assignment

Make sure that the Adjust memory quotas for a process value provides permissions for these accounts:

• Local Service
• Network Service
• IWAM_SERVERNAME
• Administrators

Note: These are the default accounts. The Application pool is running as Network Service and requires this ability.
Note: To test if this is the cause, set the identity of the Application Pool to be Local System. If this works, then permissions is definitely the cause.
Note: It may be necessary to put the Core Server in its on OU and have absolutely no GPOs applied to the OU, not even the default policy.

IP Address or Domain Name Restrictions in IIS

1. Using the Internet Service Manager (Microsoft Management Console), open the Internet Information Server (IIS) snap-in and select the Web site reporting the 403.6 error. Right-click the Web site, virtual directory, or file where the error is occurring. Click Properties to display the property sheet for that item.
2. Select the appropriate Directory Security or File Security property page. Under IP Address and Domain Name Restrictions, click Edit.
3. In the IP Address and Domain Name Restrictions dialog box, if the Denied Access option is selected, then add the IP address, network ID, or domain of the computer that requires access to the exceptions list.
4. In the IP Address and Domain Name Restrictions dialog box, if the Granted Access option is selected, then remove the IP address, network ID, or domain of the computer that requires access to the exceptions list.

Ensure that the proper Web Service Extensions are enabled

On the Core Server in IIS ensure that the following Web Service Extensions are enabled:

Patchbiz.dll versions not in sync with other patch manager related files

Install the latest Service Pack for your version of the Product

• • Details
  • Log Locations
  • Cannot connect to LANDESK Patch Content servers and/or vendor patch download locations
  • Vulnerability content category not showing up in the Download Updates window
  • A particular vendor's updates fail to download
  • Error when downloading content "Hash for patch does not match with host. Discarding."
  • Error: "Waiting for file lock" when downloading patch content
  • How to exclude scanning of patches from a certain vendor
  • How to change the default patch download location
  • Error: "Object does not match the specified SHA-256" hash
  • Error: "You have not specified a site from which to download updates" when downloading updates in Patch Manager

Details

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 is logged to the following log files on the core server:

• \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 downloads are also logged in the following log files:

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

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

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

• 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 host names.  In addition the LANDESK core server will contact the following addresses:

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

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

• Downloads-us##.kaspersky-labs.com
• dnl-##.geo.kaspersky.com
• Downloads#.kaspersky-labs.com

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)

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

Note: Some proxy servers require authentication protocols not supported by LANDESK (such as NTLMv2, etc)

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 --> LANDESK --> and run "Core Server Activation"
2. Within the "Activate LANDESK 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 LANDESK Support to investigate further.  If either is expired, contact your Sales Representative or the Licensing Queue at LANDESK 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 LANDESK Support.

A particular vendor's updates fail to download

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 LANDESK patch content, consult this article.

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

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

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

"Waiting for file lock" error 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 Managementsuite 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%'

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. 
  (Note, 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 article Patch Download Settings - custom settings reverted back to original options

How to change the default patch download location

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

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

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.

Symptoms:

• When launching Download Updates, the Definition types and/or Languages column are missing entries, and only show:

do not remove.  required to make scrolling work right.

do not remove.

• Other Tabs within Download Updates may be empty as well.
• If trying to choose Download Now it fails with message:

The UNC path to which the core will write patch files () is not a valid UNC path.

From "C:\Program Files\LANDesk\ManagementSuite\log\Console.exe.log"

Main Thread RollingLog : ERROR: Unable to find DefTime in LdBasesInfo.xml
Main Thread RollingLog : Critical Exception: System.FormatException: Input string was not in a correct format.
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at LANDesk.ManagementSuite.PatchBiz.Antivirus.AVBases.ŸŠ()
at LANDesk.ManagementSuite.PatchBiz.Antivirus.AVBases..ctor(BasesType basesType)
at LANDesk.ManagementSuite.PatchBiz.XML.UpdatesList..ctor(BasesType basesType)
at LANDesk.ManagementSuite.AVUI.AVActionsRequired.RequiresDefinitionAction()
at LANDesk.ManagementSuite.AVUI.AVActionsRequired.RefreshActionsAreRequiredInfo()
at LANDesk.ManagementSuite.AVUI.AVActionsRequired.timer_Tick(Object sender, EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) Stack Trace: at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at LANDesk.ManagementSuite.PatchBiz.Antivirus.AVBases.ŸŠ()
at LANDesk.ManagementSuite.PatchBiz.Antivirus.AVBases..ctor(BasesType basesType)
at LANDesk.ManagementSuite.PatchBiz.XML.UpdatesList..ctor(BasesType basesType)
at LANDesk.ManagementSuite.AVUI.AVActionsRequired.RequiresDefinitionAction()
at LANDesk.ManagementSuite.AVUI.AVActionsRequired.RefreshActionsAreRequiredInfo()
at LANDesk.ManagementSuite.AVUI.AVActionsRequired.timer_Tick(Object sender, EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Cause:

One or more LdBasesInfo.xml is corrupted.

• C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Mac\basesEP\LdBasesInfo.xml
• C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Mac\pre.basesEP\LdBasesInfo.xml
• C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Win\bases8\LdBasesInfo.xml
• C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Win\basesEP\LdBasesInfo.xml
• C:\Program Files\LANDesk\ManagementSuite\ldlogon\antivirus8\Win\pre.basesEP\LdBasesInfo.xml

Solution / Workaround:

• The corrupt file must be renamed.
  • Option 1
    • Navigate to each of the LDBasesInfo.xml files, and verify their contents. If one is empty, it is corrupted.
• Option 2
  • Rename all LDBasesInfo.xml files so they can be recreated.

• After the offending file has been renamed, close and reopen the Console, then relaunch the Download Updates window.
• If all corrupt files were renamed, they will be recreated at launch, and the display should show correctly.

This document assumes that you are getting started with patching, or that you are redesigning your patch processes at a high level.  Before applying any patches you should familiarize yourself with the LANDesk patching process and capabilities.  Here are several related documents to help you get started:

LANDESK Management Suite 9.5 patch & compliance documentation

LANDESK Management Suite 9.6 patch & compliance documentation

Patch Manager- Strategic and Tactical Implementation Guide

Due to varying requirements and computing environments your patching process needs to be tailored to your environment and needs.  This document serves to provide a general guideline for setting up baseline patching.  Your individual needs may vary. 

A baseline patch group will include minimal patch definitions that apply to computers and applications in your environment.  By design it applies to newly imaged computers containing your baseline production applications and serves to bring them up to a minimal standard of compliance before being released to your production environment.  Patches in this group are tested against baseline computers in your environment and are known to be safe to apply without unintended consequences.  

Here are the steps to get started:

• Build baseline computers with your standard OS image and all production applications installed. You should have baseline computers for all your major OS versions. These can be virtual machines, or physical.
• Download all applicable patch content and move all definitions to the scan folder. Ensure autofix, do not scan, and unassigned folders are empty. Create a custom group for Baseline Patch Definitions.
• Run a security scan on your baseline computers. This will detect what patches are required for these computers and applications but will not install any patches.
• Once completed view the Security and Patch Information for your baseline computers. Select every definition in "All Detected" and drag it to your Baseline Patch Definitions custom group.
• Look through this group and remove definitions (if any) which you know will break things in your environment. You can search by vendor, or any other column that is useful. Move any bad definitions to Do Not Scan and delete them from your custom group.
• Determine whether to apply patches for vendor products such as Adobe, Firefox, Chrome etc.  Move definitions which you will not apply to Do Not Scan and delete them from your custom group.
  
• Look at all patches marked "Manual" and determine if they are needed in your environment. If so, manually download the patches from the vendor. If not, move to Do Not Scan and delete the definition from your custom group.
• Right-click the Baseline Patch Definitions group and select Repair. Create a repair task for this custom group, ensuring you have downloaded all patch files as needed, including manual patches that you want to apply.
• Run this task on your baseline computers using Agent Settings that allow reboot.  This will take some time and possibly several reboots as several hundred patches will likely be installed.
• Investigate and remediate any failed patches, and ensure that no patches have caused unintended consequences for your baseline machines. Ensure none of your production applications have broken due to patches.  Move on only after you have validated that all patches are safe for your baseline computers.
• Move all definitions in your Scan folder back into the unassigned folder. Then, click on your Baseline Patch Definitions group, select all definitions and move them back to the scan folder. This assures you are only scanning against definitions that you have tested and which are needed to establish your baseline (so far).
• In the Download Updates window, check the box to "Put new definitions in 'unassigned' group" so that newly downloaded patches are not automatically set to scan.  You may change this later as you design and implement your continuing patch processes.

Your Baseline Patch Definition group is now complete and you are prepared to start baseline patching for newly imaged computers, or to catch up unpatched computers in your environment.  You can run baseline patches during OS provisioning by adding a Patch System action to your template.  This video provides more information on this action:

How to use the LANDESK OS Provisioning "Patch System" action

You will want to design your production patching process according to your needs.  You will need to investigate the remaining definitions in the "unassigned" folder and determine whether to scan and repair them or move them to Do Not Scan.  As you design your continuing patch process, make effective use of additional custom groups and Definition group settings to reduce your management workload.

Before applying baseline patches to your production environment you should apply them to a larger patch pilot group for further testing, and to eliminate any potential patch issues that would affect your users or break applications.  It is vital to be aware of your environmental needs and make educated determinations regarding which patches you apply and the potential consequences of them all. 

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

Vulscan Switches for Windows Agents

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

Vulscan switches to control scan types

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

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

General Switches

Reboot related operations

VBScript related options

Disable certain behaviors

Manipulate Data Files

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

LANDESK Endpoint Security Related Commands

LANDESK Antivirus related commands

Shortcuts to open folders or logs:

Vulscan switches used for content replication

Note:

Landesk references Windows API to determine whether or not a Windows device needs a reboot. Having a Landesk agent installed on your device allows the device to present a Landesk reboot GUI if a reboot is pending and if your Landesk configuration allows the reboot prompt.

Issue

When performing tasks such as patch scans or repairs, the LDMS Agent is prompting that a reboot is required. This may occur every time a task is ran.

Cause

This is typically caused by the presence of one or more registry keys that indicate a Reboot is pending.

• PendingFileRenameOperations Registry Key

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager]
"PendingFileRenameOperations"

• "C:\ProgramData\vulscan\vulscan.log" shows:

Pending file rename data is present.  Reboot is needed.

• Vulscan Reboot Registry Key

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\WinClient\VulscanReboot ]

• "C:\ProgramData\vulscan\vulscan.log" shows:

Vulscan reboot key exists. Reboot is needed.

Any file modifications made by Landesk or by another installer that requires a reboot will populate values in the registry that must be cleared to alleviate the need for a system restart. If the Agent is not instructed to ignore these, it will prompt users every time vulscan runs as it first checks to see if there is a 'Reboot Required'.

Solution / Workaround

There are 3 ways to correct this issue.

Reboot the Computer

Set Agent to Ignore the Reboot Keys

Delete Reboot Keys

Additional Info: How to Manually Verify Agent's 'Repair if Reboot is Pending' Setting

1. Reboot the computer

This is the ideal solution. These keys are created when a task is unable to be performed in its entirety. Things such as file rename or deletions may not be able to occur while system resources are accessing them. When the machine reboots, it will release the locks on the files, and allow any residual effects to complete. This can be critical in situations such as installing new patches.

2. Set Agent to Ignore the Reboot Keys

• Open the Agent's Distribution and Patch settings.
• Navigate to Patch-only settings | Install/remove options.
• Click the check box that says Start repair even if Reboot is already pending.
• Click Save.
• The next time Vulscan runs, it will update its Distribution and Patch settings, and should ignore Reboot Keys if detected.

Note: If a reboot is pending for a prerequisite to the current task, the current task runs the risk of failing. Use this option with discretion

3. Delete the Reboot Keys

    

This option should be considered a last resort. Reboot registry keys are created because a task was unable to perform all file changes when it tried to do so. Deleting the registry key runs the risk of the final file changes never occuring. If a key needs to be manually removed for testing purposes, it is recommended to make a backup of the key first, and restore it to the registry after testing concludes so file changes may have the opportunity to run.

Additional Info: How to Manually Verify Agent's 'Repair if Reboot is Pending' Setting

In the event an agent does not appear to be behaving how its agent settings indicate it should (i.e. reboots when told to ignore them), the AgentBehavior .xml file can be checked.

• On the Core, locate the Agent's Distribution and Patch Setting, Right click and choose Properties.
• In the Properties, in the lower right corner locate the ID:

Example: ID: 96-CORE3_v428

• The ID value corresponds to an *.xml file that defines the Behavior for the Agent.
  • Core - "C:\Program Files\LANDesk\ManagementSuite\ldlogon\AgentBehaviors\AgentBehavior_{ID}.xml"
  • Agent - "C:\ProgramData\vulscan\AgentBehavior_{ID}.xml"

Example:

• Core - "C:\Program Files\LANDesk\ManagementSuite\ldlogon\AgentBehaviors\AgentBehavior_96-CORE3_v428.xml"
• Agent - "C:\ProgramData\vulscan\AgentBehavior_96-CORE3_v428.xml"

• Within the AgentBehavior_{ID}.xml file is an element called 'ignorePendingFileRename'.
• If this value is set to True, it will allow vulscan to perform tasks even if the Reboot Registry Keys are present.
• If this value is set to False, it will prompt the user about Reboots if the Reboot Registry Keys are present.

Example:

Start repair even if Reboot is already pending is CHECKED

<Name>ignorePendingFileRename</Name><Val>true</Val>

Start repair even if Reboot is already pending is UN-CHECKED

<Name>ignorePendingFileRename</Name><Val>false</Val>

Patch Install Succeeded:

Code 0 = Unknown or Not Installed

Code 1 = Failed

Code 2 = Successful

Patch Currently Installed:

Code 0 = No

Code 1 = Yes

Code -1 = The patch installation cannot be detected. (Because the vulnerability does not have any patch installation detection rules)

Patch Detected:

Code 0 = Not detected

Code 1 = Detected (selected vulnerability has been detected)

Important Notices

• About LANDESK support program for Windows XP patch content

Initial Install and Configuration

• LANDESK Management Suite 9.6 patch & compliance documentation
• Getting Started with Patch Manager in LDMS 9.6
• Patch Manager- Strategic and Tactical Implementation Guide.pdf
• Achieving Security Maturity
• LANDESK Security and Compliance Manager - List of URL sources for downloaded patches
• How to change the default Patch Location for Security and Patch Manager?
• How to change the Default Distribution and Patch Settings
• How to repair vulnerabilities using a pre-cache task (install from local cached file or peers instead of from the source)
• How to manage superceded patches in Security and Compliance Manager
• How to use Custom Groups and Blocked Applications.
• How to schedule a Security Scan
• How to Scan and/or Repair against a custom group

Patch content information

• How to request new content be added to Patch and Compliance Manager
• How to report LANDESK Patch Manager vulnerability detection problems to technical support
• How to troubleshoot Core Server patch content download issues
• LANDESK Patch Content severity levels
• Products and Applications available through LANDESK Security and Compliance content delivery
• LANDESK Security and Compliance Manager - Microsoft Superceded Patch Report
• How to create a Custom Vulnerability Definition in Security and Compliance Manager
• Issue: Definition types missing from the download updates window.

Additional Options and Information

• How to uninstall Patches through Patch Manager
• About the Registry Keys that are checked to see if a reboot is needed
• LANDESK Patch Content severity levels
• About Vulscan switches for Windows clients
• About LANDESK Distribution and Patch settings
• About the Vulnerability scan and repair logs
  
  

Videos

• [Tech Brief Recording]  Best Practices using LANDESK Patch Manager
• Creating a distribution and patch agent setting video tutorial
• Download Updates Tool Video Tutorial
• Application Blocking Video Tutorial
  
• Video: How to use the Disable Replaced Rules tool in Security and Compliance Manager
• Video: Learning - Using Patch Manager to Patch HP Devices
• Video:E-Learning - Security Suite 9 Fundamentals
• Video:E-Learning - LANDESK Security Suite Fundamentals
• Video:E-Learning - Patch Management Overview
• Video:E-Learning - Patch Manager Overview
• Video:E-Learning - Patch & Compliance Scan & Repair Settings
• Video:E-Learning - Patch & Compliance Architecture
• Video:E-Learning - Patch & Compliance Overview and Download

Troubleshooting this Component

• How to troubleshoot Core Server patch content download issues
• Troubleshooting detection problems in LANDESK
• Troubleshooting Client Reboot Issues
• Common Troubleshooting Steps For Patch Manager
• Issue: Agent Continually Prompts for Reboot

NOTE: This is not a full list of documents and issues. You can continue to search the rest of the Community, or narrow your search to this area.

Issue

Get the following error when downloading Patch Content after installing SP1 on the 9.6 Core Server:

Invalid column name 'Scan'

Cause

DATAMARTPM.XML did not get updated in the Managementsuite folder on the Core Server when SP1 was installed.

Resolution

1. Delete the DATAMARTPM.XML file from the Managementsuite folder on the Core Server.

2. Iinstall the latest service pack on the core server

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.

Description

When we use patch manager to deploy patch to client machines, we can set patch to be autofix. Autofix fails and does not attempt to repair again on client machines.

Cause

The autofix is set to attempt 1 times before giving up by default. The reason we limit the retries is to prevent reboot loops or blue screen loops. It's very rare, but I'd rather have a high retry count than an indefinite one.

Resolution

1. Right click the patch definition and select 'Autofix - Autofix settings...' to open Autofix tab. Set Autofix retry count.

2. Go to the Patch and Compliance to set the global autofix default settings

Click the 'Configure Settings' on menu and select 'Core settings...'

Set the autofix retry count.

See also How to use autofix in Security and Compliance Manager and About Autofix and Scan by Scope changes in LDMS 9.6

Issue

Why are the Scanned and Detected column numbers not updating or are not correct in the Patch and Compliance window?

Cause

A "Gather Historical Information" task has not been run on the core.

Resolution

Schedule a "Gather Historical Information" task from Patch and Compliance.

1. Go to Tools | Security and Compliance | Patch and Compliance

2. Click the "Create a Task" icon drop down arrow.

3.  Choose Gather Historical Data

4. The Gather Historical Information window will open. You can Create a task name, and configure the scheduled days information is kept as well as the information used in running reports. You can also set up a reminder to run this task within a certain amount of days.

5. Create Task and run it, or you can hit Gather Now which will run immediately.

It is important that this task be run regularly to collect the data. For performance reasons the data is not gathered dynamically, as done in previous versions. This has increased performance in patching machines, and decreased information stored within the database tables.

Issue:

Patches failing to download with the message "Skipping old or disabled patch" and the rule is not disabled.

Cause:

The vulnerability publish date is older than the number of days specified in the setting "Also delete patches for undetected rules in definitions published more than xxx days ago" on the Patch Location tab of the Download Updates window and this option is enabled and the patch is not currently detected on any computers.

Solution:

If the patch is ever detected on a client then the patch can be downloaded.

Unchecking the option "Also delete patches for undetected rules in definitions published more than xxx days ago" on the Patch Location tab of the Download Updates window will allow the patch to be downloaded.

Microsoft has ended support for Windows XP

LANDESK Software continues to support Windows XP as an LDMS client.

Supported Platforms and Compatibility Matrix for LANDESK Management Suite

The Microsoft Extended Hotfix Support Datasheet states the following:

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

Article: Extended Hotfix Support Program

The Extended Support phase is the second phase of the Microsoft Support Lifecycle Policy. During this phase, security hotfixes are available free of charge; however, non-security hotfixes, warranty support, Software Assurance problem resolution support, and the ability to request design changes are not available.

The Extended Hotfix Support program provides customers with the opportunity to receive non-security hotfixes through the end of the Extended Support phase of the Microsoft Support Lifecycle.

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

The following Microsoft article gives general information about the Windows XP end of life policy: Support for Windows XP has ended

In addition Microsoft has made a decision to extend to extend their Anti-malware support for Windows XP even further:

Microsoft Malware Protection Center - Support for XP

LANDESK Windows XP Extended Patch Program

Customers must meet the following requirements

• Own LANDESK Patch Manager
• Purchase extended Windows XP Support from Microsoft

LANDESK Deliverables to customers

LANDesk will provide the following to the customer:

• Content for each Windows XP SP3 patch the customer delivers to LANDESK.
• Upon receiving the required patches and bulletins, LANDESK will provide the customer with Windows XP patch content that can be imported into their Security and Compliance tool in LANDESK Management Suite.

Windows XP Patch Support Guidelines

The following applies to publicly released patches for Microsoft Windows XP:

Patches for bulletins related to security:

• Patch content will be released on the same cadence and supported release schedule as non-EOL Microsoft security bulletins (MS15-XX).

Patches for bulletins that are not related to security:

Creating a Custom Blocked Application

The steps below outline the steps for configuring Application Blocking in LDMS 9.5 Important: This only applies if you are going to block applications on every device in your system or use different configurations for your groups. If you anticipate needing to separate systems and block applications only on some devices or need to block different applications for different groups, please skip to “Blocking Applications Using Custom Groups.”

1. Click on Tools | Security and Compliance | Patch and Compliance
2. Change the type to Blocked Applications
   
3. Under Blocked Applications (All items) right-click the Block folder and select Add File.
4. Enter the file name that you would like to block, enter a Title, and enter any other desired information in the other sections.
   Important: Blocked applications will block any executable with the name you enter.  Creating a file with the name "setup.exe" with the intent of blocking a specific install will block any install that uses the name "setup.exe"

Ensure that the Vulnerability Scanner includes the Blocked Applications type
Make sure that in theDistribution and Patch Settingshave theBlocked Applicationsdefinition type selected.

1. Open theSecurity and Compliancetool group
2. Select theAgentSettingstool
3. Double-click the Distribution and Patch setting that you would like to edit.
4. Under Patch-Only settings and Scan Options ensure that under Type you have the checkmark next to  Blocked Applications checked.
   This will cause the Security and Compliance scanner to include Blocked Applications in the type of content that it will scan for.

Blocking applications using Custom Groups
There are times when blocking the application for everyone in your environment may not be desired. For example, some Administrators choose to block Windows Media Player from the majority of their production users, but choose to allow other employees in the company to have access to the Windows Media Player. The steps below will outline the process of blocking an application or group of applications for a particular client computer or group of computers, but still allow the other devices in the network to run those same applications without having to change the agent configuration.

1. Click on Tools | Securitiy and Compliance | Patch and Compliance
2. Change the type to Blocked Applications
   
3. Create the applications you need blocked, or use the pre-defined list that comes down in LANDESK Content when downloading definitions in the Windows | Security | Applications to Block group within the Download Updates tool.

Create and populate Custom Group(s)

1. Within the left-hand pane of the Patch and Compliance tool, expand the tree to show Groups | Custom Groups | My Custom Groups or Public Custom Groups
2. Right-click My Custom Groups or Public Custom Groups and select New Group
3. Give the new group a descriptive name and press Enter
4. At this point you can create sub-folders under this newly created group.  Reasons for this may vary.  One reason may be that you want to set the Distribution and Patch settings for distinct folders of Blocked Applications restrictions.
5. Location the applications that you wish to block in the Block folder under Blocked Applications (All Items) at the top of the left-hand pane.
   If the application you are trying to block is not in the Block folder it will not be blocked.The application may exist in the Do Not Block or Unassigned folder.  If the application does exist in one of those folders, drag it to the Block folder in order for it to be blocked. If the application does not exist in any of the folders you can right-click the Block folder and select the Add File option.

Configure Distribution and Patch Settings to include the Blocked Applications type and focus on your custom group
If necessary you can create a new Distribution and Patch settings that includes scanning for and enforcing the Blocked Applications type.

1. Open theSecurity and Compliancetool group
2. Select theAgentSettingstool
3. Under My Agent Settings or Public Agent Settings right-click the Distribution and Patch setting group and select New.
4. Under Patch-Only settings and Scan Options ensure that under Type you have the checkmark next to Blocked Applications checked.
5. Then you can select either All Blocked Apps or Only Apps in Group and browse to your custom group.
   This will cause the Security and Compliance scanner to include Blocked Applications in the type of content that it will scan for and in the group you have created.

Unblocking an Application Using Custom Groups.Once a scan has been run on a client to block an application, that application will continue to be blocked until another scan is run on the client that does not have that application listed as an application that should be blocked. This is applies to a scheduled push or a policy. If the task was scheduled as a push you will have to reschedule the task after you have removed the definition from the group folder or the blocked folder. If the task was scheduled as a policy and you want to stopping blocking the application for everyone in that group simply remove the definition and the next time the policy syncs it will not be blocked. Deleting the policy will still leave the applications blocked.Scheduling the Security Scan to Block Applications

1. Go back to Patch and Compliance and click on the Create task (Calendar with clock) icon and select Security scan from the drop down menu.
2. Select the option to Create a scheduled task.
3. Give the task an appropriate name.
4. Under the Agent Settings section in the left-hand pane, select the Distribution and Patch setting you just created.
5. Select any other options you wish to select in these dialogs
6. Click Save to save the task.  At this point the Scheduled Tasks tool will open.
7. Locate the devices that you wish to block the application on and drag them to the task.
8. Start the task.

     Helpful Tip: Create a query for the group of computers you would like to have the application blocked for and schedule it as a policy. As you add computers they will get the blocked apps and when you add apps they will get updated on the next policy sync. Also if your target machine already has blocked      applications and you set it to scan against a different set, the new set will remove all of the old settings.

• • How often does LANDESK release 3rd Party vulnerability content?
  • Where does the LANDESK patch executable content come from?
  • What vendor sites are used for downloading patches?
  • How can I see what download paths patches are coming from?
  • What is LANDESK’s Process for downloading Content through Security and Patch Manager?
  • What process does the LANDESK Core Server follow when downloading Patch Content?
  • Does LANDESK mirror ALL patches specified in vulnerability content?

How often does LANDESK release 3rd Party vulnerability content?

The patch content team has a monitor tool that monitors all 3rd party content twice a day.

When it finds an update for the 3rd party the patch content team is notified and work begins on the definition content.

Typically release of the content definition will be within 24 hours of the group receiving the notification.

If the update is not critical it may take more time if they are released on a weekend or on a public holiday.

Where does the LANDESK patch executable content come from?

LANDESK downloads the patches it deploys from the vendors’ web sites.

What vendor sites are used for downloading patches?

This list can be updated  daily (depending on vendor and patch availability)

The following article details the complete list, and is accurate to the date on the filename of the .XLS file:

http://community.LANDESK.com/support/docs/DOC-1594

How can I see what download paths patches are coming from?

A current detailed list of URL's can be obtained by running a simple database query:

select url from patch"

The following article details the complete list of URL's, and is accurate to the date on the filename of the .XLS file:

http://community.LANDESK.com/support/docs/DOC-9638

Most of the patches are downloaded with HTTP:// with a small number coming from FTP://

What is LANDESK’s Process for downloading Content through Security and Patch Manager?

• LANDESK receives notification of a Patch

• LANDESK will download the patches from the application vendor’s site.

• LANDESK does not validate or test patches published by a third party vendor. It is the responsibility of the third party vendor to maintain the validity of the patches published on their websites.

• LANDESK hashes the "official" patch made available by the vendor.

• The file hash is to ensure that the patch downloaded from the vendor is the same file provided for remediation. This insures that the patch is authentic and has not been modified for malicious reasons or otherwise.

• LANDESK creates vulnerability information including detection, install and uninstall commands, and the patch download location.

• The Vulnerability Information is published to the Secure LANDESK content server.

What process does the LANDESK Core Server follow when downloading Patch Content?

• Vaminer.exe connects to the selected secure LANDESK content server (West coast, East Coast, EMEA).
• Connection to secure site is verified through a secure certificate.
• Vulnerability definition information is downloaded directly from Content servers e.g. patch.LANDESK.com.
• Patches are downloaded directly from the vendor’s site (with redundancy falling back to the LANDESK content servers for certain patches – (see the next question for more details) provided that the file's hash matches the hash created when LANDESK created the content.

Does LANDESK mirror ALL patches specified in vulnerability content?

Most if not all Microsoft patches are hosted on the LANDESK content servers. There are some Mac patches that are also hosted, usually large file downloads. The hosting of these patches provides a limited backup of the most accessed patches from these two main vendors. Some patch content cannot be legally hosted on the patch content servers and require they be downloaded directly from the vendor's web site (Example: Java patches and other Manual Download patches). These files, however, are still hashed in the LANDESK vulnerability definition to provide the same level of file authenticity as files hosted on the content server.