Description

The vulscan.exe processes are accumulating. Vulscan.exe is adding one process per day, and there are numerous vulscan processes since the last computer reboot.

After the security scan is complete, the dialogue window will not close and no 1 minute timeout message appears indicating that the dialogue will automatically close.

Resolution

The issue is the result of the administrator having enabled the "Distribution and Patch" behavior option "Require end user input before closing".  The problem with this setting, in this scenario, is it can cause multiple vulscan processes to be initiated where the processes are expecting user input before closing.  With the "Require end user input before closing" option checked; that is, "enabled", there is no automatic timeout.

Using the option "Close after timeout" can avoid this issue.  This setting will allow the vulscan process to stop automatically after the security scan is completed; instead of manually having to close the security scan page.

Issue

When attempting to patch there are a large about of detections of vulnerabilities that are not applicable to the client machine. When scanning, these definitions are flagged as detected for reason "Pre-req Check failed." This can cause numerous failures, bloated detected definition results, and incorrect logging.

Symptoms

To know whether or not you are getting a Pre-req check failure there are a few symptoms you can look for in order to know if this is the cause of your patch failures. This issue only occurs with Next Gen vulnerabilities.

1. Scan Failed returns

One of the first symptoms most customers notice is an abundance of "Scan Failed, Failed to start scan (0x1374900)" returns in their clients patching history. These returns are an indication that the core server received a failure to start the scan during Vulcan. This is due to important files not being in the proper location during the scan, more on that later.

2. Bloated "All Detected" patches list

The second symptom that can point to a Pre-req check failed is the bloated "All Detected" folder in the Patch and Security. This is normally filled with a large amount of detection of either previously undetected or not applicable vulnerabilities. Since there was a failure during the scan for these vulnerabilities they will be flagged as detected and will show up in this folder. When selecting one of your definitions you will see the reason for detection as "Pre-Req Check Failed."

3. Ivanti folders on the root of C:\

The final Symptom of this issue is the presence of two Ivanti folders that are being placed in the root of C:\.  "vulScan" and "LANDesk" will appear in the root of C:\ instead of the locations "ProgramData" and "Program Files(x86)" respectively. This is caused by them not being properly configured to the proper locations.

Resolution

This issue can be easily resolved by correcting the registry key where the vulScan folder should be properly located. Open Regedit and locate the following key

x64 Devices

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\explorer\Shell Folders

x32 Devices

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Here you will find the "Common AppData" key. If you are experiencing this issue it is caused by this key being blank. Simply add "C:\ProgramData" without the quotes then run a scan. This should allow for a proper scan and the vulScan and LANDesk folders will properly update in their designated locations. You are free to delete the folders on the C:\ root without any impact on the product.

Description

What do the codes returned at the bottom of a Security and compliance scan log (vulscan.log) or in the Scheduled Task results mean?

Resolution

You can translate the error codes by finding out where the code originates from.  The rightmost 16 bits of the error value (the low word) contains the error code; the leftmost 16 bits (the high word) are commonly used to indicate the component generating the error.

We will use "Exiting with return code 0x8db301b0" as an example.  In this case, 0x8db3 indicates Vulscan as the source, and 301b0 translates to "432".

0xdb3 or 0x8db3 denote an Ivanti Patch and Compliance Manager facility code.  These can relate to any of the tasks that Vulscan performs, and also relate to results from Ivanti Antivirus or Ivanti Endpoint Security.

0xdb0 and 0x8db0 are Ivanti Antivirus return codes

Codes that start with a different 4-5 digit prefix are going to be from another area of the product, another product, or will be direct Windows error codes.  Codes starting with "C0000..." are typically Microsoft.

0xdb3xxxx = Informational or Status

0x8db3xxxx = Error occurred

0xdb0xxxx = Antivirus informational or status

0x8db0xxxx = Antivirus Error

                 

To reach the decimal numeric return code to compare to the table below you can use the Windows Calculator in "Programmer" mode by doing the following steps:

1. Open Calc.exe
2. Go to View - Programmer (or just hit Alt-3 to go to programmer mode).
3. On the left side click the Hex radio button and enter in the right hand "low bit" value (the hex entry after 0xdb3 or 0x8db3, ignoring the leading zero, so you will have 3 digits, in this example "1b0") then click the radio button on Dec to switch to Decimal.  This will give the 4xx or 5xx resulting error code.

An alternative is to use an Online Hex to Decimal Converter.

Community Articles with details and troubleshooting steps regarding these possible error codes will continue to be created.

