We are pleased to announce that VSA 9.5.0.22 is immediately available for on premise installation. As a reminder, this release is a combination of .21 and .22

NOTE: A key requirement for this release is a minimum of .NET version of 4.7.2. The installer should verify the proper version and install 4.7.2 if .NET does not already meet this requirement, but we recommend that you confirm your VSA server is running the proper version.

 

For SaaS customers, 9.5.0.22 will be deployed to a subset of servers this Saturday, 7/20/19, with the remainder of servers to receive the update on 7/27/19.

NOTE: All SaaS servers are currently running VSA 9.5.0.21.

 

You can find the release notes here.

9.5.0.22 Patch Releases - 17 July 2019

This release requires agent version 9.5.0.12. Be sure to update your Windows, Mac, and Linux agents after installing this release.

This release requires .NET version 4.7.2 or later. The installer should automatically update .NET, if necessary.

New VSA User Interface

This release introduces a new VSA User Interface. These requirements must be met to use this feature:

• VSA must be running release 9.5.0.21 or later.
• The VSA server must be HTTPS enabled.

For On-premise customers, the installer confirms whether the VSA is HTTPS ready and, if so, displays the new UI by default.

For SaaS customers, the new UI is enabled by default.

The following considerations apply to the new UI:

• Custom logos – In release 9.5.0.21 only, custom logos on Partition 1 (Master) are replaced with the VSA logo. Tenant logos remain the same.
• UI templates – There is a known issue where templates created in the classic UI do not sort correctly. To fix this, recreate the template from the base template in the new UI.

To check whether HTTPS is enabled, launch a browser and connect to the VSA UI. If you see Not secure, HTTPS is not enabled:

How to enable the new UI if you’re HTTPS capable

1. Go to System > Server Management > Default settings > Enable the Classic User Interface and edit your preference:

1. Log out and back in to the VSA UI to display the new UI.

1-Click Access for Live Connect & Remote Control

This release introduces a new 1-Click Access feature that enables administrators and other authorized users to log in to a Windows agent right from the Live Connect > Remote Control menu or from the Quick View window. (VSA-4380)

See the topics below to get started with 1-Click Access.

How it works

The 1-Click Access feature attempts to run when the 1-Click Access button is clicked (either from the Live Connect > Remote Control menu or from the Quick View window) to any authorized Windows 9.5.0.12+ agent. An agent or a user role can be authorized from the VSA, under Remote Control > Policy Settings > User Role Policy/Machine Policy. Once the machine or user role has been authorized, the 1-Click feature becomes enabled in Quick View and Live Connect.

The feature starts by checking whether the KaseyaAdmin account exists on the target endpoint. If the account does not exist, then it is created with a randomized password. For additional security, the password for the account is then randomized during each subsequent login onto the 1-Click Access session and every time the session is disconnected. For more on private sessions, see Kaseya Remote Control in the VSA User Guide.

Note: If a KaseyaAdmin account exists on your system prior to activating 1-Click, your KaseyaAdmin account password will be changed and it will become inaccessible.

Next, KaseyaRemoteControlHost verifies that the account is part of the Administrators group and the Remote Desktop Users group and, if needed, moves the account into these groups. Once these steps have been completed, the account name and password are given to the RDP remote control process so that the KaseyaAdmin account is automatically used to log in. If another user is logged into the machine, there may be a message indicating that the other user will be disconnected from their session if the 1-Click user continues. If there isn’t another user logged in, this does not happen and the session begins immediately.

At this point, the private 1-Click session has been successfully connected. In the event that any of the above steps fail, 1-Click Access is aborted and a private session is used instead. If the private session fails, the user has the option to fall back to a shared remote control session. Once the session is connected, it is logged to the Agent Remote Control logs located in Agent > Agent Logs > Technician Logs > Remote Control. This information, like other remote control sessions, can be included in reports (Logs > Kaseya Remote Control Log report).

Note: Connecting two 1-Click sessions to the same machine is not supported. If two people attempt to open 1-Click sessions to the same machine, one or the other may be kicked off of the machine, or both sessions may fail entirely.

