LANDESK Security and Patch News 

Headlines

·     (June 8, 2015) Microsoft has released KB2965292 which is a Visio 2010 update. This update fixes the following issue:
Organization charts that are created in Visio 2010 by using the Org Chart wizard may be incorrect if there are duplicate display names in Global Address Book (GAL). This issue occurs because only the first user name is used in creating the organization chart wizard.  Please visit the following page for more details: http://support2.microsoft.com/kb/2965292     

New Vulnerabilities     

  ·       Vulnerability ID – 2965292_INTL  

Changed Vulnerabilities     

·       Vulnerability ID – N/A    

New Patch Downloads     

·         visio2010-kb2965292-fullfile-x86-glb.exe  

·         visio2010-kb2965292-fullfile-x64-glb.exe  

Where to Send Feedback           

At LANDESK, we are constantly striving to improve our products and services and hope you find these changes reflective of our ongoing commitment to listen to you—our partners and customers—in providing the best possible solutions to meet your needs now and in the future.  Please continue to provide feedback by contacting our local support organization.    

Best regards,  

LANDESK Product Support  

Copyright © 2015 LANDESK Software.  All rights reserved. LANDESK is either a registered trademark or trademark of LANDESK Software, Ltd. or its affiliated entities in the United States and/or other countries. Other names or brands may be claimed as the property of others.    

Information in this document is provided for information purposes only.  The information presented here is subject to change without notice.  This information is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including any implied warranties and conditions of merchantability or fitness for a particular purpose. LANDESK disclaims any liability with respect to this document and LANDESK has no responsibility or liability for any third party products of any content contained on any site referenced herein.  This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. For the most current product information, please visit http://www.LANDESK.com. 

Environment

LANDESK Management Suite 9.0

LANDESK Management Suite 9.5

LANDESK Management Suite 9.6

Problem/Issue/Symptoms

The on line activation process of a LANDESK Management Suite Core server fails.

Causes

The most common causes for this issue are:

1. Lack of http connectivity towards license.landesk.com
2. Missing certificates on the core
3. Missing registry key for the activation URL

Solutions

1) Lack of http connectivity towards license.landesk.com

1.1) Check if your core server is able to communicate with license landesk com, executing a ping license.landesk.com in a command prompt, a public IP address should reply, for instance 204.246.129.106.

1.2 Verify that you can open in a browser the following URL:http://license.landesk.com/authorizationservice/licensing.asmx

1.3) Verify that the proxy options used in your web browser are the same used in your Core Server Activation, if the browser is able to reach the URL just checked.

1.4) Verify that the software and hardware firewalls between your core and the internet allow your core to reach license.landesk.com on the tcp port 80 (http).

1.5) Verify that your %windir%\system32\drivers\etc\hosts file doesn't contain any line referring to license.landesk.com

2) Missing certificates on the core

2.1) In the folder %programfiles(x86)%\LANDesk\Shared Files\keys\. You should find  one file for each of the following extensions: .0, .cer, .crt and .key. If you are running a 32 bit server remove the (x86) part in the path. On a 9.6 Core user the %programfiles% folder instead.

2.2) Verify that the registry key CertName in HKLM\Software\Wow6432Node\LANDesk\ManagementSuite\Setup is pointing to the right certificate name. On a 9.6 core remove the Wow6432Node part from the registry path.

2.3) Verify to have a .0 file with the same name as the one just checked in the folder %programfiles(x86)%\LANDesk\Shared Files\cbaroot\certs\. If you are running a 32 bit server remove the (x86) part in the path. On a 9.6 Core user the %programfiles% folder instead.

2.4) To troubleshoot a missing or deleted certificate follow this article: How to troubleshoot a missing or deleted core certificate.

3) Missing registry key for the activation URL

3.1) Verify the presence of the AuthorizationServiceUrl key in HKLM\Software\Wow6432Node\LANDesk\ManagementSuite. The value of the key (string) must be http://license.landesk.com/authorizationservice/licensing.asmx On a 9.6 core remove the Wow6432Node part from the registry path.