Overview

This document provides a list of required URL addresses for Shavlik Protect and Ivanti Patch for Windows Servers to allow:

• Patch executable download.
• Patch content definition download.
• Online license activation or license refresh.
• Home page RSS feed.
• Product check for update.

URL List

The following URLs may be used to download updates and must allowed through firewalls, proxies and web filters:

Additional Information

• To obtain the IP for vendor sites you can ping the vendor site or contact the vendor to obtain this information. We are unable to provide a list of IP addresses due to the varied dynamic IP addresses being used by the vendors. It may be easier to create an exception for an entire domain rather than entering all specific URLs, you can usually do so by entering the exception in this format:
  • *.domain.com.

when run the security scan it build the list and download the patches, but it gives error failed to run and ends with "Exiting with return code 0x8db3019c (412)."

we have around 5000 systems in our environment and found this error with close to 600 systems.

below is the error

Fri, 08 Jun 2018 18:38:46 ReportRepairResult returned failure: Repair failed

Fri, 08 Jun 2018 18:38:46 Message returned from repair script was Repair failed

Fri, 08 Jun 2018 18:38:46 ERROR(RunVbScript) Failed to run command  - 80004005

Fri, 08 Jun 2018 18:38:46 DownloadPatch ERROR: Failed to run commands (80004005).

Fri, 08 Jun 2018 18:38:46 Last status: Failed

Fri, 08 Jun 2018 18:38:46 DeferredReportAction: name 'Firefox_Setup_60.0.1esr_x86_tw14665-39666zh-tw.exe', code '1', type '-1', status 'Repair failed'

Fri, 08 Jun 2018 18:38:46 App killer is stopping

Fri, 08 Jun 2018 18:39:43 TimberHlpr DLL_THREAD_ATTACH called

Fri, 08 Jun 2018 18:40:50 TimberHlpr DLL_THREAD_DETACH called

Fri, 08 Jun 2018 18:40:50 TimberHlpr DLL_THREAD_DETACH called

Fri, 08 Jun 2018 18:40:56 Closing the status dialog.

Fri, 08 Jun 2018 18:40:56 remoteui set to true. Sending 2...

Fri, 08 Jun 2018 18:40:56 ClosePipes

Fri, 08 Jun 2018 18:40:56 ReadPipeMessage, h is NULL.  Returning false

Fri, 08 Jun 2018 18:40:56 ClosePipes

Fri, 08 Jun 2018 18:40:56 TimberHlpr DLL_THREAD_DETACH called

Fri, 08 Jun 2018 18:40:56 Exiting with return code 0x8db3019c (412).

Fri, 08 Jun 2018 18:40:57 TimberHlpr DLL_PROCESS_DETACH called

Fri, 08 Jun 2018 18:40:57 Process is terminating, cleaning scanner...

How would I go about blocking Adobe DC for a single PC. We have an application that is not compatible with Adobe DC. This application is only installed on one PC. I want to update all other PC's. Patch and Compliance is scoped by Active Directory OU.

Hello everyone,

EPM 2017.1.

in the Patch and Compliance, I do not see any patch related to the Skype App (I can see the desktop and the Business versions).

Just to be sure: is this kind of Skype version managed via Windows Store only ?

Thank you very much.

Marco

• Introduction
• Assumptions
• Outline
• Patch and Compliance Manager Basics
• Handling Replaced Definitions
• Download Patch Content
• Distribution and Patch Settings
• Scanning the Clients
• Repairing Clients
  • Creating a Custom Patch Group
  • Using a Custom Group to Repair
  • Expanding the Deployment
• Conclusion

Introduction

This document is designed to give a new Ivanti EPM Administrator a quick way to set up Patch Manager.  It is certainly not the only way to do it, but it will get you started so you have a solid starting place to build upon.

Assumptions

A license for patch manager is required for full functionality.  Without it, you will not see Vulnerabilities or Security Threats in Patch Manager.  You will have access to Ivanti Updates that can be deployed via Patch Manager to your clients.

It is also assumed that the Ivanti EPM core has been installed and agents deployed.

The core should have an Internet connection that allows access to LANDESK.com, Ivanti.com and vendor websites like microsoft.com, google.com, apple.com, adobe.com in order to download patches.  The clients will need access to the core server.

Outline

Patch and Compliance Manager Basics

Ivanti EPM uses definitions to scan clients for vulnerabilities.  Definitions are a group of rules that tell the scanning engine (vulscan.exe) what it should look for to determine if a machine needs a patch.

