Purpose

Agents can be installed via multiple methods, as follows:

Console Installation - Push Method

Agents can be installed from the console, in which case all the configuration prerequisites are the same as those for an agentless patch deployment - see Patch Scanning Prerequisites. This includes enabling the Remote Registry service on the target machine and verifying that the proper TCP ports are open. During the install process, the agent machine will need to successfully resolve the console via DNS and connect to the console via TCP 3121 in order to obtain the assigned policy. An agent policy must be created and configured prior to installation.

Push Method Steps

• Create a new machine group.
• Add the agent machine to the machine group using a machine name, domain name, or IP address. You cannot use the Install / Reinstall Agent button to install agents on machines that were added as Organizational Units, nested groups, or IP ranges.
• Specify the necessary, machine specific credentials.
• Select the machine, then select 'Install/Reinstall Agent'.

You can also select a previously scanned machine from the Machine View and select Install/Reinstall with Policy.

Manual Installation

Agents can be installed directly on the target machine, in which case the agent machine will need to successfully resolve the console via DNS and connect via TCP 3121. Additionally, either valid credentials for the console or a passphrase will need to be supplied. In the case of a passphrase being used, the passphrase will need to have been set on the console machine via the 'Agents' tab of the 'Tools > Options' menu. An agent policy must be created and configured on the console prior to installation. The preferred method of installation is as follows:

• Ensure that the console's data files have been updated successfully (click Help > Refresh files)
• Copy the 'STPlatformUpdater.exe' file from the console machine to the agent machine. This file is located in the following folder:
  C:\ProgramData\LANDesk\Shavlik Protect\Console\DataFiles
• Log into the agent machine using credentials with administrator level privileges on the local machine.
• Launch the installer.

Scripted Installation

Agents can be installed using a script. This method of installation is very similar to a manual installation, with the exception that the target machine will run the installation using the 'Local System' account, and that the necessary installation options must be specified as command line switches. See the administration guide for further details outlining the necessary syntax.

Once the agent has been installed, the installer files for the necessary components will be downloaded and executed. The components installed will depend what type of tasks are defined in the assigned policy (e.g, Patch tasks, Power tasks, etc.). The installer files, as well as all other necessary patch and data files, will be downloaded from the source as specified in the agent policy. If the agent is unable to obtain these files from the specified source, the agent will fail to perform as expected.

Installing Agents Using An Installation Script

Logs

The installation log files can be located in any of the following locations, depending upon installation method:

C:\Windows\Temp\

C:\Windows\Temp\{stringvalue}\

%temp%\

The log files will be named as follows:

STPlatform*.log

AgentInstaller.log

Once the agent has been successfully installed, further log files (including installation log files from component installations) can be located in the agent data files (within the '...\Logs' subdirectory).

How To: Collect Protect console, patch deployment and agent logs for troubleshooting

Additional Information

Our Agent Quick Start Guide can be found here:

Patch for Windows Server 9.3 - https://help.ivanti.com/sh/help/en_US/PWS/93/qsg-pws-9-3-agent.pdf 

Purpose

The purpose of this document is to outline the issues surrounding FileZilla updates particularly related to the downloading of the patch files from the vendor.

Cause

Changes from the vendor, Filezilla, has caused downloads of the updates not from a Web browser to fail with an error 403 authentication error. From review, the cause is the lack of user token authentication as updates downloaded through Patch for Windows are done on behalf of a user or system account, not as the actual user. Additional findings have shown the direct download links to also reroute to the main Filezilla site versus downloading the actual installer.

Resolution

The current workaround to this issue can be found in this document: How To: Supply and Deploy Patches That Can Not Be Downloaded

Additional Information

Filezilla Downloads Page: https://filezilla-project.org/download.php?show_all=1

Affected Product

Patch for Windows Servers 9.3

Purpose

The purpose of this document is to show how to assign a new user account to a user role IF:

• The new user account is created in a different OU other than "Users", when unchecking "Quck Search" doesn't display new user account.
• There are more than 100 users in "Users" and other OUs combined.

Symptoms

When attempting to assign a new user account for a user role, and if you have more than 100 user accounts throughout your organisation units in the active directory, chances are, you won't be able to see the new user account:

1. if you create it in a different OU other than "Users" OU as depicted in the screenshots below.
2. When you uncheck the "Quick Search"  box in the "Find User" pop-up

1)I created a new account named “Michael Long” in a different OU called “EDW”. This OU contains all other users. This is a normal domain user account.

   2) On the “Patch for Windows” management console, when clicking on “Manage – User Role assignment – New – Find User”

Clicking on the “Quick Search” will not display the new user account. This is because the “Quick search” function would only search for accounts within the “Users” OU on the active directory.

3) By right, when unchecking the “Quick search”, it will search for all the user accounts from all OUs on the active directory and display them in the result pane. But at times, you won’t be able to see the new user account listed, as shown below, the new user account “Michael Long” is not within the list. The user accounts are listed with alphabetical order.

Resolution

In this case, please add the new user account manually and create the new role.

1) Click New
2) Type in domain\username
3) Set Role
4) Click OK.

New account added

In the “Patch for Windows Administration” guide, it also states:

“All configured users must have access to the database. If users without administrative rights on the console machine receive an error when starting Ivanti Patch for Windows Servers, it probably means they don’t have the necessary SQL Server permissions.”

i) Apart from creating the new role based on the new user account, the new user account must exists in the SQL server.

ii) Please also add this new user in the local "Administrators" group on the "Patch for Windows" actual server.

iii) Last but not least, if you have any multiple active VM sessions for the Shavlik protect server, please close them all, and login using that new account. Or reboot.