4) Other complementary tasks

4.1) Run the core server activation as an administrator

4.2) Track the activation process with procmon or wireshark to check if the core is really able to communicate with license.landesk.com

4.3) Delete the content of the %temp%, %tmp% and %windir%\temp folders

4.4) Delete all the .txt and .save files in the %programfiles(x86)%\LANDesk\Authorization Files\ folder\. If you are running a 32 bit server remove the (x86) part in the path. On a 9.6 Core user the %programfiles% folder instead.

5) Other resources

5.1) Unable to activate an 8.7 / 8.8 core server online: https://community.landesk.com/docs/DOC-29443

5.2) Manually activating the core server via email: How to Activate the Core Server

5.3) Missing licenses and subscriptions after a major release upgrade: The core server you are connecting to does not appear to have a valid license

• What are these landing pages for?
• The Landing Pages were created as a means for LANDESK users to learn about the different Components in the LANDESK Product Line.  Our desire is for these pages to be a place where you can learn about each component's setup and troubleshooting methods as well as additional actions you can take to get more out of your LANDESK Product.
  • LANDESK Management Suite
  • LANDESK Security Suite
  • Asset Lifecycle and Process Manager
  • LANDESK Service Desk

What are these landing pages for?

The Landing Pages were created as a means for LANDESK users to learn about the different Components in the LANDESK Product Line.  Our desire is for these pages to be a place where you can learn about each component's setup and troubleshooting methods as well as additional actions you can take to get more out of your LANDESK Product.

LANDESK Management Suite

• LANDesk 32-bit Console Landing Page
• LANDesk Agent Deployment Landing Page
• LANDesk Cloud Services Appliance Landing Page
• LANDesk Core Install/Upgrade Landing Page
• LANDesk Data Analytics Landing Page
• LANDesk Database Landing Page
• LANDesk Intel AMT/vPro Landing Page
• LANDesk Inventory Landing Page
• LANDesk Linux/Unix Landing Page
• LANDESK Macintosh Agent Landing Page
• LANDesk Management Suite Landing Page
• LANDesk Mobile Device Management Landing Page
• LANDESK Power Management Landing Page
• LANDesk Provisioning Landing Page
• LANDesk Remote Control Landing Page
• LANDesk Reporting Landing Page
• LANDesk Software Distribution Landing Page
• LANDesk Software License Monitoring (SLM) Landing Page
• LANDesk Systems and Security Landing Page
• LANDesk Web Console Landing Page

LANDESK Security Suite

• LANDesk Antivirus Landing Page
• LANDesk Host Intrusion Prevention (HIPS) Landing Page
• LANDesk Patch and Compliance Landing Page

Asset Lifecycle and Process Manager

• Asset Lifecycle and Process Manager Landing Page

LANDESK Service Desk

• LANDesk Service Desk Administration and CIs Landing Page
• LANDesk Service Desk Calculations Landing Page
• LANDesk Service Desk Documentation Landing Page
• LANDesk Service Desk Knowledge Management Landing Page
• LANDesk Service Desk Pre 7.4 content Landing Page
• LANDesk Service Desk Object Designer Landing Page
• LANDesk Service Desk Process Designer Landing Page
• LANDesk Service Desk Query Design Landing Page
• LANDesk Service Desk Reporting Landing Page
• LANDesk Service Desk Service Catalogue Landing Page
• LANDesk Service Desk Landing Page
• LANDesk Service Desk Web Desk and Self Service Landing Page
• LANDesk Service Desk Window Manager Landing Page

Issue

When trying to open a certificate sent by the Certificate Authority, a message is received:

This file is invalid for use as the following: Security Certificate

Cause

The certificate is not readable under its current extension.

Resolution