These definitions are written by Ivanti and are downloaded to the core server from the Ivanti Patch Content servers.

The Ivanti EPM administrator can determine which definitions are scanned on client devices.

A client must scan and be vulnerable to a definition before it will attempt to repair that vulnerability (apply the patch).

Handling Replaced Definitions

One of the advantages of using Ivanti EPM Patch and Compliance Manager is that as much as possible our scanning engine checks the version of files to determine if a patch is needed.  This allows us to only recommend the latest patches without wasting time installing patches that are replaced by newer patches.

1. Go into Tools - Security and Compliance - Patch and Compliance
2. Click on the icon that looks like a cog wheel (Configure Settings) - Definition Download Settings
   
3. Click New
   
   
   
4. Set Definition Type to Vulnerability
5. Severity to Any
6. Comparison to None
7. Under the Scan tab
8. Check "Assign Scan Status"
9. Select "Scan (Global)" in the "Global Scan Status" drop-down.
10. Select the checkbox "Disable any rules this definition replaces"
11. Click Ok
12. Click Close

For further information on handling replaced patches see How To: Manage Superceded Patches in Patch and Compliance Manager

Download Patch Content

As mentioned before, Ivanti produces definitions that tell the scanning engine what to scan and report on when scanning a client.  Before you can use this content, the core server must download the definitions.

1. From Patch and Compliance, click the yellow icon with the down arrow named "Download Updates"

2- Expand Windows - Software Updates

3- Check LANDESK Agent Health and LANDESK Software Updates

4- Expand Vulnerabilities

5- Check Microsoft Windows vulnerabilities

6- Click "Download now"

7- Once it is done, click close.

Distribution and Patch Settings

The "Distribution and Patch" Settings control how, when, and what vulscan will do when scanning for patches.

1. To modify Distribution and Patch Settings go to Tools - Configuration - Agent Settings.
2. In Agent Settings, expand "All agent settings"
3. Click on "Distribution and Patch"
4. Double-click on the Distribution and Patch Settings on the right side to open it up

Under "General Settings" you'll see items related to how files are downloaded and what notification users will see before running tasks.

Network Settings controls how files are downloaded and from where.

Policy sync schedule controls how often policies are checked

Notification controls what the end user will see while vulscan is running

We'll skip Distribution-only settings as they only apply to software distribution and not patch management.

Patch only settings are covered in this document: "Patch-only settings" in "Distribution and Patch" settings for LDMS 9.6

Scanning the Clients

Clients by default will scan once a day.

Here's how to create a scheduled task to run a security scan.  This will ensure the current information is up to date.

1. From the Patch and Compliance tool, select the Create a task button, then Security Scan
2. Optional - On the Agent Settings section you can choose to use a different "Distribution and patch settings" or leave it at the default to use the currently assigned setting on the client.
3. Click Save
4. This will take you to the Scheduled tasks tool. You know the drill.
5. Drag the machine to the task.
6. Right-click the task and select Start now -> All

Repairing Clients

Now that the clients have been scanned, we can use the "Detected" view to see which patches need to be applied.

In the Patch and Compliance tool, click on "Detected"

Then sort it by Severity.

It's recommended to first repair service packs and then Critical patches.

It's also recommended to test patches first to make sure they don't introduce any unwanted changes in your environment.

In the above screenshot, there are a number of Critical patches.  You can right-click on one or even multi-select a lot of them and chose to repair them.

However, this method only allows up to 25 patches to be applied at once.

In order to repair more than 25, a group must be used.

Creating a Custom Patch Group

To create a new patch group, click on "Groups" to expand it out.

Expand Custom Groups

Right-Click "My custom groups" and chose "New group"

Name it "TestPatchGroup" or whatever you choose.

Now that we have a group we can populate it with the patch definitions we wish to repair.

Go back to the "Detected" group and select the definitions.

Right-click on the selected definitions and click "Copy" as seen below

Next, right-click on your test group and select Paste.

Now select all the patches and right-click on them and select "Download" associated patches.

Select all the patches and click Download.

This will start the patch download.  Any patches that haven't been downloaded will be downloaded.  Those that have already been downloaded will be verified, and if the hash matches they won't be downloaded again.

Once the patches are downloaded, click "Close".

Using a Custom Group to Repair

Right-click on the custom group TestPatchGroup, select Repair.

This will bring up the Patch and Compliance - repair task dialog.

For now, we'll leave the "Add targets" set to "Don't add targets at this time"

Agent Settings can be used to change to the one created earlier.

