Overview

Additional control over who can edit and import definitions has been added in LDMS 9.6 Service Pack 1.

Previously anyone with the "Edit" right for "Patch and Compliance" could edit all definitions and import definitions.

In 9.6 Service Pack 1 LANDESK Administrators will be able to enforce greater control over who can edit and import definitions.

Require "Edit Public" right

To open this setting, go into Patch and Compliance.

Click the Configure Setting icon (cog wheel)

Click "Permissions..."

Only users with the LANDESK Administrator role will be able to control this setting.  If you wish to require the "Edit Public" right, check the box.

If you wish anyone with the less restrictive "Edit" right to make changes, uncheck the check box.

Issue

Administrator wants to increase or decrease the number of Security Scan logs that are kept on the client computer.

Resolution

Add or change the key maxBackups (DWORD) in the following registry path, as shown in the video:

32 bit devices

HKLM\Software\LANDesk\ManagementSuite\LogOptions\Vulscan.exe

64 bit devices

HKLM\Software\Wow6432Node\LANDesk\ManagementSuite\LogOptions\Vulscan.exe

Symptom

Reboot prompts indicate more time till automatic reboot than is defined in the reboot settings.

Example: Reboot shows it will automatically reboot in 13 hours instead of 5 minutes which is what the reboot settings show.

Cause

LDReboot.exe was called outside of the reboot maintenance window defined for the agent.

"C:\ProgramData\landesk\log\ldReboot.log" shows that ldReboot was called outside of the maintenance window:

Tue, 27 Jan 2015 14:28:41    Auto-reboot window is specified
Tue, 27 Jan 2015 14:28:41       Time window:   04:00 to 05:00
Tue, 27 Jan 2015 14:28:41       Days of week:  any
Tue, 27 Jan 2015 14:28:41       Days of month: any
Tue, 27 Jan 2015 14:28:41    Auto-reboot time is outside auto-reboot window - changing to 2015-01-28 04:00:00

The maintenance window is defined in the Agent's reboot settings under General | Automatic reboot

Solution / Workaround

Because an auto-reboot window has been defined, automatic reboots will only be permitted within the designated time frame.

This can cause behavior different than intended if ldReboot is called outside of that window, for example during a patch cycle.

To correct this, define a longer reboot window, or disable the window.

Allowing multiple hour delays on automatic reboots has been seen to fail, as other actions may call ldReboot and reset the timer.

Overview

Autofix and Scan by scope have been implemented to allow different computers to be scanned or autofixed by the scope(s) they are in and still use the same Distribution and Patch settings.

Patch and Compliance Tree Changes

The Scan tree in Patch Manager has been changed to show both global and scoped Autofix and Scan groups.

Notice that the "All Items" has been incorporated into the root of the tree "Vulnerabilities (all items)"

If you don't see a "Current Scope" option, make sure at least one scope is created and that you have selected to view the Patch and Compliance under one of those scopes.

For example, in the screenshot above my scope is currently set to "Blah".

If I changed the scope to "Global (all devices)" I would no longer see the Autofix (current scope) and Scan (current scope) options.

Setting to Global or Current Scope

To set a definition to Global or Current scope they can be copied and pasted into the desired category: Autofix (current scope), Autofix (global), Scan (current scope), or Scan (global).

If multiple scopes are needed to be set you can open individual definitions and select multiple scopes as seen in the next section.

Definition View of Scope

When opening a single definition you can view the Scan or Autofix tab.

This screen shows the current status of a definition, in this example "Scan (global)"

The available scopes are also show with checkboxes.

To enable this definition to be scanned by scope you can check the checkboxes next to the available scopes.

Autofix tab has a similar view.

Scan by Scope process

When a computer gets vulnerability definitions from the core it will also ask the core for its list of scopes.

The client uses this list of scopes to compare against the list of definitions it should scan.

The vulnerability definitions are stored on the core server in the LDLogon\VulnerabilityData directory.

The .xmlz are the compressed versions of the .xml files.

The .xmlz is copied down by the client and put into a "mergedGetVulnerabilitiesOfType_?.<Coreserver>.xml

The scopes will be listed in the .xml files as "Scanscopes"

For example, this custom definition is set to be scanned by scope 3:

<vulnerability Lang="INTL" Vul_ID="CD-order1" Date="1415725397" T="4">

  <Status>Available</Status>

  <ScanScopes>.3.</ScanScopes>

Introduction

As we all know, the latest release of Office from Microsoft comes in 2 flavors. A 'rich client' based installation, which is practically the same as running the Setup as in previous versions, and a Click-to-Run setup. The Click-to-Run version basically downloads stand-alone App-V packages of the applications you want to use from the Office Suite. Easy as this may be (and, depending on your licensing scheme, the only option you may have), this provides a challenge for Patch Management, as LANDESK cannot patch within an App-V package.

This document will describe how to easily still use LANDESK to patch Click-to-Run Office365 installations using all LANDESK intelligence. From now on, the use of Office365 will assume the Click-to-Run version.

Configure your Office365 installation

More information about actually deploying Office365 can be found here. During configuration of Office365 setup you can create a XML file that will change certain settings in your Office365 package to fit your environment. This XML can be created using the Office Deployment Tool for Click-to-Run. In this setup, there are 2 important setting for Patch Management. First off, you can set the Office365 installations to Auto-update. This will prevent that users need to manually check for updates. Second, there is a path where the installed Office365 packages will look when Auto-Update is configured. By default this will point to a share. In a configured XML this will look like this:

In a small environment, you can just point the UpdatePath to the location where LANDESK downloads patches. But, in a larger environment, you don't want all devices to connect to a central share, when you have options like Preferred Servers, Bandwidth Usage or the Cloud Services Appliance you want to use. For this reason, change the UpdatePath setting to: %ProgramFiles%\landesk\ldclient\sdmcache (or whatever the location of your sdmchache is)

Using LANDESK

Ideally you have 1 installed rich Office365 installation (Office Professional Plus 2013), although this is not completely necessary.

First, create a query which checks All Devices for Office365 installed.

You can download the Patch definitions in the normal way. If you have the Office Professional Plus 2013, running the vulscan will detect the definitions you need to deploy on the Click-to-Run devices. If not, you need to have a manual monthly process to select from the definitions last month from the Patch and Compliance screen, Vulnerabilities, View by Product --> Office2013 and/or Office2013x64, download the detected/selected patchcontent from the definitions and wait until all replications to Preferred Servers have completed.

Now we can select all Office365/2013 vulnerabilities from this month and create a Repair Task.

Most important, change the settings in Task Settings, so that the task uses Policy based delivery (so it will also work with devices through the CSA) and uses the Pre-Cache option under the Download options. Don't add any targets automatically to the task. Rename the task to cover the content, like 'Office365 Patches December'. Save and add the query you created as target.

Start the task. When the devices check for Policies, they will start this task and download (with all LANDESK intelligence) the selected patch content to the SDMCACHE on the client. From there, it will be picked up by the auto-update of the Office Setup.

Summary

Change the setup XML to use the UpdatePath setting: %ProgramFiles%\landesk\ldclient\sdmcache

Select all Office2013 vulnerabilities for the selected month

Download all their content

Wait for replication tasks until the content is on all Preferred Servers

Create a repair task with Policy/Pre-cache options configured

Target the query you created which queries Office365 installation

Start the task

The devices check for their policies and download the patches to SDMCACHE

The Auto-Update of Office picks the patches up from the local SDMCACHE folder

Thanks

Many thanks to remon.mulders for his brilliant thoughts on this subject!!

• • 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
/Dump
/Data
/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

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

This information is out of date:

For the latest information on this topic, please see the following Community Article:

Products and Applications available through LANDESK Security and Compliance content delivery

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

Issue

When running a vulnerability scan, the Security and Compliance Manager (Vulscan or Vulnerability Scan) window is blank.   The window shows the title, but the contents are blank.

Otherwise the Security and Compliance scan appears to run normally.

Cause

The vulnerability scan window may not display correctly when remote controlled into the client computer via Remote Desktop.

Resolution

Remote Desktop into the client computer using an Admin connection.

In order to connect using an admin session, the /Admin switch must be used.

Command line: mstsc /Admin /v:(computername)

For further information regarding the /admin and /console switches and Remote Desktop see this article.

Pour la version Francaise consulter l' article suivant

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

Issue

Patch Manager randomly loses settings inside the download updates window.