Additional Information

According to internal sources, this scenario is an expected behavior. It is a limitation to the API we use to interact with AD to obtain the complete list of users. It is not a defect, and a change request to enhance the search feature in the future was already in place.

Affected Products

Shavlik Patch for Windows 9.x

Purpose

This document will explain why and how to fix scheduled scans that fail to run, but manual scans do work.

Symptoms

Scanning a machine runs immediately but when scheduling the tasks are failing to run.

Causes

1) When scheduling a scan, Protect requires a "Scheduler Credential". This credential is set under Manage > Scheduled Console Tasks.

2) The credential being used does not have Local System Admin rights and permissions. It must be a local Administrator, and it must be allowed to run scans under User Role Assignment.

Resolution

1) Look in Manage > Scheduled Console Tasks and determine which account is the scheduled jobs are being scheduled as

2) Log into the Protect server with those credentials.

3) Go to Manage > Credentials and recreate the credentials be set in the Machine Group (click option to share).

4) Log into Protect with the account you normally log in with.

5) Open the Machine Group and set the new credentials.

6) Scan without scheduling to make sure it works.

7) Schedule a scan for 5 minutes into the future to test.

Example: If the credential is domain\user1, then domain\user1 needs to log in to the Protect server, open the console, create the credentials, and assign them.

Additional Information

This document also pertains to scheduling the staging process.

This credential is used to place the scheduled task on Windows Task Scheduler and not used to login to the target machine.

Scheduled tasks are created and will be viewable in Windows Task Scheduler.

Affected Products

Ivanti Patch for Windows Server 9.3

Overview

Oracle has announced changes to ongoing support for Java SE 8 (Standard Edition). This article describes these changes and how Ivanti will continue its support for Java SE 8 in January 2019 and beyond.

In January 2019 Oracle will require those who wish to continue support for Java 8 SE on Servers, Desktops, and Cloud Deployments to subscribe to the new Java SE Subscription offering to continue to receive Java SE 8 updates. This subscription covers all Java 8 SE licensing and support needs. If you cannot migrate applications with dependencies on Java 8 over to Java 10 by then, this is your option to continue to gain security updates until you can transition.

The following End of Public Updates announcement was taken from the Oracle Java SE Support Roadmap.

“End of Public Updates of Java SE 8

Java SE 8 is going through the End of Public Updates process for legacy releases.  Oracle will continue to provide free public updates and auto updates of Java SE 8, until at least the end of December 2020 for Personal Users, and January 2019 for Commercial Users. Personal Users continue to get free Java SE 8 updates from Oracle at java.com (or via auto update), and Commercial Users continue to get free updates to Java SE 8 from OTN for free under the BCL license. Starting with the April 2019 scheduled quarterly critical patch update, Oracle Customers can access updates to Java SE 8 for commercial use from Oracle through My Oracle Support and via corporate auto update where applicable (Visit My.Oracle Support Note 1439822.1 - All Java SE Downloads on MOS– Requires Support Login).

Oracle does not plan to migrate desktops from Java SE 8 to later versions via the auto update feature. This includes the Java Plugin and Java Web Start. Instead of relying on a browser-accessible system JRE, we encourage application developers to use the packaging options introduced with Java SE 9 to repackage and deliver their Java applications as stand-alone applications that include their own custom runtimes.

Current releases remain free and open source for all users from jdk.java.net.”

Ivanti will continue to support Java SE 8, but will do so with what we refer to as “drop-in” support for products who have this functionality.  This means supported Ivanti Patch Management solutions will continue to detect and have logic to update Java SE 8 instances in your environment, but it will be up to the customer to provide the installer and drop it into the patch repository for remediation purposes. This change keeps both Ivanti and our customers in compliance with Oracle’s licensing for Java SE 8.

Additional Information

Please refer to instructions for the Ivanti Patch solution you are using for details on how “drop-in” support works in your product:

• How To: Supply and Deploy Patches That Can Not Be Downloaded

Supported Products

Ivanti Patch for Windows

Ivanti Security Controls (ISeC)

Ivanti Patch for SCCM

Purpose

The purpose of this document is to resolve the issue where the Windows 10 machines will fail to scan even though Remote Registry has been enabled previously.

Symptoms

Even after enabling the Remote Registry service on Windows 10 client machines, machines fail to scan with Error 501.

Cause

Windows 10 will disable the Remote Registry service by default when the computer is in idle and the service is not being used causing agentless scans to fail.

Resolution

1. On the client machine, open up your registry editor by typing regedit in the start menu and hitting enter.
2. Make the following modification in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RemoteRegistry:

• Name: DisableIdleStop
• Type: REG_DWORD
• Data: 1

Affected Product(s)

Ivanti Patch for Windows Servers 9.3

Ivanti Security Controls

As a part of our commitment to continuous improvement of self-help and online support, we wanted to give you advance notice of some upcoming changes.

We are currently migrating our Ivanti Communities (community.ivanti.com & community.shavlik.com) to a new site.

The migration is to help facilitate a seamless customer experience between our systems, as well as help unify our products under the Ivanti brand.

What does this mean for me as a customer?

You will use your same credentials to continue accessing forums, knowledge base, and the support/success portal.

Your access to support does not change.

Notifications from the community will now be sent to the registered email address (the one you log into the site with). Previously some users established a secondary email to receive emails at –this feature will no longer operate that way.

The look of the site and the structure of certain things will be different, so we will be hosting webinars to discuss some of these changes.

Please watch Community.Ivanti.Com for information about when these will occur.

