• Issue
• Cause
• Troubleshooting
  • Log Files Used for Troubleshooting
  • Reset Internet Information Services
  • Core Server Reboot
    • Incorrectly configured Application Pool in IIS or faulty .NET Framework Installation
  • Local Security Policy "Adjust memory quotas for a process" user rights assignment
  • Client cannot connect to \\CORESERVER\LDLOGON\VulnerabilityData or browse http://coreserver/wsvulnerabilitycore/vulcore.asmx
  • Vulnerability Data corrupt on the core server
  • Vulnerability Data on client is corrupt and client is not updating to new data
  • A definition within a particular category is corrupt
  • MSXML installation corrupted or missing on 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.
  • 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.
  • Remove the /3GB switch from the BOOT.INI file on the Core Server
  • The LDMS Core Server has run out of disk space

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

Ivanti EPM 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

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:

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

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 quotas for a process" user rights assignment is assigned to the following accounts:

Administrators

LOCAL SERVICE

NETWORK SERVICE

SQLServer20XXMSSQLUser$ServerName$DatabaseInstanceName

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

The Ivanti EPM 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 Ivanti EPM vulnerability scanner calls the WSVulnerabilityCore web service and uses a SOAP request for "GetVulnerabiilitiesOfType" and requests vulnerabilities for the type of definition (Windows Vulnerabilities, Ivanti 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.

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?

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?

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#

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

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\ directory ) 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.

The LDMS Core Server has run out of disk space

This error (along with multiple other errors) can occur if your core server is out of disk space.  If it's a virtual disk, allocate additional space.  If it's a physical disk, clean up unused files to create more space.  You may consider moving your Software library, Patch library, HII Driver library, OS Provisioning images etc. to a different hard drive on the core or to a different preferred server to free up significant space.