Just curious if anyone has done this.  It would be nice to be able to set patches to autofix, and have them applied after hours.

frankdls

We've determined that that for our agency, forcing software updates on people during the workweek requires too much micromanagement and issues.

Therefor, we are wondering if LANDesk offers an easy way that users may request software installs and updates.  to be a bit more specific, I would like users to have the ability to run mandatory software updates when it's convenient for them.  Or if they would like a piece of software added to their computer... they may click "install" themselves.  This would not be a service desk feature, that's not what we're looking for.

As I write this, I realized it is the exact same thing as Apple's App store.. but we would populate the available applications internally.

Thank you in advance for any replies.

Items in brackets are optional, and the | symbol means "or":

Running "vulscan e", "vulscan l", "vulscan c", or "vulscan av" does the following:

Vulnerability definition types for use with the /scan= switch:

Vulscan switches used for content replication

/replicate– triggers vulscan to do a content replication.

/changesettings with a /replicationbehavior=default  tells vulscan which behavior to use.  Default means compute the behavior guid based on the computer idn.  For example, if my computer idn is  1234, then I will try to download a behavior called “ReplicationBehavior_Replicator_1234.xml”. Vulscan will now consider itself a “replicator” and will try to update its copy of a replicationBehavior any time it runs, creating any local scheduler jobs as necessary.

/changesettings /replicationbehavior=-2 will disable vulscan as a replicator, removing any local scheduler tasks regarding replication and causing vulscan to no longer attempt to get the latest replication behavior file.

/settingsIndex=NNN– you’ll see this commandline used by the local scheduler when it launches vulscan.  This tells vulscan which group of settings to use to control its behavior as specified in the console’s UI.  For each scheduled replication event that you specify, there will be a new “settingsIndex”.

/duration=NNN– The maximum duration that vulscan should do replication, in minutes.  This will appear in the replication behavior file and not typically on the command line, but in the file you’ll see something like “Duration_0”, or “Duration_1”, etc.  The value after the underscore is the settings index number.  When vulscan applies settings found in the behavior file and it sees that its settingsIndex value has been set, then it looks for any variables in the behavior file that end with an underscore and that number (such as “Duration_0”).  It strips off the underscore and number and sets the value internally.  Therefore, anything you see in the behavior file that ends in the underscore can be passed on the commandline (and therefore take precedence over the behavior file settings).

Many of the _NNN settings that are in the behavior file are regarding the local scheduler task that should be created.  So vulscan only interprets those values when creating the local scheduled task that will later launch itself to do replication.

I am using Patch and Compliance in order to install IE though my company. The installer works great and I am able to monitor the installs as they go. I have my install set to "noReboot" and "passive" but with any IE install it does not alert the user to reboot once finished therefor just leaving the user to reboot without knowing for sure if IE was installed. I have a VBS that i want to run after "Run an executable" in the same task. It's a simple script that will display a prompt for the user if they want to reboot with a Yes to reboot and no to cancel. The problem that I am running into is that the script does not run after the install, IE does install but then I see a failed install results.

Am i doing something wrong were I enter the script,should I be going about this a different route?

I have attached the script as well along with a picture of were I enter this option

Notes

Using Patch Manager to Install IE

Want to Run Script that shows Prompt to Reboot after IE10 is finished within the same task

Script does not Run when entered with Patch install Commands "Run Script"

IE installs but shows Error on LANDesk Side with no "Prompt To Reboot" from script

Issue

Microsoft Update has a vulnerability listed as "Critical" but when looking at the same vulnerability in LANDesk it is listed as "Low" or "N/A".  Why are they different?

Solution

Windows Update uses a different set of severity levels to sort the vulnerabilities than LANDesk does. The Windows Update site uses high-priority, software, optional, and hardware optional as possible severity levels. These severity types do not correlate with the severity values that Microsoft provides in the vulnerability KB articles.

LANDesk uses the severity level that is specified by the vendor.  For Microsoft vulnerabilities LANDesk uses the severity level that is specified in the Microsoft KB article that they provide for each vulnerability.