For more on private sessions, see Kaseya Remote Control in the VSA User Guide.

1-Click Access requirements

The following requirements must be met to use the 1-Click Access feature:

• VSA – The VSA must be running version 9.5.0.21 or higher.
• Windows machine –

  Note: We do not recommend 1-Click Access be allowed on a domain controller.

  • Operating system – The following operating systems are supported: Windows 7, 8, 8.1, 10, Server 2008 R2, Server 2012 R2, Server 2016, and Server 2019.
  • Remote access – The Windows machine must have remote access enabled and must not have network level authentication enabled, as shown here:

• Windows agent –

  Note: Mac and Linux agents are not yet supported.

  • The Windows machine must be running an authorized agent that is version 9.5.0.12 or higher. Agents are not authorized for 1-Click Access by default. To authorize an agent for 1-Click Access, see To authorize an agent below.
  • Remote Control must be enabled for the agent.
• VSA user – 1-Click is available to master administrators by default and can be enabled for other user roles. To enable 1-Click Access for a user, see To authorize a user below.

Note: There is a known issue (VSA-6807) that may affect the Machine Policy’s precedence over the User Policy. This will be addressed in an upcoming release.

To authorize an agent

Use these steps to enable 1-Click Access for an agent:

1. Log in to the VSA user interface as a master or system user.
2. Navigate to Remote Control > Policy Settings > Machine Policy.
3. Select a user notification type from the list.
4. Check the 1-Click Access box.
5. (Optional) Check Require admin note... and Record all remote control session....
6. Select one or more Machine.Group IDs. Click Apply.

To authorize a user

Use these steps to enable 1-Click Access for a user:

1. Log in to the VSA user interface as a master or system user.
2. Navigate to Remote Control > Policy Settings > User Role Policy.
3. Select a user notification type from the list.
4. Check the 1-Click Access box.
5. (Optional) Check Require admin note... and Record all remote control session....
6. Select one or more Role Names. Click Apply.

To run a 1-Click session from Live Connect

In Live Connect, you can run a 1-Click session from the Asset Summary tab or from the Remote Control menu.

• Asset Summary tab - Click the agent's  icon and select 1-Click Session:

• Remote Control menu - Click 1-Click Session:

To run a 1-Click session from the Quick View window

To run a 1-Click session from the Quick View window, click 1-Click Access:

Reporting for 1-Click

1-Click session activity is included in these reports:

• Agents > Agent Logs - 1-Click activity displays under Technical Logs on the Remote Control tab:

• Info Center > Reporting > Reports > Logs - Remote Control - The Remote Control report definition generates a report of remote control sessions, by machine ID.

Handling 1-Click connection failures

If 1-Click cannot connect to an agent, this message displays:

Connection couldn't be established. Please verify that Windows Remote Desktop is enabled on the remote machine. Do you want to connect to a console session instead?

Do one of the following:

• Click Yes to initiate a console session.
• Click No. This message displays: Connection couldn't be established.... Click Okay to close the message and return to Quick View or Live Connect.

Account Security Notifications

There is a new User Interface for account security notifications. The new menu item is only visible to master- and system-level users running version 9.5.0.21 or higher.(VSA-5490)

When sending out email notifications, there is now an option to deliver the message to ‘all admins’ or define specific email addresses. When specifying addresses, a user can add up to 5 email addresses (comma or semi-colon separated) with a maximum limit of 1000 characters in total.

The notification features in the new UI include:

• Notify when an admin is created-as or promoted-to Master/System
• Notify when an admin is Enabled/Disabled
• Notify when an admin is Modified
• Notify when an admin is Locked-Out

The number of lockouts is set by the administrator on the System > Server Management > Logon Policy page.

Enhancements

BMS Integration

• Fixed an issue where VSA could return incorrect machine groups when sending asset data to BMS. (VSA-165)

REST API

• Enhanced API performance by decreasing calls to the Windows Security Store. (VSA-6417)

Security Audit

• Added the option to configure a security alert that is sent to Admin when a VSA user account has been locked because of too many consecutive failed logon attempts. This alert must be configured (it is not enabled by default). (VSA-5426)