(Recordings of these webinars will be available for on demand access)

When will the new site be live?

Community.Shavlik.com: Saturday December 15, 2018.

Community.Ivanti.com: Q1 2019.

Do I need to register for this new site?

If you are already registered for any of our existing support sites – you do not need to re-register.

This includes:

• Community.Ivanti.com
• Community.Shavlik.com
• Success.Ivanti.com
• Support.Ivanti.com

If you are not registered, you can choose to register with the site at any time to gain access to features such as downloads and support.

Purpose

This document will show you how to run/schedule the "Console Clean Up" ITScript to clean up your Patch Repository

The Patch Repository location is the path listed under "Patch download directory" in the Downloads tab under Tools > Operations (Tools > Options in 9.3)

The default location is C:\ProgramData\LANDesk\Shavlik Protect\Console\Patches

Symptoms

Your patch repository is taking up too much storage space storing old patches you no longer need

Steps

Go to Manage > ITScripts, and when it is done updating, close the pop-up if it did not close automatically

Under the "Maintenance" category, highlight "Console Clean Up" and click "Approve"

Then go to Tools > "Run console ITScripts"

The values listed are in Days (the default value for both is 180 days) - if you want to modify a value, double-click on the parameter you want to change (patchAge/deploymentAge) and enter the desired value

When finished, press "Continue" to proceed to the scheduling options

Click "Run" to run immediately, or select the scheduling options you want and click "Schedule" (the "Run" button changes to "Schedule" when you select scheduling options)

Affected Product(s)

Shavlik Protect 9.2

Ivanti Patch for Windows  Servers 9.3

Symptoms

When running a batch file as part of a Custom Action, the deployment hangs and never completes.

Cause

When Patch for Windows Servers (PWS) builds a deployment, it creates a batch file that is copied to the target machine. This batch file contains all the information related to that deployment, including what patches should run and with what switches. It also includes any Custom Actions that the user defined. This batch file will be referred to as the PWS Generated Batch. When the PWS Generated Batch executes, it initiates each task sequentially going through the list (one task must finish before the next can begin). When the PWS Generated Batch calls the user's custom batch file, the PWS Generated Batch waits for the user's custom batch file to return an exit code to indicate it is done. If the user's custom batch file is not accessed with an appropriate command, it will not return the necessary exit code for the PWS Generated Batch to continue through its pending actions.

Solution

If the Custom Action batch file is going to run an action that following actions are dependent on (example: batch file stops a service so a custom action can run a .exe), then utilize the CALL command.
The call command will allow the custom batch file to return an exit code to the PWS Generated Batch so it can continue on its jobs, once the custom batch file finishes.

Example:

Call %PATHTOFIXES%stop_services.bat

If the Custom Action batch file is going to present the end user with information that should stay open (example: a custom message that the batch file shows), then utilize the START command.
The Start command will begin the custom batch file, and once it has started, the PWS Generated Batch will continue without waiting for the custom batch file to close.

Example:

Start %PATHTOFIXES%show_warning.bat

These are CMD commands, not Ivanti custom commands. More info on CMD commands here: An A-Z Index of the Windows CMD command line | SS64.com

Related Documents

Custom Action - Using the Null Patch

Affected Product(s)

Ivanti Patch for Windows Servers 9.x

Ivanti Security Controls

Purpose

The Protect Cloud synchronization feature enables your agents to check in and receive policy updates from the cloud. This allows you to manage agents on machines that are not able to communicate directly with the console. This feature also provides you with the ability to install a Shavlik Protect Agent using the cloud.

Agents that are configured to use Protect Cloud will have two check-in options: they can continue to check in with the Shavlik Protect console, but they will also be capable of checking in and receiving policy updates via the cloud. This is particularly useful for disconnected agent machines that are away from the corporate network and unable to contact the console for updates. As long as an agent machine has Internet access, it will be able to send results and get updates using the cloud.

The following diagram illustrates the two agent check-in options:

FAQ

1) How does the cloud work?

The console makes changes to agent policies and syncs to the Protect Cloud server. The  Protect Cloud server is where Protect Cloud agents check in since they can't talk to the console. All patches that are needed are downloaded straight from the vendor's website.

2) How does a traveling worker get updates?

The cloud agent on the traveling worker's machine will first try to establish communication with the Protect Console in the domain even if its VPN. If that communication is not established, it will next try to connect to the Protect Cloud server and look for any updates to the policy. If there are updates, the policy change will be made to the Protect Cloud agent and if there are new patches they are downloaded straight from the vendor.

3) Is any activity from the Protect Cloud agent sent back to the console for reporting?

Yes, results will be sent back to the main Shavlik Protect Console, however it will take longer for those results to show up since there are more steps with the sync.

4) Will installing the Protect Cloud agent on a target machine take up another license seat?

No, since the machine was already used as a target machine either by being doing an agentless scan or if there was already an agent installed, it won't take up another license seat.

5) Does it cost more to use Protect Cloud?

No, this service does not cost any extra even if you are using Shavlik Protect Standard or Shavlik Protect Advanced. All you have to do is register your account by going into the Shavlik Protect Console and clicking on Tools > Operations > Protext Sync Cloud > Create a Protect Cloud account.

6) Can you initiate a scan from the console to the target machine through Protect Cloud?

No, you can only make changes to the Agent Policy and schedule the scan through that policy. The Protect Cloud agent is treated just like an agent on a target machine connected to the Protect Console and has all the same properties, except that instead of directly communicating to the Protect Console, it is instead communicating with the Protect Cloud server.