All of the severity levels that are listed for each vulnerability in the Patch Manager solution come directly from the vendor of the patch.  LANDesk does not assume or make any decision as to what severity level the patch should be for a 3rd party product.

How does LANDesk determine the severity level of a patch?

The 3rd party vendors of the vulnerability are responsible for determine the severity ratings. Below is the breakdown of these ratings for both Microsoft and other vendors vulnerability ratings and the corresponding LANDesk value.

Microsoft using the following rating system:

The Severity Rating System

The severity rating system provides a single rating for each vulnerability.  The definitions of the ratings are:

For more information please see http://www.microsoft.com/technet/security/bulletin/rating.mspx

LANDesk maps Microsoft severities in the following manner:

For non Microsoft content we use the 3rd party vendors severity rating and then map it to the LANDesk ratings.

* Not Applicable applies to any vulnerability that does not have a rating or is a patch or software update that do not have security Implications to them. An example would be a patch that fixes a font display issue in an application.

More Information

Tip: You can look at the article used to set the severity and see additional information about the vulnerability by following the "More Information at:" link in the patch properties. To get to this link, right click on the vulnerability in question and select Properties. Then select the Description tab. You can link directly to the article by clicking the "More Information at:" Link

For more information on some processes to help manage and patch all the patches listed in Microsoft Update, please see LANDesk Patch Manager is not installing all of the patches that show up in Windows Update

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.

So, to summarize

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

We have started having an issue with LANDesk patching Chrome.  We do not approve all Chrome patches but for us the issue started with version 38.0.2125.104 and we also had the issue with 38.0.2125.122. On certain computers the patch will install and the end user will be prompted rebooted.  After the reboot the computer then runs a Security scan at log on and it runs the install again and the user is prompted to reboot again so they are endlessly being asked to reboot until they contact the Help Desk.  In LANDesk the patch is showing as if it was installed successfully but apparently the patch definition is not detecting that the patch is installed. I have connected to a few of these computers and if I check Program and Features Chrome is showing up to date but if I open up Chrome is showing out of date.  I can then Run As on Chrome with an Admin account and then Chrome finally reflects the correct "most recent" patch version and it gets the end user out of the endless reboot prompts.  Any help or suggestions would be great.

Here is what Security and Patch looks like for a computer having the issue.

LANDesk 9.5 SP 2

KB3024777 needed. Any idea when it will be released through Patch Manager?

This is an urgent fix that Microsoft released a couple days ago for a problem with Root Certificates I find it worrying that this has not been released to LANDesk yet.

We have the exe but really need the detection rules for LANDesk

Install KB3024777 to fix an issue with KB3004394 on Windows 7 and Windows Server 2008 R2

A common question that is asked is "How can I use Patch Manager to uninstall patches?"

Uninstalling patches

You can uninstall patches that have been deployed to managed devices.

For example, you may want to uninstall a patch that has caused an unexpected conflict with an existing configuration.. By uninstalling the patch, you can restore the device to its original state.

To uninstall a patch

1. Open the properties of the vulnerability for the patch that needs to be uninstalled.

2. From any detection rule listing on the General tab, right-click one or more rules, and then click Uninstall Patch. If the Uninstall Patch option is greyed out, this option is not available for this patch and you will need to find another way to uninstall the patch.

3. Enter a name for the uninstall task.

4. Specify whether the uninstall is a scheduled task or a policy-based scan, or both.

5. If you selected scheduled task, specify which devices from which you want to uninstall the patch.

6. If the patch can't be uninstalled without accessing its original executable file (i.e., to use command-line parameters), and you want to deploy the executable using Targeted Multicast, check the Use multicast check box. To configure Multicast options, click the Multicast Options button. For more information, see About the Multicast options dialog.

7. If you selected policy, and you want to create a new query based on this uninstall task that can be used later, click the Add a query check box.