In "patch and compliance" the button "download updates" is used to to configure and schedule the download of the definition updates.

Sometimes the parameters inside download updates are reset to blank. The result is that it does not download updates and you have to reconfigure it.

Cause

This is due to database corruption.

Resolution

1. Make a backup of the database.
2. Close all LANDESK consoles and stop all LANDESK services using the batch file in this article:
   http://community.landesk.com/support/docs/DOC-2465
3. Run this SQL query on the LDMS database:

   DROP table PatchSettings
4. Open a cmd as a administrator and go to this path and run this command:
   

   * C:\Program Files (x86)\LANDesk\ManagementSuite>CoreDbUtil.exe /xml=Datamart.xml

5. In the GUI Interface inside CoreDBUtil select "build components"
6. Restart all LANDESK services as explained in Step #2
7. Log in to your console and review the patch settings in the Download Updates tool.

Situation

How does the "Use 64 bit registry view on 64 bit Windows" setting affect my detection rule?

Description

LANDESK allows configuring custom Patch and Compliance rules to check on patch information for applications LANDESK doesn’t provide definitions for.

We will not cover this in great detail here. For more Information How to configure Patch and Compliance rules please vistit https://help.landesk.com/docs/help/en_US/LDMS/9.6/default.htm#cshid=Patch_Property.

We will discuss the effects that come from ticking the box within the Registry settings. This box changes the view the LANDESK client has on the registry of 64bit Windows machine drastically.

Because The LANDESK client is a native 32-bit application. Under 64-bit Windows all 32-bit applications are kept inside the Windows 32-bit on Windows 64-bit sandbox system.

This is called the WoW64 subsystem. The WoW64 subsystem also handles registry aspects owned by 32-bit applications. The registry entries of 32-bit applications are kept within the the following registry path:

HKEY_LOCAL_MACHINE\Software\Wow6432Node

This path is unknown to 32-bit applications. For 32-bit applications this path is presented as the following:

HKEY_LOCAL_MACHINE\Software\

That way 32-bit clients only see the 32-bit part of the registry, while the 64-bit part of the registry is hidden from 32-bit application. So the 32-bit LANDESK client would normally not being able to access, or check, any 64-bit part of the registry.

Solution

The LANDESK client uses a loophole with the WoW64 subsystem to access the 64-bit part of the registry. This has to be configured for every single rule, where this is necessary. To do so just check the box "Use 64-bit registry view on 64-bit windows within the rule settings and the LANDESK client will get access to the whole registry of the 64-bit Windows. This implies that if the 64-bit registry view has been enabled, registry keys of 32-bit application will now be accessible only via the HKEY_LOCAL_MACHINE\Software\Wow6432Node path. The HKEY_LOCAL_MACHINE\Software path now holds only the registry setting of 64bit applications.

Usage Example:

• If writing a rule for 32-bit applications that targets only 32-bit clients, you do not need to activate the 64-bit view.
• If writing a rule for 32-bit applications that targets 32-bit and 64-bit Windows, you also do not need to activate the 64bit view.
• If writing a rule for 64-bit applications which targets 64-bit Windows, you need to activate the 64-bit view to be able to see the 64-bit portion of the registry.
• If writing a rule for 32bit application which targets 64-bit Windows and the 64-bit view is enabled, it is crucial to add WoW6432Node to the Registry path to access the 32-bit portion of the registry.

Problem

From time to time, you may need to change the security scan local scheduler settings using a managed script.

Resolution

Sample Script:

[MACHINES_WIN]

REMEXEC03=<qt/>%LDMS_CLIENT_DIR%\LocalSch.exe<qt/> /del /taskid=777

REMEXEC04=<qt/>%LDMS_CLIENT_DIR%\LocalSch.exe<qt/> /exe=%quote%%LDMS_CLIENT_DIR%\vulscan.exe %quote%  /cmd=<qt/>/noreboot<qt/> /taskid=777 /freq=86400 /tod=%quote%14|16%quote% /autodelay=1|60

Note:

1. /taskid=777, security scan local scheduler task ID is always 777 by default.   Changing the ID is NOT recommended.
2. /cmd=<qt/>/noreboot<qt/> is the security scan switch, please refer to the related document below for more details.
3. /freq=86400, local scheduler task frequency in seconds, 86400 means 1 day. The value can be changed according to your needs.  This is measured in seconds.
4. /tod=%quote%14|16%quote%, time period sets to perform the task, 14|16 means from 2pm to 4pm. The value can be changed according to your needs.
5. /autodelay=1|60, time delay sets to perform the task, 1|60 means 1 hour. The value can be changed according to your needs.

Related document: About Vulscan switches for Windows clients

Description

In the Vaminer.log you find the following SSL error.

LoadingPatchSources : GetStreamForPath https://patch.landesk.com/LDPM8/ldvul.php failed The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

If you open the patch location inside the IE of the core (here the European site), you get a certificate error displayed.

Cause

This is related to an untrusted root certificate in the core server’s certificate storage.

Reslution

Update the root DigiCert Root certificates, so that the certificates are trusted again.

There are two possible option to do so:

1. Install the latest Root certificate update provided by Microsoft via Windows Update.
2. Update only the DigiCert Root certificates needed for LANDesk Patch Manager
   1. Goto https://www.digicert.com/digicert-root-certificates.htm to check on the latest DigiCert root certificates hash values. These values will assure that you install the correct certificates in the later process
   2. Goto https://ev-root.digicert.com/ to install the DigiCert High Assurance EV Root CA
      1. You probably see a certificate error
      2. Click either inside the error message “show certificate” or click on the padlock symbol in the address bar of your IE to access the certificate.
      3. Change to the Certification Path tab and select the certificate marked with an red cross.
      4. Click on “view certificate”

• v. In the general tab click on “Install Certificate”
• vi. Choose “Place all certificates in the following store” and select the “Trusted Root Certification Authorities” store.

1. After you imported all certificates, close the IE again and open https://patch.landesk.com/ again.
2. There should be no error message again and the Certification Path should look as follows

If you are like me living a country that does not have a localized version of LANDESK, you might run into this issue.

You start the Vulnerability Scan en when the message should appear that the vulscan detects a vulnerability, you only get the message: Unable to find string with ID...

This happens because LANDESK doesn't support the language of your OS but builds a XXXvulscan.dll with your language code. In the case of The Netherlands, we would see a NLDvulscan.dll. This 'localized' dll unfortunately doesn't contain the all of the strings the vulscan UI asks for.

To remedy this, go to the LDLogon share on the Core Server. Copy the ENUvulscan.dll and rename the copy to XXXvulscan.dll, XXX being your country ID. If the localized DLL exists already, delete it before you rename the copy.

That's it. Your vulscan running on the workstation will detect a newer DLL on the server and automatically download it. And you will have all the strings available from the English languange DLL, showing you exactly what is detected and more.

In addition this can occur if not all Vulscan related files are up to date and there is a mismatch.  

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

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

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

Content verification is only available for the following content types:

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

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

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

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

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

This article describes the meaning of the suffixes used in the titles of Patch and Compliance Manager vulnerability definition content.

Various suffixes are given to Patch Manager vulnerability definition titles to help more accurately describe their purpose.

The following table shows the suffix, it's meaning, where it is used, and an example:

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 9.0.4.6 then you will need to replace it with the 9.0.3.76 DLL found in your SP3 install directory or you can contact support and we can send you the proper Vulscan.dll.

LANDESK uses Vulscan and vulnerability definitions to determine what patches are needed on a client machine. These results are then reported to the core server and patches can be installed on the client machines

Vulscan scanning process

When vulscan is run, by default it will use the currently installed and configured Distribution and Patch settings. These settings will tell vulscan what to scan for, be it type(s) or a group. What to scan for, or the settings to use can be changed via the command line, or as part of a scheduled task.

Once vulscan has determined what it will scan for, it will request the needed definitions from the core. They are delivered as a compressed file of XML data. The XML data is the vulnerability information and contains the information needed to determine if a machine is vulnerable to any number of vulnerabilities. Vulscan will check file versions, registry values and a number of items to determine the status of a machine.

Vulnerability Definitions