You can allow a user to initiate a task on their own. For more instructions on how to do this, please see the following article: Initiating a Task with an Off-Network Protect Cloud Agent

7) Is all the traffic encrypted between Console to Cloud and Cloud to Agent?

Yes, the Console and Agent talk to the Cloud so neither has to open an inbound port.  The Protect Cloud acts as the proxy between the two.  Communication between console\cloud and agent\cloud is HTTPS web service calls using a token to provide mutual authentication.  All policy and result data is encrypted so only the console and the agent can decrypt.  The Cloud cannot decrypt your data only ensure delivery to authorized agents\console.  All data is encrypted in transit and at rest.  Results are picked up every 15 minutes so there is only a small windows of the results data being at rest before the console picks it up.

8) How often does the Shavlik Protect Console synchronize with  Protect Cloud servers?

Every 15 minutes. This can be manually updated if the user needs a full sync by going into the Shavlik Protect Console and clicking on Tools > Operations > Protect Sync Cloud > Force full update now button.

9) Can I uninstall Protect Cloud agent but keep the Shavlik Protect agent still on the target machine without having to completely uninstall and reinstall the agent?

Yes, just go to the Shavlik Protect Console and change the Policy to not sync with Protect Cloud and update the policy on the target machine.

Affected Products

Patch for Windows Server 9.3+

Disclaimer

Please read this disclaimer before using this tool:  LANDESK Share IT Disclaimer

Description

The DPDTrace tool provides diagnostic scan output for troubleshooting Windows patch detection issues.

How to use the DPDTrace GUI

1. Download the latest version of the DPDTrace GUI.  Download Here
2. Extract the DPDTrace.zip to the desktop of the machine you will scan from.  This can be on a server remote to the target machine or on the target machine itself.  Support may specify where to scan from depending on the issue being diagnosed.
3. Open the DPDTrace GUI by double-clicking DPDTraceGUI.exe from the extracted folder.

   4. Choose Local to scan the local machine. The IP address or the Machine Name of the local machine will automatically populate.

   5. Choose Remote to scan a remote machine. You will need to provide a valid Machine Name or IP Address to scan.

   6. Enter a username with administrator access to the target machine.

          a. The format must be DomainName\UserName or MachineName\UserName depending on how you are authenticating to the target machine.

   7. Enter a valid Password. You can choose to un-check the Hide option if you wish to see your password for troubleshooting purposes.

Protect Version: (Ivanti Customers)

     8. Choose the Protect scan engine version to be used during the scan.

OEM Version: (OEM/SDK Partners/Customers)

     9. Choose the OEM scan engine version to be used during the scan.

Patch Type:

     10. Choose Patch Type to be used during the scan.

          a. We highly suggest leaving the defaults of Security Patches and Non-Security Patches selected unless a support tech requests a change.

     11. Click Run to start the scan.

     12. You will see Command Prompt popups and popups for the Rename HF.Log utility during the scan process.  Do not close either these.

     13. All popup windows will close and a new popup will occur once the scan is complete.  Click OK.

     14. The scan diagnostic is complete and all of the trace logs, scan outputs and registry exports have been zipped to this folder:  C:\Users\UserName\Desktop\DPDTrace\SendToSupport

          a. The zip file will be named HFCLi_YearMonthDay.zip

     15. Provide this zip file to support!  It will not pass through email filtration, so please attach it directly to your case on the support portal using the Add Attachment button.
           If you have any issues attaching this zip to the case, please let the support tech know so they can provide you with more options.

Additional Information

A command line DPDTrace tool can be used by customers who cannot run this GUI version:  DPDTrace command line logging tool used for patch detection issues

Purpose

This article explains how our detection determines whether the Delta or Cumulative version of updates are offered.

Description

Our detection logic will verify the 'UBR' value from the registry to determine if the Delta or the Cumulative update will be offered.

HKLM" Key="SOFTWARE\Microsoft\Windows NT\CurrentVersion" Value="UBR" (Update Build Revision)

• The Delta is offered if build version equals N-1. (N= Latest Build. Current build being offered minus one version level)
• The full Cumulative update is offered if build version is N-2 or less.

You will only be offered one or the other and never both.

Related Documentation

Windows 10 release information

Affected Product(s)

Ivanti Patch for Windows Servers (all)

Ivanti Security Controls (all)

Purpose

The purpose of this document is to address the error

Could not find a part of the path 'C:\Program Files (x86)\Update Services\Schema\baseapplicabilityrules.xsd'

when running the Configuration Checker in Patch for SCCM.

Symptoms

When running the Configuration Checker on Patch for SCCM, the below error shows when trying to test the setup of the plugin and the connection to WSUS.

In the Shavlik Patch.log file, you'll find the below message:

Connected to server version (6.3.9600.18694) using client API version (4.0.0.0). $$<Shavlik Patch><09-29-2017 08:52:18.771+300><thread=4 (0x4)>

Warning on check 'Check for a secure connection to the WSUS server.' : An SSL connection to the WSUS server is recommended. $$<Shavlik Patch><09-29-2017 08:52:18.784+300><thread=4 (0x4)>

Error on check 'A connection can be made to the WSUS server using the port specified.' : Could not find a part of the path 'C:\Program Files (x86)\Update Services\Schema\baseapplicabilityrules.xsd'.

Cause

The installation of WSUS has either become corrupt or was not installed correctly during the initial installation.

Resolution

A full reinstall and proper reconfiguration of WSUS is required to correct this issue.

Additional Information

Obtaining and viewing logs for issues related to Patch for SCCM

Microsoft TechNet: Could not find a part of the path 'C:\Program Files\Update Services\Schema...