Software Management Module

• To perform an action in Software Management, such as a scan or deploy, an agent would generate a call to the VSA, which would then go to the Windows Security Store to get the X509 certificate. With this enhancement, the X509 certificate is cached after the first agent checks in and requests the certificate so that a Windows Security Store call does not occur every time one of these Software Management activities is performed. (VSA-6417)
• Enhanced download performance by:
  • Adding more peer options for optimal load distribution. When downloading files, an endpoint will now have a list of peers to download blocks of files and, if there is more than one peer available, a random peer will be chosen. If there are no blocks available from peers, the endpoint gets the block from the VSA. Note that users may still see a spike in bandwidth network traffic during the initial download of files to the VSA. (VSA-3702) (VSA-4035)
  • Staggering scan and patch downloads to ensure that agent requests do not hit the VSA all at the same time. (VSA-6355)
  • Decreasing the number of status responses sent to and from the endpoint and the VSA. (VSA-6356)
  • Adding sleep functionality to the agents to allow more processing time before sending results back to the VSA. (VSA-6357)
• The software catalogs on the Software Management Dashboard (Content Quarterly and Full Installer) have been updated with the latest supported software titles. (VSA-6128)

VSA UI

• The VSA Login page has been updated for integration of Kaseya's IT Complete suite of IT solutions: (VSA-5298)

• The VSA Navigation Panel and Site Header have been updated with a clean new look: (VSA-4519)

Bug Fixes

Agent - Windows

• Fixed an issue where certain Windows operating systems were being reported incorrectly and a '<' prefix would display in the Operating System column in the VSA UI. This fix requires an agent update. (VSA-5537)
• Fixed an issue where silent installs could fail due to the first command line parameter being ignored on some Windows systems. (VSA-4895)

Anti-Malware Module

• Corrected a misspelling in the By Organization Anti-Malware Audit report template. (VSA-874)

Antivirus Module

• Made improvements to the way old endpoint packages are removed so that the latest package is the only one that is used. This ensures that duplicate packages are removed consistently and that the updated code is running on the endpoints. (VSA-5296)

Audit Module & REST API

• Added a database index to fix a performance issue that could cause errors to display on the Server Management > System Log page. (VSA-3770)

Cloud Backup Module

• Fixed a Mac backup client install issue that prevented VSA from detecting the installed client. (VSA-5661)
• Fixed an issue where the Mac backup client could not be installed due to changes introduced in Acronis 7.7. With the upgrade to Acronis Cloud Backup version 7.7, changes were made to how the Acronis Backup Client performs its automatic registration to Acronis. The Acronis Backup Client installation script has been updated to handle this change. Acronis has documented this issue in this article: https://kb.acronis.com/content/55244#OS_X6. (VSA-4003)
• Fixed an issue with Files/Folders type Cloud Backup profiles where backups would fail if the profile did not contain at least one rule for the Include filter and at least one rule for the Exclude filter: (VSA-4036)
  • If no rules were specified for either filter, the include/exclude filters status was saved in an invalid format which was sent to Acronis. Once this invalid format was reached during the start of a backup, the backup would fail and this error displayed on the Acronis data center website: Backup failed. Invalid Usage.
  • If only one filter had no rules specified, the backup would fail once it was run on assigned machines.

The fix and customer impact:

The invalid include/exclude save format was corrected so that our third-party vendor, Acronis, can parse the backup request.

For customers who have already created a backup profile that does not contain at least one include filter and one exclude filter, the following is recommended:

• Delete the backup profile and recreate it with the same backup name and profile configuration settings.
• Once created, the backup profile can be assigned to the machines which had the original (failing) backup plan. Subsequent backups should work as expected.

• Addressed an issue that prevented users from creating new Backup Groups if either the AU- or EU-based Acronis data centers were selected as the backup group storage location. The issue did not affect US data centers. (VSA-5973)

Acronis released Cyber Cloud version 7.9 to their AU and EU data centers. This new release introduced several security improvements, including enhancements to their public facing APIs that required changes in the way VSA retrieves an 'activation access token' from Acronis via an API.