• Change the file extension to *.p7b
• The file should be readable by opening within the Certificate Manager. (Double click the file to open it).
• Expand Certificates | File Path | Certificates
• Right click the certificate issued to your domain, choose All Tasks | Export

• In the Certificate Export Wizard click Next

• In the Export File Format window select Base-64 encoded x.509 (.CER) and click Next

• In the File to Export Window enter a path and File Name for the file to export as

• In the Wizard Complete screen, choose Finish to close

• The exported *.cer  file can be validated with the vPro Certificate Validation and Conversion Tool

LANDESK Patch and Compliance Manager uses an auto update feature in order to make sure that all vulnerability scanning files are up to date with the core server. This ensures compatibility between the files and the latest definitions as well as compatibility with the files on the core.

Vulscan Self Update

When vulscan runs, it will initialize the needed files, then contact the core server to check for any updated files. If it finds updated files it will download them, stop any running LANDESK services as needed, replace the files and then start any LANDESK services. This process varies slightly depending on files that are updated.

Agent files

Vulscan checks for the following agent files and executables and updates them as needed:

• vulscan.exe
• vulscan.dll
• vulscan.sig
• xxxVULSCAN.dll where xxx is the 3 letter language prefix such as enu or ptb
• softmon.exe
• ldavhlpr.dll
• vbscript.v55
• sendtaskstatus.exe
• av.key
• ldav.key
• rollinglog.dll
• ldreboot.exe
• ldreboot.dll
• localsch.exe
• ltapi.dll
• LDSystemEventCatcher.dll

Settings

Vulscan will update all settings with the latest version of the CURRENT INSTALLED SETTING on the client. This includes:

Again, this will only update the settings that are currently set or installed on the client machine. This WILL NOT update the client files (exes, dlls, etc) for all of the above components, only the settings.

Important Note: It is important to know which settings are on the client machines whenever modifying settings. If you are working with some settings, testing or adjusting, any machines that run vulscan, scheduled or otherwise, will update. The currently installed settings can be found in the inventory record of the device under Computer - LANDESK Management - Component

Preventing Auto Update

The /noupdate switch can be used to prevent vulscan from updating files. This switch must be added to any scheduled task, policy, or locally scheduled task in order to completely prevent updating the client.

Right Click Scanning

If you right click on a device and select "Security and Compliance scan now" the client WILL NOT update.

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.

Description

A vulnerability repair job results in the following errors: "Another installation is pending reboot", "Reboot required", "Cannot complete the requested action. The device must be rebooted first." or similar error messages.

Cause

The vulnerability scan will check for the existence of a PendingFileRenameOperations registry key value in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager.

If there is a value there the computer is waiting for a reboot to complete an installation.

Resolution

1. The best resolution is to let the computer reboot, completing the install, however sometimes this key is not cleared properly by an ill-behaving application.
2. To bypass this check before trying to Remediate a patch, adjust the Scan and Repair Setting to not look for this key in the following manner:
   1. Open the Management Suite Console.
   2. Click on Tools | Security and Compliance | Agent Settings
   3. Under My Agent Settings or Public Agent Settings select the Distribution and Patch settings you wish to edit.
   4. Under Patch-Only Settings | Install/Remove Options tick the box next to Start Repair even if Reboot is already pending.
      

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.

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

Description

Patch group contains all Microsoft Vulnerabilities that are marked as "Important" and "Critical".  After we have deployed patches to our server we have noticed that after running a windows update scan there are still some missing patches which are categorised as "Important" by Microsoft. When we checked the same patch in LANDESK we noticed that Landesk marks these as "N/A".

Example is patch KB2861855 which is a security patch categorised as "Important" by Microsoft  but NA by LANDESK.

Reason

The mark N/A means that Microsoft has not mentioned the severity of the Vulnerabilities in the kb.

Solution

Severity can be overwritten by following these steps:

1. Right-click a vulnerability definition
2. Select "Override Severity"
   
3. Select "Override vendor-specified severity"
4. Select the desired Severity you would like to assign to the vulnerability.