Reboot Settings can also be changed here.  It is recommended that clients be allowed to reboot as needed.  Either in the current task or later in a controlled manner.  Files in use cannot be replaced during patching which will leave your machines unsecured by the patches until the reboot.

How to use Reboot Settings

Click "Save" to finish and the task will show up in Scheduled Task.

Drag and drop your test clients onto the task.

Right-click the task and select "Start Now - Devices that did not succeed".

This will start the patch task.

Expanding the Deployment

After testing the patches and important applications on your clients, it's time to expand the rollout of the patches.

Additional clients can be added to Scan task.

As additional definitions are detected on clients they can be added to the Repair Group and the patches downloaded.

Then additional clients can be added to the repair group.

Conclusion

At this point, you will have a decent understanding of the patching process.  Now you can refine the Distribution and Patch settings and the Reboot settings to better match the needs of your environment.

We are attempting to install Windows 10 1709 release.  I have followed both steps to install using patching and provisioning, not having any luck.  Both tasks fail.  I have gone over these instructions multiple times and can not figure out what I am missing.  All help is appreciated.

LANDESK Patch News Bulletin: LANDESK has Released Content that will Update Clients to Windows 10 Anniversary Update 04-AUG-2016

patching windows to 1709

Re: anyone been able to push 1709 update to windows 10 in LANDesk?

I am attempting to convert an existing WSUS server patching strategy to LanDesk.

My current WSUS Server patching strategy has all approved patches downloaded to the server when available and then each server is part of an AD group telling it when its OK to start Automatic updates.

So we have AD group for say "Sunday - 2AM" and "Monday - 5AM" and servers are members of the groups accordingly.

So in LD I created a bunch of different Agent settings to match my AD patch groups and then I apply the appropriate agent setting to each server.

So now I have a test server with its Agent settings listing the maint windows from 6pm to 7pm each night.

I created a repair task and scheduled it to run once at 5pm.  when the repair task runs at 5pm, it fails with a return code 491 - Some/All actions have been deferred until the next maintenance window.

I understand this message.

What I expect is that the patches have been downloaded to the server via the agent and then when its 6pm, the agent will start up and install the patches.

However, this is not happening and I'm not sure why?

Is it because I need to run the repair task during the maintenance window?  or do I need to have Autofix somehow enabled?

Just not sure why its not doing what I expect it to do.

any insight would be appreciated.

Hello all,