The vulnerabilities definitions are in the form of compressed XML data. Each definition is named according to the vulnerability released from the vendor. They contain any number of detection rules and associated patches. For example MS10-036 is a vulnerability in Microsoft Office shared code. Therefore it affects a wide variety of configurations from Microsoft Word Viewer to Office 2007 Enterprise. Each of the possible configurations or patches has a detection rule that allows vulscan to determine the status of the machine. What is important is that a single vulnerability visible in the console may consist of multiple detection rules and even multiple patches. These rules and associated patches are populated using information made available by the vendor of the vulnerable product such as Adobe or Microsoft.

Vulnerability is determined by checking file versions, file existence, registry values, or through a custom script as specified in the vulnerability definition. Once a machine is determined vulnerable the needed patch is identified and the results are sent back to the core.

Sometimes the vulnerability in LANDESK can differ slightly from other tools. For more information on this see: Windows Update and LANDesk Have Different Severity Levels for Same Vulnerability

Troubleshooting

If you think that LANDESK is not detecting correctly there are a few things you can do. Usually detection will either indicate a machine is vulnerable when it isn't, or it will fail to detect a machine that should be vulnerable.

Vulscan Log

The single most important resource in troubleshooting detection is the vulscan log. For complete information on reading and understanding the vulscan log take a look at the following article: How to read a vulnerability scan (vulscan.log) log file

Finding the correct vulscan log is important. Run vulscan e to open the vulscan log folder on the client machine. Otherwise the files are at:

Windows XP, 2003

• C:\Documents and Settings\All Users\Application Data\vulscan\

Windows Vista, 2008, 7, 8, 2012

• C:\ProgramData\vulscan

The vulscan logs will be named vulscan.log then vulscan.1.log up to vulscan.10.log. Vulscan.log is the most recent with vulscan.1.log through vulscan.10.log representing the previous scans. Occasionally other vulscan logs may be present due to simultaneous attempts to run vulscan. They will usually be named vulscan.PID_XXXX.log or vulscan_instanceX.log

The best way to determine which log contains the task or information you need is to look at the Command line option near the top of the log:

Command line: /repair "vulnerability=FIREFOX3v3.6.7" /agentbehavior=LDMS9_22 /taskid=23

The above command line is running a repair of a Firefox vulnerability using the Distribution and Patch settings with ID 22 and is run by the task with and ID of 23. The command line will help you determine what task, or what type of scan was run. A blank command line indicates that the scan was run as part of the regularly scheduled vulnerability scan. For information on vulscan command lines see: About Vulscan switches for Windows clients

Once you have the correct vulscan log, look for the vulnerability in question.

Processing vulnerability MS10-032
Checking vulnerability MS10-032, rule index 0
Should reboot before repairing windows2000-kb979559-x86-enu.-z7Svg.exe returned: 0
VUL: 'MS10-032' not detected.  No affected platforms were found.  Patch is NOT installed
Checking vulnerability MS10-032, rule index 1
Should reboot before repairing windowsxp-kb979559-x86-enu.-scWKg.exe returned: 0
VUL: 'MS10-032' not detected.  No affected platforms were found.  Patch is NOT installed
Checking vulnerability MS10-032, rule index 2
Should reboot before repairing windowsxp-kb979559-x86-enu.-scWKg.exe returned: 0
VUL: 'MS10-032' not detected.  No affected platforms were found.  Patch is NOT installed
Checking vulnerability MS10-032, rule index 3
Should reboot before repairing windowsserver2003.windowsxp-kb979559-x64-enu.-aqeyw.exe
returned: 0
VUL: 'MS10-032' not detected.  No affected platforms were found.  Patch is NOT installed
Checking vulnerability MS10-032, rule index 4
File OSVERSION version within specified
Prod Windows Server 2003 Service Pack 2 (ID:MS7756H1) verified OSVERSION,
found: 5.2.3790.2
File C:\WINDOWS\system32\win32k.sys version less than 5.2.3790.4702
Should reboot before repairing windowsserver2003-kb979559-x86-enu._2kIiA.exe returned: 1
VUL: 'MS10-032' DETECTED.  Reason 'File 'C:\WINDOWS\system32\win32k.sys' version
is less than the minimum version specified.'.  Expected '5.2.3790.4702'.
Found '5.2.3790.4571'. Patch required 'windowsserver2003-kb979559-x86-enu._2kIiA.exe'.