Select a scan and repair setting from the available list (or create a custom setting for this scan, to determine how the scanner operates on end user devices.

Click OK. For a scheduled task, you can now add target devices and configure the scheduling options in the Scheduled tasks tool. For a policy, the new policy appears in the Application Policy Management window with the task name specified above. From there you can add static targets (users or devices) and dynamic targets (query results), and configure the policy's type and frequency.

About the Uninstall patch dialog

Use this dialog to create and configure an uninstall task for patches that have been deployed to affected devices.Task name: Identifies the task with a unique name. The default is the name of the patch. You can edit this name if you prefer.

Uninstall as a scheduled task: Creates an uninstall patch task in the Scheduled tasks window when you click OK.

Select targets: Specifies which devices to add to the uninstall patch task. You can choose no devices, all devices with the patch installed, or only the devices with the patch installed that are also selected (this last option is available only when you access the Uninstall Patch dialog from within a device Security and Patch Information dialog).

If the original patch is required:

Use Multicast: Enables Targeted Multicast for deploying the uninstall patch task to devices. Click this option, and click Multicast Options if you want to configure the multicast options. For more information, see About the Multicast Options dialog below.

Uninstall as a policy: Creates an uninstall patch policy in the Scheduled tasks window when you click OK.

Add query representing affected devices: Creates a new query, based on the selected patch, and applies it to the policy. This query-based policy will search for devices with the selected path installed and uninstall it.

Scan and repair settings: Specifies which scan and repair setting is used for the uninstall task to determine whether the security and patch scanner displays on devices, reboot options, MSI location information, etc. Select an scan and repair setting from the drop-down list, or click Configure to create a new scan and repair setting.

Note: This information can be found in the LDMS 8.8 help file under the headings "Uninstalling Patches" and "About the Uninstall Patch Dialog"

Applies to 9.6 and 9.6sp1

Autofix by scope added in LDMS 9.6

Scan by scope added in LDMS 9.6sp1

Overview

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

Patch and Compliance Tree Changes

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

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

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

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

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

Setting to Global or Current Scope

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

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

Definition View of Scope

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

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

The available scopes are also show with checkboxes.

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

Autofix tab has a similar view.

Scan by Scope process

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

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

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

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

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

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

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

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

  <Status>Available</Status>

  <ScanScopes>.3.</ScanScopes>

Applies to 9.6sp1

Overview

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

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

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

Require "Edit Public" right

To open this setting, go into Patch and Compliance.

Click the Configure Setting icon (cog wheel)

Click "Permissions..."

Only users with the LANDESK Administrator role will be able to control this setting.

If you wish to require the "Edit Public" right, check the box.

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

Problem

New patch content is not downloading.

When trying to download updates many of the "Definition types" previously listed are gone. These can include: Microsoft Windows Vulnerabilities, Microsoft Windows Spyware, Apple Vulnerabilities, Antivirus Updates, or the Linux vulnerabilities.

Cause

The subscription for Patch Manager or LANDesk Security Suite has expired or the Core has not been able to contact the licensing server to verify content subscriptions. Or, the license is missing the subscription for the version of Management Suite the Core is currently running.

Resolution

Reactivate the core:

1. On the Core server - Click on Start | All programs | LANDesk | Core Server Activation
2. Click Activate

Check to make sure that your subscription has not expired and that you have a subscription for the version of Management Suite you are currently running. To do this:

1. On the Core server - Click on Start | All programs | LANDesk | Core Server Activation
2. Click Licenses in the botton left hand corner.
3. Look for anything that says it has expired.
4. Check for a subscription for the version of Management Suite that is currently running on the Core Server. The version must match. A 9.6 subscription will not work for 9.5.
5. If you have expired items, you will need to get those renewed.
6. If you are missing the subscription for the version you are currently running, open a case with LANDESK Support to get the license fixed.

If you know that the subscription was renewed but it is not showing it in the Licensing window open a ticket with LANDesk Technical Support to further troubleshoot the problem.  A screenshot of the Licensing screen from the Core Activation Utility would be advised to give to Support.

This can be done through the Self Service Portal, or by contacting LANDesk Support via telephone.

This video shows you how to get started with Application Blocking.

If this video has helped you please like or leave a comment, Thank you.

This video shows you how to leverage the download updates tool to help you automate the sorting and organization of your downloaded patches.

If this video has been helpful, please like or leave a comment.

Noob question as I'm just switching over from WSUS to Landesk 9.0SP3 for client patch management. I've gone through numerous documents explaining patching, all of which cover the 9.0 SP1 or older version and don't explain what the 3 folders ("Replaced", "Paritally replaced" and "Replacement not Enabled Folders") under the Scan folder do.

Specifically, am I supposed to be moving patches around in these folders or are they positioned there by Landesk?

Also, when I grab patches to put into my custom group folders to create my repair (patch) task, am I copying the patches just from the "Scan" folder or do I also have to grab them individually also from the 3 subfolders too?.

I think I've got the rest down, these folders just make me wonder as they're not mentioned in the documents I've gone through. Searching the forums I wasn't able to find anything useful on them as well.

Thanks

Pete

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.

Issue:

Gather Historical Information task is failing to run.

Following is in the GatherHistory.Details.Log file in the Managmentsuite\Log folder on the Core Server:

09/18/2014 15:12:18 INFO  13352:SaveTrendInfoForVulnerabilitiesAsync : Critical Exception: System.Data.OleDb.OleDbException (0x80040E31): Query timeout expired   at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)   at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQueryP(String sql, Int32 timeoutSeconds, Object[] parameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql, Int32 timeoutSeconds, ArrayList oleDbParameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql)   at LANDesk.ManagementSuite.PatchBiz.PatchTrend.SaveTrendInfoForVulnerabilities(Int32 removeOldDataDays)   at LANDesk.ManagementSuite.PatchManagement.ProgressForm. € ()   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)   at System.Threading.ThreadHelper.ThreadStart() Stack Trace:    at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)   at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQueryP(String sql, Int32 timeoutSeconds, Object[] parameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql, Int32 timeoutSeconds, ArrayList oleDbParameters)   at LANDesk.ManagementSuite.Database.Database.ExecuteNonQuery(String sql)   at LANDesk.ManagementSuite.PatchBiz.PatchTrend.SaveTrendInfoForVulnerabilities(Int32 removeOldDataDays)   at LANDesk.ManagementSuite.PatchManagement.ProgressForm. € ()   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)   at System.Threading.ThreadHelper.ThreadStart()