Problem

When trying to patch office updates the patches fail to update. When looking at the Vulscan.log file you see a 8004005 return code.

Cause

Microsoft Office is trying to access the network share that the original software or service pack was installed from. The install source can be verified at the following registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Delivery\SourceEngine\Downloads\"Download_Code"\Sources\"Product Name"

The Download_Code subkey is a series of numbers and letters in a format that may look similar to the following:

90000409-6000-11D3-8CFE-0150048383C9

The Product Name is the specific install component you are looking for. You will see the same product name under various "Download code" entries. Any of these may be the reason why your update is failing.

You can also try to download and install the patch manually. If you unplug the computer from the network while it is running the upgrade you will be prompted for a install location during the install process. This means the install source is not on the computer, and you will have to follow the resultion section to patch the compuer.

Note: VULSCAN.EXE runs as the local system account when running in a scheduled task. Local system cannot access network resources so it will be unable to access the installation source.

Resolution

The MSI tab gives some additional functionality to the LANDESK patching process. The main feature is the Original Package Location section. This will allow you to reference a network resource where your install files are located. It will also allow you to provide the credentials needed to access the network resource.

Note that although the Run As information is contained on this same page, it is separate from MSI credentials.   This is used to elevate rights to an account that has Local Administrator access on the client.

1. Open the LANDESK Management Suite console.
2. Click on Tools | Security and Compliance | Agent Settings
3. Expand My Agent Settings or Public Agent Settings and then click on Distribution and Patch
4. Right click on the Distribution and Patch settings you wish to change and click properties. Click on the MSI Tab.
5. Enter the network patch for the location of the Original Package. Note: this doesn't have to be the original location that the software was installed from. It just needs to have the needed install files.
   

   The Security Scan will NOT scan recursively. This can result in the need of multiple Distribution and Patch settings for the various installed versions of Office.

6. Enter the credentials needed to access this network path.
7. Click Save.
8. Retry running the patches.

Note: This same problem can happen with software updates of other types that rely on a source location to install updates and patches.  The the resolution above is still valid.

Issue

You see the following errors in your Vulscan log on clients since upgrading to 9.5 and the error returned says "Failed to get Vulnerability Data from the Core".

Downloading http://coreserver/ldlogon/VulnerabilityData/0_win7-x64_ENU.1364920985.xmlz

Failed to download http://coreserver/ldlogon/VulnerabilityData/0_win7-x64_ENU.1364920985.xmlz.  Error code 8

Last status: Failed

Download Failure: Error 80004005 downloading http://coreserver/ldlogon/VulnerabilityData/0_win7-x64_ENU.1364920985.xmlz

Last status: Failed: Could not download http://coreserver/ldlogon/VulnerabilityData/0_win7-x64_ENU.1364920985.xmlz

Skipping repair step because scan errors occurred.

Failed

Read from pipe (0x1bc) failed: 109

Wed, 03 Apr 2013 05:11:03 Exiting with return code 0x8db30194 (404).

Cause

Clients are being told in their Scan and Repair settings -> Network Settings -> Preferred server /Peer download option to only download from "Attempt peer download" and/or "Attempt preferred server" and "Allow source" is not selected.  See screenshot:

If "Allow Source" is not selected and your preferred servers or clients have no Vulnerability Data to give to your clients then this error will occur.

Resolution

Select "Allow Source" or make sure your preferred servers or at least one of the clients on the same subnet has the proper vulnerability data.

For a further list of Vulscan return codes, see this article.

Problem

When attempting to repair a large group of vulnerability definitions you are presented with the message "You have selected more than 25 vulnerabilites. Only the first 25 will be included in this operation. Continue?"

Solution

The only way to schedule a repair of more than 25 patches is to schedule more than one task, or repair against a Custom Group.  To learn how to repair against a Custom Group, please see http://community.landesk.com/support/docs/DOC-2842

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

This document is for an older version of the product:

For the latest information see this article: How to use Application Blocking in LDMS 9.6 Patch and Compliance Manager

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

1. Open the 32bit Management Suite console.
2. Click on Tools | Security and Compliance | Patch and Compliance
3. Change the Type to Blocked applications.
   .
4. Right Click on the Block Folder.
5. Choose Add a File...
   
6. Enter the file name you would like to block.
7. Enter Title.
8. If desired enter the other information sections.
9. Click OK.
   
10. Make sure that your Scan and Repair settings have Blocked Applications checked.
    
11. The next time your clients run a Security Scan they will pull down the Blocked Application files and begin blocking.

Important! 

Blocked Applications will block any .exe with the name you enter. So creating a file with setup.exe with the intent of blocking a specific install will block any install that uses setup.exe. 

Issue

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

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

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

Resolutions

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

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

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

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

Incorrect alternate Core Server name specified in Scan and Repair settings

Verify what Scan and Repair Settings the client is using.

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

Core Server Reboot

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

IIS Configuration and/or Permissions Issue

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

A basic connectivity test can be done:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Modifying the Identity used by the WSVulnerability Application Pool

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

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

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

Description

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

ASP.NET and CBA_anonymous accounts

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

GPO Policies on Core Server

1. Go to Start | Administrative Tools | Local Security Policy.
2. Expand Local Policies.
3. Highlight User Rights Assignment
4. Make sure that the Adjust memory quotas for a process value provides permissions for these accounts:
   
   Local Service
   Network Service
   IWAM_SERVERNAME
   Administrators
   
   Note: These are the default accounts. The Application pool is running as Network Service and requires this ability.
   Note: To test if this is the cause, set the identity of the Application Pool to be Local System. If this works, then permissions is definitely the cause.
   Note: It may be necessary to put the Core Server in its on OU and have absolutely no GPOs applied to the OU, not even the default policy.

IP Address or Domain Name Restrictions in IIS

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

Ensure that the proper Web Service Extensions are enabled

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

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

Install the latest Service Pack for your version of the Product

LANDESK Security and Patch News     

Headlines

·     (June 10, 2015) Microsoft has released KB3054786 which is the latest Outlook 2013 Junk Email Filter update. A download link is included. This non-ENU definition may have been download with ENU content. This was done to provide support for Multilingual User Interface(MUI) applications. The English versions of an MS Office application or other application may support adding localized/language support on top of English installations. So these MUI specific content definitions may download with ENU content to support MUI installations. Please see http://community.landesk.com/support/docs/DOC-30218 for additional details. Please visit the following page for more details: http://support2.microsoft.com/kb/3054786     

New Vulnerabilities     

  ·        Vulnerability ID – 3054786_INTL  

Changed Vulnerabilities     

·        Vulnerability ID – 2986209_INTL
(Added the replacement information.)    

New Patch Downloads     

·         outlfltr2013-kb3054786-fullfile-x86-glb.exe  

·         outlfltr2013-kb3054786-fullfile-x64-glb.exe  

Where to Send Feedback           

At LANDESK, we are constantly striving to improve our products and services and hope you find these changes reflective of our ongoing commitment to listen to you—our partners and customers—in providing the best possible solutions to meet your needs now and in the future.  Please continue to provide feedback by contacting our local support organization.    

Best regards,  

LANDESK Product Support  

Copyright © 2015 LANDESK Software.  All rights reserved. LANDESK is either a registered trademark or trademark of LANDESK Software, Ltd. or its affiliated entities in the United States and/or other countries. Other names or brands may be claimed as the property of others.    

Information in this document is provided for information purposes only.  The information presented here is subject to change without notice.  This information is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including any implied warranties and conditions of merchantability or fitness for a particular purpose. LANDESK disclaims any liability with respect to this document and LANDESK has no responsibility or liability for any third party products of any content contained on any site referenced herein.  This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. For the most current product information, please visit http://www.LANDESK.com.