Above you can see the section of a log where it is processing the vulnerability MS10-032. There are 5 rules (numbered 0-4). Rules 0-3 did not apply because they are for other OSes. Rule 4 applies because it is for Windows 2003 SP2. It then moves on to check the file wind32k.sys to see if it has the correct version. Since the version is less than the required, this vulnerability, MS10-032 is detected, and the patch needed is listed. (windowsserver2003-kb979559-x86-enu._2kIiA.exe)

For any detection problems, this log information can be useful in determining why it is detecting as vulnerable and if it should be or not.

Non-vulnerable machine showing as detected

There are a number of reasons that a machine may detect vulnerable when it isn't. After a patch has been installed, some files may not be fully installed until the machine is rebooted. LANDESK will not recognize this until the machine is rebooted AND another vulscan has scanned for that vulnerability to determine it is no longer vulnerable. Also sometimes LANDESK will think vulnerable software is installed that isn't.

• To resolve this, make sure the following has been done:

1. Reboot the machine
2. Rescan the machine, making sure that the vulnerability in question was scanned
3. Verify that the vulscan log shows the vulnerability as scanned and DETECTED. When it shows as detected, look at why and determine if in fact it should be detecting or if maybe something unexpected is on the client or was left behind on the client.
4. If the log indicates that the vulnerability is DETECTED and it truly shouldn't be, open a case with LANDESK Support and provide them with the vulscan log and information about the vulnerability. We can then work on determining if there is a problem with the detection rules and work on correcting any problem.

Vulnerable machines not showing as detected

Occasionally another scan or tool will indicate that a machine is vulnerable to something, but LANDESK will not have the machine as vulnerable. This can result from a difference in detection. Some tools will look for the patch installation information indicating that a patch was installed. If a newer patch that patched the needed files has been installed they may indicate the machine is vulnerable. LANDESK will do the same "patch installed" detection, but will not use that to determine a machine's vulnerability instead using other registry keys and file versions whenever possible. This and other differences in detection can produce differing results.

• If you suspect LANDESK is not detecting a vulnerability that it should be

1. Find the vulnerability in the console and double click to open it.
2. Check the box next to Status and verify that it says Scan
3. Select the Description tab. Open the link in the More Information at: box in an internet browser
4. Get the vulscan log from the client machine in question and look through the log for the vulnerability information
5. Review the rules and detection results in the log and compare it to the information on the page open with more information about the vulnerability. Be especially aware of any patches that supersede the patch in question.
6. If you are able to determine that the machine really should be vulnerable, collect the log(s) and open a case with LANDESK support. When you do, please make sure to indicate what detection rule isn't working right or may be missing and reference any technical documentation from the vendor that helped you determine this. LANDESK support will verify the issue and work to get the definition updated so that it detects properly.

Tip: In order to easily navigate to the logs and settings directories for the vulnerability scanner, the following commands can be used at the Run line in Windows:

• vulscan e
• vulscan log

Conclusion

LANDESK vulnerability detection will sometimes report unexpected or even incorrect information. When that happens, consulting the vulscan log and reviewing the results from each detection rule in the vulnerability will enable you to determine better what is going on and how to fix it.

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

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

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

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

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

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

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

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

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

Introduction

LANDESK Security and Compliance Manager enables you to remediate (repair) vulnerabilities on clients with the LANDESK agent installed.  There are several situations where this remediation will not complete, will detect improperly, otherwise does not act as desired.

Scope

The scope of this article is to walk through some of the basic troubleshooting steps to find why the Patch and Compliance scan is not working as desired.  It will cover troubleshooting install error, or corrupted installs that are being caused by the patch the vulnerability definition is attempting to remeidate.

Assumptions

This article assumes that the Core Server is version 9.6 with the latest Service Pack installed.  The agents also have the 9.6 agent installed with the latest service pack, and are able to send inventory and vulnerability scans to the Core Server.

Logs and files and paths used in Troubleshooting

1. Vulscan.log
   a. Windows 2000, 2003, and XP i. C:\Documents and settings\all users\Application Data\Vulscan
   b. Windows Vista, 7, 2008 and 2008 R2 i. C:\ProgramData\Vulscan
   
2. 0_winxp_enu_########.xml –
       a. Client - ..\ldclient\sdmcache b. Core - \\\ldlogon\computervulnerability