Affected Product(s)

Ivanti Patch for SCCM 2.x

Purpose

This document provides a link to the Migration Tool User's Guide for Ivanti Patch for Windows Servers.

Information

Ivanti Patch for Windows Servers 9.3 Migration Tool User's Guide

Product(s)

Ivanti Patch for Windows Servers (all versions)

Overview

Oracle has announced changes to ongoing support for Java SE 8 (Standard Edition). This article describes these changes and how Ivanti will continue its support for Java SE 8 in January 2019 and beyond.

In January 2019 Oracle will require those who wish to continue support for Java 8 SE on Servers, Desktops, and Cloud Deployments to subscribe to the new Java SE Subscription offering to continue to receive Java SE 8 updates. This subscription covers all Java 8 SE licensing and support needs. If you cannot migrate applications with dependencies on Java 8 over to Java 10 by then, this is your option to continue to gain security updates until you can transition.

The following End of Public Updates announcement was taken from the Oracle Java SE Support Roadmap.

“End of Public Updates of Java SE 8

Java SE 8 is going through the End of Public Updates process for legacy releases.  Oracle will continue to provide free public updates and auto updates of Java SE 8, until at least the end of December 2020 for Personal Users, and January 2019 for Commercial Users. Personal Users continue to get free Java SE 8 updates from Oracle at java.com (or via auto update), and Commercial Users continue to get free updates to Java SE 8 from OTN for free under the BCL license. Starting with the April 2019 scheduled quarterly critical patch update, Oracle Customers can access updates to Java SE 8 for commercial use from Oracle through My Oracle Support and via corporate auto update where applicable (Visit My.Oracle Support Note 1439822.1 - All Java SE Downloads on MOS– Requires Support Login).

Oracle does not plan to migrate desktops from Java SE 8 to later versions via the auto update feature. This includes the Java Plugin and Java Web Start. Instead of relying on a browser-accessible system JRE, we encourage application developers to use the packaging options introduced with Java SE 9 to repackage and deliver their Java applications as stand-alone applications that include their own custom runtimes.

Current releases remain free and open source for all users from jdk.java.net.”

Ivanti will continue to support Java SE 8, but will do so with what we refer to as “drop-in” support for products who have this functionality.  This means supported Ivanti Patch Management solutions will continue to detect and have logic to update Java SE 8 instances in your environment, but it will be up to the customer to provide the installer and drop it into the patch repository for remediation purposes. This change keeps both Ivanti and our customers in compliance with Oracle’s licensing for Java SE 8.

Additional Information

Please refer to instructions for the Ivanti Patch solution you are using for details on how “drop-in” support works in your product:

• How To: Supply and Deploy Patches That Can Not Be Downloaded

Supported Products

Ivanti Patch for Windows

Ivanti Security Controls (ISeC)

Ivanti Patch for SCCM

Purpose

This document will walk you through on configuring your machine so that it can be scanned using local account credentials.

Symptoms

Although you have the correct local account credentials defined and assigned, scans on your machine fail. Errors include 451 The specified user account requires administrative rights to the target machine, 452 Unable to connect to the remote machine or 5: Access is Denied.

Resolution

• Run regedit and locate the following registry key:
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
• With that key highlighted, click Edit > New > DWORD (32-bit) Value
• Type LocalAccountTokenFilterPolicy and then press Enter to name and create the new value
• Double-click the new LocalAccountTokenFilterPolicy value and change the value to 1 and click OK to save it

For more details on disabling UAC remote restrictions, see http://support.microsoft.com/kb/951016

Additional Information

Refer to this portion of the Agentless Patch Scanning Prerequisites.

Affected Versions

Patch for Windows Servers 9.3.x

Ivanti Security Controls (all)

WannaCrypt (also known as WanaCrypt0r 2.0, WanaCry or Wcry) is an encryption-based ransomware attack, that started spreading globally on May 12th.

The malware encrypts files on affected systems using AES and RSA encryption ciphers, meaning hackers can decrypt system files using a unique decryption key.

WannaCrypt changes the computer's wallpaper with messages, asking the victim to download the decryptor from Dropbox and demanding hundreds in bitcoin to get their files back.

Attack vector

WannaCrypt uses multiple attack vectors:

• The primary attack vector is distribution via e-mail. WannaCrypt uses social engineering or phishing techniques, relying on users to open and execute a malicious payload embedded within the e-mail. When opened by the user, the malware will install itself and start encrypting files immediately.
• WannaCrypt will then try to spread within the network or over the internet, using exploit code for vulnerability CVE-2017-0145, which allows remote attackers to execute arbitrary code via crafted packets to an SMBv1 server, aka "Windows SMB Remote Code Execution Vulnerability". This vulnerability is only present in the SMB v1.0 protocol. Microsoft released a patch in March: Microsoft Security Bulletin MS17-010. For more information about this update, see Microsoft Knowledge Base Article 4013389.
• All windows versions from Windows XP to Server 2016 are affected; all of these systems have SMBv1 enabled by default. Windows 10 is not affected. On May 13th, Microsoft released an emergency security patch for unsupported versions of Windows, including Windows XP, Vista, Windows 8, Server 2003 and 2008 Editions.

How to protect against WannaCrypt and other ransomware?

• Keep your system Up-to-date: Shavlik Protect, Shavlik OEM (SDK) and Ivanti Patch for Windows Server, Update the XML to 2.0.2.2723 and deploy MS17-010 and ensure that the most recent bundles have been deployed. This was originally plugged in the March Patch Tuesday release so the following bulletins will resolve the vulnerability.
• Content release 06/13/2017:

  • Updated MS17-010(Q4012598): Added patches for Windows 8, Windows XP and Windows Server 2003, Windows Vista, Windows Server 2008