Solution:

1. Close the LANDESK Console.

2. Create the "Query Timeout" registry value as a 32-bit DWORD in the following registry key on the Core Server:

HKLM\SOFTWARE\LANDesk\ManagementSuite\WinConsole

Create any registry keys that are missing. Set the value to 10000 decimal.

unable to get vulnarable defnition from core 404 error.....i tried to give host file enrty with core ip still facing same issue .....help

I'm in the process of migrating from our 9.5 SP3 core to 9.6 SP1 (side by side), our agents are at 9.5 SP1 so we are using our 9.5 core to push a 9.6 SP1 Advanced Agent via custom vulnerability.

The process itself works fine, older agents are detected, i can push the repair (manually at this stage as we are testing) and everything works once you step through the continue buttons and by the end of the process the client is reporting to the new core and working as you would expect.

I have created a specific scan and repair setting to be used when running the repair job:

General Settings - Show progress dialog: Never

Repair Options: Always Prompt User / User cannot defer or cancel action

Repair Options: Message - Custom message explaining what is happening, After timeout start the install after 10 minutes.

Reboot Options: Never reboot.

The idea is that users will receive a notice explaining the update is coming down, you can keep working and will be prompted to reboot at the end (from the 9.6 SP1 client default policy).

What i am finding however is that users a prompted to hit the "Start Now" button 4 times before it will actually go - You hit "Start Now" the window disappears and then comes back, repeat 3 times and it goes, i'm not sure why this would be the case? We do't have this issue with any other scan and repair jobs.