3. MergedGetVulnerabilitiesoftype_X..xml
       a. Windows XP, 2003:  C:\Documents and Settings\All Users\Application Data\Vulscan
       b. Windows 7, 8.1, 2008, 2012: C:\Program Data\Vulscan
4. SDMCache folder
       a. C:Program Files\LANDesk\LDClient\SDMCACHE (32-bit client)
       b. C:\Program Files (x86)\LANDESK\LDClient\SDMCACHE (64-bit client)

Vulscan Switches

• AgentBehavior=AgentBehaviorID
• /ShowUI
• /AllowUserCancelScan
• /AutoCloseTimeout=Seconds

/Scan=X, where X is the Type (listed below)\

• 0-Vulnerabilities
• 1-Spyware
• 2-Security Threats
• 3-LANDesk Updates
• 4-Custom Definitions
• 5-Blocked Apps
• 8-Antivirus

• /Group=GroupID /AutoFix=True or False

The Computer is being detected vulnerable when it shouldn’t be.

1. If the vulnerability was just remediated and the computer is still showing detected:
   1. Make sure the client has rebooted.
   2. If the patch requires changing a system or protected file, that change will not take effect until the client reboots.
2. Run a Security Scan on the client.
   You can manually run the scan with the following command.
   

   Vulscan /scan=0 /showui (Vulscan Switches)

3. Verify that the client installed the patch and still shows as vulnerable on the core server.
   1. Open a LANDesk Management Suite Console.
   2. From the Network View expand Devices and click on All Devices.
   3. Locate the computer in question.

The Computer is being detected vulnerable when it shouldn’t be.

If the vulnerability was just remediated and the computer is still showing detected:

1. Make sure the client has rebooted.
   1. If the patch requires changing a system or protected file, that change will not take effect until the client reboots.
   2. Run a Security Scan on the client.  You can manually run the scan with the following command.
      

      Vulscan /scan=0 /showui (Vulscan Switches)

   3. Verify that the client installed the patch and still shows as vulnerable on the core server.
      1. Open a LANDesk Management Suite Console.
      2. From the Network View expand Devices and click on All Devices.
      3. Locate the computer in question.
      4. Right-click on the computer and select "Security and Patch Information"
      5. Click on Clean/Repair History.
      6. Locate the patch and locate the Succeeded column.  Verify that it says "Yes".
      7. Click on All Detected in the left-hand column.
      8. Look for the vulnerability in question.
      9. Check the most recent Vulscan logs.  About the Vulnerability scan and repair logs
      10. Look for the vulnerability that is still showing as detected.
      11. The log will show why the client is still showing as vulnerable.
          1. Possible Causes of why the client is still showing as vulnerable:
             1. The file or registry setting is not being properly updated by the patch.
                (Try uninstalling and reinstalling the patch.  If detection works after this, the original patch failed to install the required files)
             2. The vulnerability detection logic needs to be adjusted.   LANDESK Support will need the Vulscan log to request a change to the detection logic.
                How to report LANDESK Patch Manager vulnerability detection problems to technical support

The vulnerability should never have been detected

1. Run a vulnerability scan on the client.
     You can manually run the scan with the following command: 

   vulscan /scan=0 /showui

      (The /scan=# command may differ depending on the definition type you wish to scan)

Issue 

Scheduled task to repair a vulnerability is failing

The vulscan.log file shows the following error:

Last Status: Failed:  Must reboot before appyling this patch.

exiting with return code 0x8db3019c (all patches failed) or 0x8db3019d (some patches failed)

Resolution

The client needs to be rebooted.

When vulscan.exe runs a patch on a client machine it will create the following registry key if a reboot is needed.

HKLM\Software\LANDesk\Managementsuite\Winclient\Vulscan\VulscanReboot

If this registry key exist then the vulscan will not scan for that patch rule again until the client is rebooted. This is a volatile registry key that will get deleted once the client is rebooted.

Another key that gets created is;

HKLM\Software\LANDesk\Managementsuite\Winclient\Vulscan\RescanBeforeRepair

This registry key will get created even if the patch does not require a reboot.  The purpose of this key is to alert vulscan.exe that it needs to scan for the definition again before attempting to intall the patch.  This will prevent vulscan.exe from attempting to reinstall the patch over and over on client when there is a problem.  The rescanBeforeRepair value will be deleted by the next scan that takes place on the client machine.