• If you are using Monthly Rollups - June 2017 Patch Tuesday
  • MS17-06-MR7(Q4019264): Monthly Rollup for Windows 7 and 2008 R2: June 13, 2017
  • MS17-06-MR8(Q4019216): Monthly Rollup for Server 2012: June 13, 2017
  • MS17-06-MR81(Q4019215): Monthly Rollup for Windows 8.1 and 2012 R2: June 13, 2017
  • MS17-06-2K8(Q4018466): Security update for the Windows SMB Information Disclosure Vulnerability in Windows Server 2008: June 13, 2017
• If you are using Security Only Updates or Bundles - March 2017 Patch Tuesday
  • Windows 7 and Server 2008 R2: SB17-002[MS17-010](Q4012212): March 2017 Security Only Quality Update for Windows 7 SP1 and Windows Server 2008 R2 SP1
  • Windows 8.1 and Server 2012 R2: SB17-003[MS17-010](Q4012213): March 2017 Security Only Quality Update for Windows 8.1 and Windows Server 2012 R2
  • Windows Server 2012: SB17-004[MS17-010](Q4012214): March 2017 Security Only Quality Update for Windows Server 2012
• Any of the Security Monthly Quality Rollup for the above Operating Systems from June 2017 and later will also remediate this as is shown below.

Video demonstrating how to patch and report on the Wannacrypt vulnerabitity in Ivanti Patch for Windows Servers (Shavlik Protect). This also works for the Petya vulnerability patches.

• Beware of phishing: never open e-mail attachments from an untrusted sender or click on links within e-mails or documents without checking the source. Ivanti Anti-Virus can also scan incoming e-mail.
• Regularly backup user data: create copies of all user data at regular times to prevent data loss, should a ransomware attack occur.
• Enable Windows firewall: limit the spreading of ransomware within the corporate network by correctly configuring firewalls. Block access to SMB ports over the network and/or the Internet. The protocol operates on TCP ports 137, 139 and 445 and over UDP ports 137 and 138.
• Block legacy protocols such as SMB v1: See the following article on how to enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server (Note: Windows XP only supported SMB v1).
• Audit installed software and keep it up to date: malware often uses flaws in outdated software. Keep all installed software up to date, not only on end nodes but also in the data centre. Patch Manager will also detect vulnerabilities in many third-party software, other than the operating system.
• Ivanti free 90 day offer: When a global threat like WannaCrypt comes along, it's up to all of us in cyber security to make sure we shut it down.To help minimize its impact, until June 15, 2017, we're offering a free 90-day license for the best-in-industry patch management solution that's tailored to your system needs.  Register for Ransomware Get Well Quick trial.

Indicators of compromise

WannaCrypt creates the following registry keys:

• HKLM\SOFTWARE\WanaCrypt0r\wd = "<malware working directory>"
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\<random string> = "<malware working directory>\tasksche.exe"

It will display a ransom message on the desktop wallpaper, by changing the following registry key:

• HKCU\Control Panel\Desktop\Wallpaper: "<malware working directory>\@WanaDecryptor@.bmp"

Files created in the malware's working directory:

• %SystemRoot%\mssecsvc.exe
• %SystemRoot%\tasksche.exe
• %SystemRoot%\qeriuwjhrf
• b.wnry
• c.wnry
• f.wnry
• r.wnry
• s.wnry
• t.wnry
• u.wnry
• taskdl.exe
• taskse.exe
• 00000000.eky
• 00000000.res
• 00000000.pky
• @WanaDecryptor@.exe
• @Please_Read_Me@.txt
• m.vbs
• @WanaDecryptor@.exe.lnk
• @WanaDecryptor@.bmp
• 274901494632976.bat
• taskdl.exe
• Taskse.exe
• Files with “.wnry” extension
• Files with “.WNCRY” extension

What if I'm compromised?

Once ransomware has encrypted files, there is not much you can do. Sometimes, ransomware has been badly written and it has been possible - by reverse engineering their code - to find a way to decrypt the data.

This does not seem to apply to WannaCrypt and we are unaware of a way to recover encrypted data at this time.

One might ask if paying the ransom will really decrypt the files. Sometimes it will, but there is no guarantee.

When Cryptolocker hit a few years ago, some users reported that they did get their data back after paying the ransom.

More information: Webinars

Live Updates on the Ransomware Attack from Our CISO, Director of Security and Chief Technologist

May 15, 2017 - 9:00 PDT | 12:00 EDT | 17:00 BST | 18:00 CEST

Ivanti Webinar Series

Ransomware Update: New Threats, New Defenses

September 14, 2016

Stephen Brown, Director of Product Management, Ivanti

Passive Protection Against Ransomware

June 01, 2016

Eran Livne, Principal Product Manager, Ivanti

Statement regarding Ivanti's Own Environment

To date, Ivanti has not detected the WannaCrypt malware in our environment.

In advance of the threat, we took the following proactive steps to fortify our environment against these types of threats:

• We verified that our AV is installed, up to date, and active on client devices and servers, both internal and cloud / customer-facing.
• We verified that appropriate patches from Microsoft and third parties are installed and correctly configured in a timely manner.
• Where appropriate, we use Application Control for whitelisting, privilege management, and system monitoring.
• We constantly educate our employees on the risks of phishing, monitoring our incoming emails.
• We leverage third-party tools to actively monitor email for ransomware and other malicious URLs.
• We leverage third-party tools to monitor infestation and proliferation of malware in our internal and customer-facing IT environments.