The fix and customer impact:

The incorrect API that was retrieving the 'password reset access token' was removed and replaced with the correct 'user activation access token' API. This change works with both 7.8 (US) and 7.9 (AU and EU) Cyber Cloud data centers.

• If Cloud Backup users never encountered issues creating Backup Groups then there is no customer impact and no action is required.
• If users previously attempted to create a Backup Group and were prompted with the error message shown below, the group they created is in a bad state and will need to be deleted and then recreated in the Cloud Backup/Configuration/Backup Groups page.

Error message: Exception has been thrown by the target of an invocation. Failed to activate User "XXXXXXXX" in "1234567890'

Database & Schema

• Database cleanup routines have been optimized for increased efficiency. (VSA-5499) (VSA-6656)

KServer

• Fixed an issue that resulted in unneeded agent procedure calls. (VSA-6486)

Remote Control Module

• Corrected the message text that displays if a user attempts to modify options on the User Role Policy page without first selecting a role type. The message has been changed from No machines selected to No role types selected. (VSA-5593)
• Fixed the following issues on these Remote Control > Notification Policy pages: (VSA-5623)
  • Machine Policy – The following error displayed upon accessing this page: Oops. Something went wrong.
  • User Role Policy – The following error displayed after selecting a role, clicking 1-Click Access, then clicking Apply: Oops. Something went wrong.
• Fixed a session token issue that occurred upon clicking the agent status icon. With this issue: (VSA-6102)
  • The following error displayed: Errors occurred while creating the session token!
  • Live Connect and Remote Control did not launch.
  • Software Management pages could no longer load correctly.

REST API

• Fixed an issue that impacted performance on SaaS servers running VSA 9.5.0.21. This caused intermittent errors in many areas of the VSA. Examples: the new UI could revert to the classic UI, error popups could display on pages, VSA modules could fail to load, and VSA could fail to launch Live Connect and Kaseya Remote Control. (VSA-6106)
• Improved handling of expired sessions: (VSA-6354)
  • Validation checks around expired tokens now return a Null value so that VSA APIs no longer return 500 internal server errors for calls to bad or expired tokens.
  • Token expiration criteria has been changed to fix an issue where additional user sessions could expire when a user logged out of the VSA UI.
• Fixed a performance issue with Software Management downloads that caused the API to become saturated with tracker requests. The fix includes changes to: (VSA-6327)
  • The updateInterval sleep time that must elapse before another tracker request is sent.
  • The peer used for the download. Downloads now only use peers within the same default gateway.
• Fixed an issue with tenant validation in the custom field API. (VSA-5656)

Security Vulnerability

• This fix ensures that security notifications are no longer sent when changes are made to Kaseya Support accounts, even if it appears that the changes were conducted with direct SQL calls. (VSA-6101)

Service Desk Module

• Fixed an issue where links to attachments in Service Desk ticket notes did not persist after adding a subsequent note through email. Links were no longer present in the email reply. (VSA-3174)

System Module

• Fixed an issue where clicking Check Latest Patch Level on Configure > Server Management > Configure resulted in a SQL error. (VSA-3293)

Security Vulnerability & Software Management Module

• Enhanced security to ensure that private deployment profiles in Software Management do not display to unauthorized users. (VSA-4812)

Software Management Module

• Fixed an issue where approved patches were being installed during the blackout window. (VSA-3723)
• Fixed an issue with deployment profiles that resulted in the deployments running as soon as the profile had been applied to a machine group, rather than running according to the schedule set in the profile. (VSA-5101)

VSA Core

• Corrected an issue in which third-party applications could not be uninstalled or upgraded after patching. (VSA-4554)

VSA UI

• Fixed a compatibility issue with Internet Explorer that caused blank pages to display in the VSA UI. (VSA-6105)
• Fixed a resource issue that prevented administrators from using the system when it was under heavy load. With this fix, a dedicated IIS application pool has been added for navigation-related API calls so that IIS resources are no longer exhausted by excessive API calls. (VSA-6506)