I have a large number of PHYSICAL machines on network with VMWare Tools installed -- The VMWare Tools update through LANDesk does not work (actually, it can't work at all since VMWare Tools executables simply throw an error on physical machines)

So I tried to uninstall VMWare Tools via VMware Tools "setup.exe" /s /c on a test machine. As far as I can tell, VMWare Tools is removed completely -- I've run several inventory scans since, and Inventory doesnt show VMWare Tools under Add/Remove Programs or Software Products.

Nevertheless, VMWare Tools seems to be detected by vulscan, and it still attempts (and fails) to run the fix.

Can anyone provide any insight as to why it's still detecting?

Product: Ivanti patch For Windows (9.3.0 : 4510)

Hi All

Hoping someone can save me from alot of extra work.

I have just taken over the Ivanti Patching for a number of estates in out company which where previously managed by a single user. When all the patching was set up it was set up under his Personal account. I am now in the process of taking over will be moving this to be managed by a Single Service Account, I have re-added required credentials fine, re-added the hosts fine. Off to a great start so far

When running a test Scan against a machine group 0 machines are discovered or scanned, in the machine group in question the VM's are there but there is no "Browse Credentials" assigned to the VM's. When I R-Click to add these credentials to the VM's the "Browse Credentials" Setting is Greyed out and not able to be selected. (see Image below for example)

My current solution to this is to manually re-add each individual VM back into the machine group which then presents the "Browse Credentials" with ones assigned and I am able to run a Scan successfully.

Is there a way round the "Browse Credentials" being Greyed out or is there a reason for this that can be worked around. There are multiple Machine groups with 200+ VMs whcih will need to manually added in so will take considerable time, where I could Select all and change the Brewse Credentials for all in one go if this was not greyed out.

Hope this issues makes sense and someone has some insight.

Thanks

Overview:

When attempting to run a vulnerability scan, the scan will fail.  On the Windows agent, if running in verbose, you'll see the scan hang on Verifying Device ID with the core.  If you browse the logs on the clients, either Mac or Windows, you'll see some 403 error codes similar to the example below.

Action SOAPAction: "http://tempuri.org/ResolveDeviceID" failed, socket error: 0, SOAPCLIENT_ERROR: 5.  Status code: 403, fault string: Retrying in 2 seconds...

On the Core, you may see "certificate not presented" for the agent you requested the security scan.

Cause

With Enhanced Client Security, it's imperative to have a clean certificate store on the local device for IIS.  Having a non-self-signed certificate in the Trusted Root Certification Authority will cause issues.  The installer will prompt you to remove bad certificates prior to proceeding with the install, but if you have a GPO that may restore the bad certificate.  For more information regarding this issue, see https://help.ivanti.com/docs/help/en_US/LDMS/10.0/default.htm#cshid=RootCertificateConfiguration

Validation

If you're having an issue with security scans and want to test a potential bad certificate:

1. Open Internet Information Services (IIS) Manager
2. Expand the Sites and click on the WSVulnerabilityCore application.
3. Open SSL Settings and set Client Certificates to 'Ignore' (default is 'Accept').
4. If the scan works, that is indicative of the problem. Leaving the configuration at Ignore is NOT recommended and could compromise the Enhanced Client Security.  This is just to test to see if a bad certificate is the cause.

Fix

1. Launch certmgr.msc on the Ivanti Endpoint Manager Core Server
2. Expand Trusted Root Certification Authorities
3. Click on the Certificates sub folder and review the certificates in the store, paying particular attention to the Issued By category.  Look for certificates that are not signed by the server itself or by a certificate provider and remove them.

On some systems(Core Servers) it may be necessary to change the following registry keys that affect how certificates are trusted:

Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL, Value name: ClientAuthTrustMode, Value type: REG_DWORD, Value data: 2

Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL Value name: SendTrustedIssuerList Value type: REG_DWORD Value data: 0 (False, or delete this key entirely)

For additional information, see Ivanti's article https://help.landesk.com/docs/help/en_US/LDMS/10.0/default.htm#cshid=RootCertificateConfiguration or Microsoft's article https://support.microsoft.com/en-us/kb/2802568

Hi

I am very new to the forums and Landesk in general

I have a problem upgrading windows 10 from 1511 to 1709 using patch and compliance.

Here is what I've done so far

I followed the below guide, downloaded the ISO from our Microsoft portal, we have both Enterprise and Pro in our environment so I created a file for both of them and  Landesk accepts them both as downloaded

How to upgrade to Windows 10 Creators Edition using Ivanti Patch Manager

Then I distributed the ISO's to our preferred server and created a repair job

this job I sent to a specific machine and within 2 minutes it showed Success

now for my stress factor..

Noting happened on the machine itself, I cannot see the package on the machine and it does not patch.

I have created several software packages and set up PXE booting for the environment but this one I cannot solve

I sent a package to the machine to check if I could install to it, and that works as it should

I hope you guys can point me in the right direction

Enhanced Vulscan Self-Update Feature

In LDMS version 2016.3 and later releases, the Self-Update feature that runs during vulnerability scans has been enhanced to grant additional capability and flexibility.

Vulscan Self-Update

In version 2016.0 SU5 and older, vulscan checks the ldlogon folder to see if any of the core-side self-update files are newer than those same files found on the client. If so, those files would get updated regardless of OS version and LDMS agent version.  In version 2016.3 and later, the self-updating process is smarter and vulscan includes the option to check for a minimum OS version and/or a minimum LDMS agent version if configured to do so.  If the core is not so configured, then self update will occur as usual.

The main benefit to this new system is that you can cause vulscan self-update to use one set of files for devices that meet or exceed your OS and Agent version specifications, and a different set of self-update files for devices that are below your specifications.  This is most helpful if you are still managing Windows XP or Server 2003 devices.

Which Files Are Updated?

The following files are monitored and can be updated:

• LDReboot.dll
• ldavhlpr.dll
• ldReboot.exe
• LDSystemEventCapture.dll
• localsch.exe
• ltapi.dll
• RollingLog.dll
• sendtaskstatus.exe
• softmon.exe
• softmon.sig
• vbscript.v55
• vulscan.exe
• vulscan.sig

Initial Setup and Configuration

If you wish to implement OS and Agent version checking for self-update, create a SelfUpdate subfolder in ldlogon and create an AppliesTo.ini folder within:

The appliesto.ini folder should have the following text:

[Requirements]

MinAgentVersion=10.1

MinOSVersion=6.1

In the example above it is configured for LDMS agent version 10.1 and OS version 6.1 (Windows 7) and is appropriate for the scenario of preventing XP devices from self-updating to the new agent version.  However you should change this to correspond to the actual versions you want to use if you have a different use case.

How it Works

When vulscan runs on a client, it will check with the core server to see if ldlogon\selfupdate folder exists and contains the appliesto.ini folder.  If found, vulscan will use the enhanced process and will use the files in the Self-Update folder for devices meeting or exceeding the versions specified.  Devices not meeting the agent and OS versions will self update from the ldlogon folder.  If the self-update folder or the appliesto.ini file are not found, vulscan will self-update all devices from the ldlogon folder.

Therefore, place the self-update files from your LDMS 2016.0 SU5 WinXP agent into the ldlogon folder, and place the updated files that match your upgraded core version into the self-update folder.  This will cause XP devices to retain self-healing properties through vulscan self-update, but use only the correct files for it's agent version of 2016.0 SU5.  Devices newer than XP will self-update using the correct and proper files that you have placed into the self-update folder.

Overview:

Ivanti Patch and Compliance now provides support for Office 365 versions 2013 and 2016.  Patch and Compliance administrators can now scan, detect, and remediate client devices that have Office 365 installed. For Office 365 version 2013, Ivanti leverages the Microsoft Office Deployment Tool to perform the remediation tasks for updating Office 2013 installations. For Office 365 version 2016, Ivanti has developed an Office Com API to perform remediation tasks for updating Office 2016 installations. Ivanti provides a utility (Office365Util.exe) for you to use to download the Office installation data and to check the hash for Office 2016 installation data. When the Office patches are downloaded, Ivanti Endpoint Manager will check the hash on the pertinent files to ensure validity.

High Level Process

1. The Ivanti administrator downloads Office 365 definitions from the Ivanti global servers.
2. Once the Office 365 definitions are downloaded to the core, the Ivanti administrator can scan for those Office 365 vulnerabilities.
3. In order to remediate (apply latest patches) detected vulnerabilities, Ivanti administrator have to manually run, on the core machine, a new tool provided by Ivanti (Office365Util.exe). Using this tool, the Ivanti administrator can choose the Office 365 versions that are relevant to the environment. The Ivanti Office 365 utility will download the patch binaries and the Microsoft Office deployment tool from the Microsoft cloud.
4. Once the patch binaries are downloaded to the core, the Ivanti administrator can apply the patches to all vulnerable endpoints using the standard method of applying patches.

Step 1: Download Content

Customers download the Office 365 vulnerability definitions, the O365Util.dll, and the Office365Util.exe from the Ivanti Global Host Content Server by downloading the latest Microsoft Windows Vulnerabilities.

Download Updates (Microsoft Windows Vulnerabilities)	Updating Definitions (Office365Util.exe/O365Util.dll)

Updating Definitions (MSO365)MSOFFICE 365 (Vul_Defs)	MSO365 (Vul_Defs)

Step 2: Launch Office365Util.exe

Upon successful content download, an Office365Utility folder is created under the LDLogon share and will contain the Office365Util.exe file provided by Ivanti.

\\Core_Server\LDLogon\Office365Utility

This utility will allow you to select the specifics regarding the Office 365 product you are patching. Launch this utility directly from C:\Program Files\LANDesk\ManagementSuite\ldlogon\Office365Utility\ by double-clicking on Office365Utility.exe
(do not try to run it via the network share \\Core_Server\LDLogon\Office365Utility or \\localhost\LDlogon\Office365Utility as you will get an error).

Step 3: Select Options from Office365Util

The view provided below displays the available options inside of the Office365Util application (Ivanti Office 365 Utility for Patch and Compliance):

Platforms	Deployment Tools

Channels	Office 365 (2013) Product List View

In order to successfully patch Office 365, select which Office 365 patch product updates to download in order to support client remediation. After selecting the desired product updates from the Ivanti Office 365 Utility for Patch and Compliance application, click START.

Office 365 Tool

The START action will do (2) things:

1. Create an Office365Tool folder under the LDLogon share and process the Microsoft setup.exe file
   
   

   \\Core_Server\LDLogon\Office365Tool

The contents of this folder will contain the Deployment Tool Type (2016 or 2013) selected during the download and all relative installation data applicable to the options selected in the Ivanti Office 365 Utility for Patch and Compliance
application. The display below will outline the contents of both Deployments Tools (2016 and 2013).

Office365Tool	Deployment Tool Options

2016 Content	2013 Content

   
      2. Create an Office365 folder under the LDLogon\Patch share that contains the patch files(s):

\\Core_Server\LDLogon\Patch\Office365

Patch Location

^Updated Office 365 patching is not designed to take advantage of our download technology. The client device will NOT download o365 patch files from a preferred server or peer device. The files will be retrieved from the default or non-default patch location.

Non-Default Patch Location

This section is only applicable to those who have changed the default download location for patches. After downloading the Office 365 patch updates and installation data with the Ivanti Office 365 tool, the following SOURCE will be in the vulnerability definition:

Office 365 (2016)

 

httpSourcesURL="Core_Server/LDLogon/Patch/Office365/DeploymentToolType/Channel/Architecture"

 

Ex: httpSourcesURL=http://2016E/ldlogon/patch/office365/2016/current/x64

Office 365 (2013)

httpSourcesURL=http://Core_Server/LDLogon/Patch/Office365/DeploymentToolType

 

Ex: httpSourcesURL= http://2016E/ldlogon/patch/office365/2013

In order for the Patch Install Commands in the vulnerability definition to interpret the correct patch location, the Custom Variable will have to be set in every MSO365 vulnerability definition.

To do this open the properties on the definition and select the Custom Variables tab. By default the value specified will resolve to the default patch location.

You will need to explicitly set the value to reflect the location your patches reside.

The Patch Install Commands section of the definition utilizes a script that resolves the Custom Variable.

References

How to change the default Patch Location for Security and Patch Manager

Microsoft Office 2016 Deployment Tool

Microsoft Office 2013 Deployment Tool for Click-to-Run

We have found there are times necessary to deploy the Cumulative patch instead of the Delta version. In our detection of Windows 10 patching we have made it so you can never deploy the Cumulative and Delta patch for the same month. This safety measure is put in place to prevent you from deploying both version to a machine and causing it to BSOD.

The article below explains how we determine with version to offer.

Next Gen: Why the Delta vs Cumulative Update is Offered for Windows 10

To get a definition for the Cumulative Only patch definition please contact support and request the KB number needed.

Support will be able to provide this definition, then you will be able to import it manually.

After importing this Cumulative only definition it is important to set the other versions of the Windows 10 patches to do no scan to prevent accidental deployment.

Known Examples

Some of the issues we have seen that indicate you may need the Cumulative patch when the Delta version fails.  In these cases Microsoft has recommended to use the Cumulative patch and not the Delta.

In the STDeployerCore.log it shows the return code from the installer '14081' and in the Event Viewer it shows the error 2147956481.

Error 2147956481 translates to 80073701

0x80073701 = ERROR_SXS_ASSEMBLY_MISSING

STDeployerCore.log

2018-06-25T18:55:12.7016944Z 10e0 I Authenticode.cpp:134 Verifying signature of C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows10.0-kb4284835-x64_delta-1803_V2_tw14820-40047.msu with CWinTrustVerifier

2018-06-25T18:55:14.1076288Z 10e0 V UnScriptedInstallation.cpp:30 Executing (C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows10.0-kb4284835-x64_delta-1803_V2_tw14820-40047.msu /quiet /norestart), nShow: true.

2018-06-25T18:57:33.2906542Z 10e0 V ChildProcess.cpp:140 Process handle 000006E4 returned '14081'.

• Introduction
• Types of available patch definitions
  • Servicing Updates
  • Major Updates
  • Finding Windows 10 RTM or Windows 10 Version 1511 devices
  • Disable or Enable Automatic updates in Windows 10
• Future Consideration - Long Term Servicing Branch

Introduction

This article discusses the different methods used to patch and update Windows 10 using Patch and Compliance Manager.

Microsoft releases updates in different ways and has recommendations on the cadence that should be used by businesses in different scenarios.

Windows 10 servicing options for updates and upgrades (Windows)

There are several methods that can be used to update Windows 10 through Patch and Compliance Manager.  Ivanti typically addresses these updates in the following ways:

Types of available patch definitions

Servicing Updates

These updates focus on Security and other important updates.   These updates are the "Patch Tuesday" updates that have been known in the past.   They are released every 2nd Tuesday of the month and they typically contain approximately 5-15 important updates.  So these updates do not differ from the past methodology with older Microsoft Operating Systems.

Ivanti typically releases content within 1-2 days after the content is published by Microsoft with very rare exceptions.

This information can be found in the Patch for Endpoint Manager Content Notifications section of the Ivanti Community.  Ivanti administrators are encouraged to subscribe to the RSS feed from the Community space.

At the time of this writing, this is the listing of Windows 10 cumulative patches:

• Note that the top two fixes have the same publish date. This is due to the updates applying to the two different versions currently released: Windows 10, and Windows 10 Version 1511
  These versions are also known by their build numbers (Windows 10 flat: 10240, Windows 10 1511 update: 10586.164

It is important to note that these are cumulative fixes.  That means that the latest cumulative fix contains files and fixes from all prior cumulative fixes.

As such, the cumulative fixes increase in size each time.  The latest one as of this writing was 640 meg, so the Peer Download and Preferred download technologies in Ivanti Management Suite are well suited for this.

For information about the patch itself and the fixes contained in the patch, you should double-click the definition and go to the Description tab.

1. Shows the description of the patch.  This is mostly a list of the hotfixes that have been rolled up into a cumulative patch.
2. Shows additional details.
   1. CVE ID - This link will take you to the "Common Vulnerabilities and exposures" web site with more information about these fixes. 
      As you will notice, there is a drop-down next to the "More information for CVE ID".  This is because there are a number of vulnerabilities that are covered by the cumulative patch.
      

      CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."

   2. Also there is the assigned CVSS score for the vulnerabilities addressed in the patch. 
      

      The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat.

   3. The "More information at" link will take you to the Microsoft Article about this update.  In this case: https://support.microsoft.com/en-us/kb/3140745

Major Updates

Major updates are used in the Current Branch for Business methodology.    This is for environments where a longer pilot testing period is desired prior to deploying.   Windows 10 version 1511 is an example of such an update.  These updates are expected ~ every 4 months or so.

Currently, this update is available in Ivanti Patch and Compliance Manager:

Finding Windows 10 RTM or Windows 10 Version 1511 devices

There are two definitions that can be used to find either Windows 10 Version 1511 installations or Windows 10 RTM installations (non-updated)

Disable or Enable Automatic updates in Windows 10

In addition there are two definitions for enabling or disabling Automatic Updates in Windows 10.

Future Consideration - Long Term Servicing Branch

This Windows installation should be used for devices that will remain in a more static state for a much longer period of time.  Examples would be Point of Sale devices, devices used in Healthcare and other devices.

This branch essentially is only updated when the next long-term version of Windows is released.  For example, if the next Windows version that Microsoft released was called "Windows 11", at this time the LTSB branch would be updated, and this would likely be an entire OS update which would require much more testing and a longer phased rollout.

As such, Ivanti has not released an LTSB update as one is not expected until the distant future.  More information will be available regarding utilizing Ivanti for updates to the LTSB version of Windows as that release approaches.

Issue

When attempting to patch there are a large about of detections of vulnerabilities that are not applicable to the client machine. When scanning, these definitions are flagged as detected for reason "Pre-req Check failed." This can cause numerous failures, bloated detected definition results, and incorrect logging.

Symptoms

To know whether or not you are getting a Pre-req check failure there are a few symptoms you can look for in order to know if this is the cause of your patch failures. This issue only occurs with Next Gen vulnerabilities.

1. Scan Failed returns

One of the first symptoms most customers notice is an abundance of "Scan Failed, Failed to start scan (0x1374900)" returns in their clients patching history. These returns are an indication that the core server received a failure to start the scan during Vulcan. This is due to important files not being in the proper location during the scan, more on that later.

2. Bloated "All Detected" patches list

The second symptom that can point to a Pre-req check failed is the bloated "All Detected" folder in the Patch and Security. This is normally filled with a large amount of detection of either previously undetected or not applicable vulnerabilities. Since there was a failure during the scan for these vulnerabilities they will be flagged as detected and will show up in this folder. When selecting one of your definitions you will see the reason for detection as "Pre-Req Check Failed."

3. Ivanti folders on the root of C:\

The final Symptom of this issue is the presence of two Ivanti folders that are being placed in the root of C:\.  "vulScan" and "LANDesk" will appear in the root of C:\ instead of the locations "ProgramData" and "Program Files(x86)" respectively. This is caused by them not being properly configured to the proper locations.

Resolution

This issue can be easily resolved by correcting the registry key where the vulScan folder should be properly located. Open Regedit and locate the following key

x64 Devices

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\explorer\Shell Folders

x32 Devices

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Here you will find the "Common AppData" key. If you are experiencing this issue it is caused by this key being blank. Simply add "C:\ProgramData" without the quotes then run a scan. This should allow for a proper scan and the vulScan and LANDesk folders will properly update in their designated locations. You are free to delete the folders on the C:\ root without any impact on the product.