Since this threat emerged, we have taken the following additional steps:

• We have educated our staff about this particular threat and reinforced the importance of not opening files or clicking on links from unknown sources.
• We have verified that our network infrastructure does not block access to the kill switch URL.
• We have audited our environment against all the above measures.

Ivanti free 90 day offer

When a global threat like WannaCrypt comes along, it's up to all of us in cyber security to make sure we shut it down.To help minimize its impact, until June 15, 2017, we're offering a free 90-day license for the best-in-industry patch management solution that's tailored to your system needs.  Register for Ransomware Get Well Quick trial.

Bookmark this page, we will add updates as they become available. Our patch content teams are currently working to include the emergency security patches in our patch content.

Purpose

This document outlines how to work around a minor issue that can occur when installing Patch for SCCM.

Symptoms

In some circumstances, it has been seen that when installing Patch for SCCM 2.4.29206, you are asked to install a language version of .Net Framework 4.7.1 that does not match the base language of the server that you are installing Patch for SCCM on.

Resolution

• At this point, ensure that the .Net Framework version relevant to your server is installed.  Bypass the prerequisites install by pressing CTRL+S.  You can then continue to install the product as normal.
• This will be fixed in a later version of Patch for SCCM.

Affected Product

Patch for SCCM 2.4

Symptoms

• Patch for Windows upgrade failure.
• Patch for Windows install failure.
• You may see a pop-up error:

Error 1603: A fatal error occurred during installation

Error 1605: This action is only valid for products that are currently installed.

Error 1612: The installation source for this product is not available. Verify that the source exists and that you can access it.

Purpose

Patch for Windows may become corrupt or unstable due to multiple reasons.  Corruption to the Windows Installer, Installer folder or other corruption to the automated uninstall process is a typical root cause. When this occurs a manual uninstall of Patch for Windows is necessary.  This article provides information on manually removing Patch for Windows from a server. This should only be used as a last resort to clean up a broken installation of Patch for Windows.

Resolution

Microsoft provides assistance with the manual uninstall process by providing a Fix it tool.  The link to the tool is: Fix problems that block programs from being installed or removed

How to use the Fix it tool

1. Use the link above to navigate to the Fix it main page.
2. Click on ‘Run Now’ and choose ‘Save File’.
3. Run the EXE that is downloaded and choose ‘Accept’ on the first page.
4. Choose the second option ‘Detect problems and let me select the fixes to apply’.
5. Choose the ‘Uninstalling’ option
6. You will see a list of the installed products on the server.  Choose the product if you see it on the list for instance. ‘Shavlik Protect’.  If you do not see the product on the list then select ‘Not listed’.

If Shavlik Protect, vCenter Protect, Netchk Protect, Patch for Windows is listed:

1. Choose the corresponding name and click ‘Next’.
2. Choose ‘Yes, try uninstall’
3. Verify both options are check-marked and click ‘Next’.
4. You should see a screen that indicates whether the product was uninstalled or not.
5. Click ‘Next’ and the close out of the screen.

If Shavlik Protect, vCenter Protect, or Protect is Not Listed:

1. Choose ‘Not Listed’ and click ‘Next’.
2. Enter the product code for the version of the Product installed and click ‘Next’. (Include the brackets)

          (Product codes are listed below)

1. Verify both options are check-marked and click ‘Next’.
2. You should see a screen where it indicates whether the product was uninstalled or not.
3. Click ‘Next’ and the close out of the screen.

Product GUID codes:

Make sure to use the corresponding GUID for the version of Protect you are attempting to uninstall.

• Protect 7.0.832.0: {C6D1AE7C-DE93-4E93-A916-C4144525C82C}
• Protect 7.0.841.0: {C6D1AE7C-DE93-4E93-A916-C4144525C82C}
• Protect 7.1.410.0: {90047C28-0B1B-4B30-8177-50729907EBF2}
• Protect 7.2.155.0: {9B7F1E45-4C47-4E25-9EAB-098923E4171C}
• Protect 7.5.2716.0: {CEA2D643-08C0-422E-9B27-B58ED9D38D07}
• Protect 7.6.1482.0: {661A3308-5BE2-4E0F-A752-BDDB247DD2DB}
• Protect 7.8.1340.0: {0A4D8D5E-7177-4A45-8A7F-0A5757403F97}
• Protect 7.8.1388.0: {0A4D8D5E-7177-4A45-8A7F-0A5757403F97}
• Protect 7.8.1392.0: {0A4D8D5E-7177-4A45-8A7F-0A5757403F97}
• Protect 8.0.3756.0: {F77AFB04-D13F-48DA-BB99-A5B31B6AAE0B}
• Protect 8.0.3965.1: {5A696B05-9F06-4B3D-83A0-69E848EFAC4A}
• Protect 8.0.4027.2: {5A696B05-9F06-4B3D-83A0-69E848EFAC4A}
• Protect 9.0.1106.0: {8045AD29-C6A4-43F5-9F1F-9560EB09F99A}
• Protect 9.0.1182.0: {070964CB-00B0-4E36-A3F6-A09F76FBD197}
• Protect 9.0.1182.0  {B7F5FF6F-382B-8834-3B85-B6390F7F4DA1}
• Protect 9.1.4334.0: {83593D3F-ADD7-491B-82EC-1A2E6D08C385}
• Protect 9.1.4472.0: {83593D3F-ADD7-491B-82EC-1A2E6D08C385}
• Protect 9.2.4988: {063C2D00-E6D5-6624-4903-4EEB4561AE61}
• Protect 9.2.5046: {063C2D00-E6D5-6624-4903-4EEB4561AE61}
• Protect 9.2.5119: {063C2D00-E6D5-6624-4903-4EEB4561AE61}
• ScriptLogic Patch Authority Ultimate 8.0.3756: {A8210996-CD25-4C8C-A2D7-207635DEDC28}
• ScriptLogic Patch Authority Ultimate 8.0.4027: {86DE6110-3F1C-40EE-98D9-05CD7A4B212F}
• ScriptLogic Patch Authority Ultimate 9.0.1182: {0EAD1B8A-6F58-2304-A817-34C1724CE04C}
• Patch for Windows Servers 9.3 Console: {5240C49D-72A5-4EE6-8687-C1F8DBD849CC}
• Patch for Windows Servers 9.3 Agent: {863EACA4-E689-4284-BEE2-8C5DE09E32BA}
• Patch for Windows Servers 9.3 Agent Patch Engine: {E9C4A462-8F43-4959-A6C6-B63E6D0050BA}
• Patch for Windows Servers 9.3 Agent Asset Engine: {0D593038-F0EF-4F93-8134-2DA47CA016EB}

