Issue

Windows 7 and Windows 2008 machines are blue screening upon boot.

Identifying Affected Machines

Machines can boot into Safe Mode.

1. While inside safe mode navigate to
   

   64bit: HKLM\\software\\wow6432node\\LANDesk\\ManagementSuite\\Winclient\\SoftwareMonitoring\\FTD

    

   32bit: HKLM\\software\\LANDesk\\ManagementSuite\\Winclient\\SoftwareMonitoring\\FTD

    

2. Look for CSRSS.exe   If it is there, the machine is affected.

You may also see 0x000000F4 in the Bluescreen information like this:

Cause

CSRSS.exe is a Windows System file for some windows operating systems.

CSRSS.exe has recently been infected by viruses and DENY-CSRSS was made in response to this threat and offered in Application Blocking Content.

Denying this file on some OSs causes a blue screen.

Resolution

On Affected Clients:

1. Boot into Safe Mode.
2. Open Regedit.
3. Navigate to
   
   64bit: HKLM\\software\\wow6432node\\LANDesk\\ManagementSuite\\Winclient\\SoftwareMonitoring\\FTD
   32bit: HKLM\\software\\LANDesk\\ManagementSuite\\Winclient\\SoftwareMonitoring\\FTD
   
   
4. Find CSRSS.EXE and remove it.
5. Reboot normally.

On Core Server:

LANDESK has removed DENY-csrss from content.  If you have DENY-csrss in Patch and Compliance, please update Application Blocking content and it will be automatically removed or you can manually delete DENY-csrss/

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!!

Issue

Affected Computers window doesn't display any results after right clicking a vulnerability and selected "Affected Computers" from the quick menu.

This affects all vulnerability definitions on the core server and also on additional consoles

Troubleshooting

This mostly occurs after upgades or patch installations as these also update / change the database.

1. Try to open the affected computers window several times
2. Check the end of the logfile "C:\Program Files (x86)\LANDesk\ManagementSuite\log\console.exe.log" (default location)
   It is more than likely, that you will see an entry similar to the below one:

"05/30/2013 23:32:56 ERROR 3420:Main Thread DataServices.Database : ExecuteDataTable

System.Data.OleDb.OleDbException: Invalid object name 'CVDetectedV'......"

This means that the CVDetected View is missing from the database

Solution:

1. Create a full backup of the Landesk Database
2. Close the Landesk Console on the Core server and all additional consoles
3. Open a command line and "cd" in to the folder "C:\Program Files (x86)\LANDesk\ManagementSuite\" - this is the default location of the Managementsuite folder.Depending on how Landesk has been installed it could be different.
4. Double check if you have a file, called "DatamartPM.xml" in yout Managementsuite folder. If the file is there,
5. Issue the following command CoreDBUtil.exe /xml="C:\Program Files (x86)\LANDesk\Managementsuite\DatamartPM.xml"
6. This should open a new window. In the new window, please click "Build Components"
   
7. Wait until the application finishes and then log back to the console and re-open the "Affected Computers" dialog.
   This time you should be able to see the affected devices correctly.

Issue

Windows Devices in another AD domain are not using the FQDN to the LANDESK core server to download the patches and are failing.

There is a DNS entry for the LANDESK server in the target AD domain but is not getting queried because only the hostname is listed in the download URL rather than the FQDN.

Cause

The patch download link is based upon the specified URL and not based upon the core server's name in the keyvalue table.  This is because the patch download location can be changed to another server besides the core server.

Resolution

Modified "Web URL or UNC path where clients access patches" settings from the Download Updates - Patch Location tab.

Issue

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

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

Inventory Related Troubleshooting

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

Example:

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

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

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

Check for the core server in the registry:

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

Also check the Inventory scanner shortcut.

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

IIS Related Troubleshooting

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

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

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

Re-Register ASP.NET

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

Review IIS Virtual Directory and File permissions

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

In particular the permissions for IncomingData and VulscanResults are important.

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

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

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

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

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

Restore IIS settings from backup if available.

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

COM+ Objects

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

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

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

Issue from import of Scan and Repair settings

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

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

• • Issue
  • Causes and Resolutions
    • The patch content needs to be updated as the local content is out of date
    • A web caching or other networking appliance within the environment is causing the contents of the file to change or is serving up a deprecated version of the file
    • Patch definition content is corrupted in the database
    • The file has changed after the patch definition was published
    • Manual download patches

Issue

Error when downloading content "Hash for patch (Patch Name) does not match with host. Discarding."

Causes and Resolutions

For security purposes, each patch file referenced within a vulnerability definition contains a hash value to ensure that the file referenced is the authentic patch file.

After downloading the patch, if the patch does not match, Patch Manager will discard the file.

There are various causes that can contribute to this issue.

The patch content needs to be updated as the local content is out of date

If the LANDESK Patch Content has been changed since the last time patch content has been downloaded this error can occur.

Download patch content again.   If the error still occurs, try downloading from a different patch content server (US West Coast, US East Coast, or Europe)

A web caching or other networking appliance within the environment is causing the contents of the file to change or is serving up a deprecated version of the file

In many environments, web caching appliances are in place.   When LANDESK attempts to download the file, the internet caching appliance intercepts the request and incorrectly delivers an older version of the file.   Once the file is downloaded on the LANDESK Core Server, the hash check fails.

In this instance, the cache for the particular failed file can be cleared on the internet caching appliance, the entire cache can be cleared, or the internet caching appliance can be configured to allow the core server to bypass caching.

Manually copying the file to the patch storage directory from a computer that bypasses the internet caching appliance can verify that this is the issue.

Patch definition content is corrupted in the database

If the latest patch content is downloaded, there are no caching appliance is in the environment, the local downloaded patch file has been deleted from the storage directory, and there is still a failure, the following SQL query can be run to force the content to redownload.

This query changes the LANDESK Revision number to "0".   When the core server compares revision numbers with the revision on the LANDESK patch content servers the version on the LANDESK patch content server will be higher, thus the content will download again:

UPDATE Vulnerability SET LANDESKrevision = 0 WHERE vul_id = 'definition name'

A more advanced variation on this is:

select * from VULNERABILITY where VUL_ID IN ('<vul_no1>', '<vul_no2>')

Update VULNERABILITY
set LANDESKREVISION=0 where vul_id in ('<vul_no1>', '<vul_no2>')

The file has changed after the patch definition was published

If other steps fail, it is possible that the file has changed, and it is necessary for LANDESK to update the patch content.

It is possible that the vendor changed the contents of the file but kept the same filename, and LANDESK has not updated the related vulnerability definition yet.   At times a vendor will make a change to a file, but does not publish information regarding the change.

If this is the case, this download should fail regardless of the Core server attempting the download.   This would be a global issue.

In this instance, contact LANDESK Support and request that the patch content be updated.   A LANDESK technican can also verify the file download failure internally.

Manual download patches

It can be difficult to determine if the hash does not match for patches that must be manually downloaded from the vendor.   Typically these require going to the vendor website, finding the correct file and version, renaming it to the unique filename specified in the rule for the definition, and placing it into the patch download folder.

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.