Delete the relevant certificates. (You will need to reinstall all agents after performing this step)

1. ClickStart>Run, type MMC, and clickOK. The MMC Snap In window opens.
2. ClickFile>Add/Remove Snap-In.
3. Under Available Snap Ins, selectCertificates.
4. ClickAdd.
5. Select theComputer Accountoption and clickNext.
6. Ensure that theLocal Computeroption is selected and then clickFinish.
7. Click OK.  You should now see Certificates listed under Console Root.
8. Expand Certificates.
9. Delete these certificates that are listed as being issued by ST Root Authority:

• Personal\Certificates
• Trusted Root Certification Authorities\Certificates
• Intermediate Certification Authorities\Certificates

   10. Close the MMC window.  At this point, install the latest version of Protect.

If you continue to encounter any install errors, contact Ivanti support: Ivanti Support Portal

If the Fixit tool fails to correct the error, you may need to manually delete an upgrade key located under HKEY_CLASSES_ROOT\Installer\UpgradeCodes in the registry. Then try reinstalling Patch for Windows with the latest installer.

Known Upgrade Codes:  [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\UpgradeCodes\B7F5FF6F382B88343B85B6390F7F4DA1]

Additional Information

The Fixit utility is provided by Microsoft. Make sure you read any known issues or guidelines for this tool on Microsoft's site prior to use.

Affected Products

Patch for Windows - All version

Overview

These instructions will help you enable All logging (verbose logging) then those collect logs and supporting information to help Support troubleshoot issues on your console and remote clients.

Instructions

Ivanti Patch for Windows Servers (PWS) 9.X Console Logging:

1. Open the Patch for Windows GUI and navigate to Tools > Options > Logging and change logging to All for both user interface and services.

     a. If you are unable to set logging via the GUI see this doc: http://community.shavlik.com/docs/DOC-22938

2. Close the console GUI.

3. Stop the 'Ivanti Patch for Windows Servers Console Service' service.

4. Delete the contents of C:\ProgramData\LANDesk\Shavlik Protect\Logs on your console.

     a. If troubleshooting agentless deployment or scheduling, delete the contents of C:\Windows\ProPatches\Logs on your target machine as well.

5. Start the 'Ivanti Patch for Windows Servers Console Service' service and open the Patch for Windows GUI.

6. Attempt to reproduce the issue.  Please document steps to reproduce.  Screenshots are very helpful.

7. Collect the logs from the Logs folder(s) from steps 4 (please zip).

     a. Include applicable screenshots.

     b. [Deployment issues only] On the target system, zip a copy of the entire C:\Windows\ProPatches folder and its contents (exclude the Patches sub-folder).

8. Zip everything together and attach to the case on the support portal.

Shavlik Protect - Ivanti Patch for Windows Servers Agent Logging:

1. You will need to set your agent's logging level to All by opening the Agent Policy assigned to the machine you are gathering logs from. The option is in the General tab.

2. If not already set, change the logging level to ‘All’ then Save and update Agents. Choose to update agents if prompted again.

     a. If Patch for Windows fails to update the agent, you will need to perform an Agent Check-in from the agent GUI on the target machine or wait for the scheduled check-in.

3. Remote to the agent client machine, close the agent GUI and stop the services:

     a. The services start with Ivanti or ST.

4. Delete the contents of theC:\ProgramData\LANDesk\Shavlik Protect\Logs folder on the agent client machine.

5. Start services that start with Ivanti or ST.

6. Attempt to reproduce the issue.  Please document steps to reproduce.  Screenshots are very helpful.

7. Take applicable screenshots of errors or information relevant to the issue.

     a.  Collect the logs from step 4.

     b.  Collect the screenshots.

8. Zip everything together and attach to the case on the support portal.

Ivanti Patch for Windows Servers Deployment Logging: (the information collected here is specific to agentless deployments)

1. Navigate to the target machine with the deployment issues.

2. Stop all services that start with Ivanti or ST.

3. Attempt to reproduce the issue.  Please document steps to reproduce.  Screenshots are very helpful.

4. Delete the patches from C:\Windows\ProPatches\Patches.

5.  Zip the entire C:\Windows\ProPatches folder.

     a. Include applicable screenshots.

6. Zip everything together and attach to the case on the support portal.

Ivanti Patch for Windows Servers install issues:

• Where can I find Patch for Windows Console and Agent installation logs?
  

Affected Products

Ivanti Patch for Windows Servers 9.3+