VSA 10: Version 10.18 release notes

NOTE  During release deployment, all active web application sessions will be disconnected, and customers will need to log in again at the beginning of the maintenance window. SaaS customers will be informed of their maintenance window via status.kaseya.com.

Schedule*

Region Date Starting Time (EST)
APAC May 13, 2025 14:00
EMEA May 15, 2025 15:00
US May 20, 2025 20:00
On-Premises May 27, 2025 12:00

NOTE  *The schedule is subject to change. Please check the Status page for regular updates. When changes are made to the original schedule, those changes are denoted in red.

In this release, agents will be updated to version 10.18. Some features will only be available once the agent has been updated. For each tenant, agents are programmed to automatically, randomly update within a 36 hour window following the release deployment. A device's agent version can be viewed and can be manually updated by navigating to Device Details > Software > Agent Version.

The agent version for this release is 10.18.

Key feature enhancements

Introducing the Automation Workflow Cooper Copilot in early access

We are thrilled to announce a groundbreaking new feature of VSA 10: the Automation Workflow Cooper Copilot, now available for early access starting May 26, 2025. This innovative feature is part of our ongoing commitment to AI advancements and is designed to transform how you create workflows. With Cooper Copilot, you can generate workflows simply by typing your desired automation outcome, eliminating the need to start from a blank canvas or the need to have explicit scripting skills.

For example, you can input the prompt “I want to be able to view DWG files on Windows Computers” and Cooper Copilot will produce a workflow suggested deploying a DWG viewer from Autodesk.

Cooper Copilot will enhance your automation capabilities, streamline the creation of Workflows, and significantly boost efficiency across your automation tasks.

During this early access phase, we are dedicated to training and refining our Cooper AI model based on your invaluable feedback. To participate in our early access program, please fill out this form. We are excited to help you unlock the full potential of Cooper Copilot-powered Automation Workflows.

Here's a video showing Automation Workflow Cooper Copilot in action:

Policy Extensions: Organizational Targeting

In this release, we are pleased to announce the addition of Organizational Targeting for Policy Extensions, eliminating the need to copy or replicate root-level policies when a minimal change is needed for down-stream sites and groups.

What are policy extensions? 

Policy extensions allow you to adjust a policy’s settings for a subset of the policy’s targeted devices.

The policy extension model helps you to build your policies more broadly in the root levels, covering more devices with common settings. Then, using extensions, you can further refine the policy’s targeting criteria and setting adjustments to deal with exceptions, special situations, and advanced service levels.

The VSA 10.18 release enhances the extension model by introducing new functionality and changing existing behavior to further simplify the policy management experience by allowing the context to be refined within extensions.

Prior to VSA 10.18, there were two modes for targeting devices using an extension:

  • Dynamic Targeting: This mode automatically and dynamically targets devices by using attributes such as device type, operating system version, and manufacturer.
  • Explicit Targeting: This mode requires manual selection of the devices the extension will target.

For each organization, site, and/or group which required unique settings, a separate root-level policy was required.

The VSA 10.18 release enhances the extension model by introducing new functionality and changing existing behavior to further simplify the policy management experience by allowing the context to be refined within extensions.

Targeting Modes

Policy Extensions now support three distinct modes for targeting devices:

  • Dynamic Targeting: This mode automatically and dynamically targets devices by using attributes such as device type, operating system version, and manufacturer.
    • This mode supports direct child extensions using dynamic and device targeting only. Child extensions using organizational targeting are not supported.
  • Organizational Targeting (NEW): This mode assigns the extension directly to the selected context.
    • This mode supports direct child extensions using any targeting mode.
  • Device Targeting: Formerly known as Explicit Targeting, this mode requires manual selection of the devices the extension will target.
    • This mode does not support child extensions.

Policy & Extension Hierarchy

Beginning with VSA 10.18, policies and extensions follow a hierarchical model based on the policy’s organizational context selection.

For example, if your goal is to have a unique root-level policy assigned directly to Organization 1, and you also need to modify this policy’s settings for Organization 1>Site 1, instead of creating a new root-level policy specifically for Site 1, you must create an extension under the Organization 1 policy for Organization 1>Site 1. The Site 1 extension will apply directly to Site 1 and will be nested underneath the Organization 1 policy:

Migration of Existing Policies

The VSA 10.18 release will apply the following behavior to existing policies:

For any site and group root-level policy where there is also an existing root-level policy assigned directly to any parent context of that object, the existing policies will be automatically nested underneath their parent policy as extensions. The nesting process will follow the natural hierarchical model of the context. Let’s look at a few examples:

Example 1:

  • Policy1 is a root-level Policy assigned to Site1.
  • Policy2 is a root-level Policy assigned to Site1>Group1.
  • Because Site1 is the direct parent of Group1, after migration, Policy2 will automatically become an extension of Policy1, like this:
    • Policy1 (Site1)
      • “New” Extension (Group1) (Policy2)

Example 2:

  • Policy3 is a root-level Policy assigned to Organization3.
  • Policy4 is a root-level Policy assigned to Organization3>Site3.
  • Because Organization3 is the direct parent of Site3, after migration, Policy4 will automatically become an Extension of Policy3, like this:
    • Policy3 (Organization3)
      • “New” Extension (Site3) (Policy4)

Example 3:

  • Policy5 is a root-level Policy assigned to Organization5
  • Policy6 is a root-level Policy assigned to Organization5>Site5>Group5
  • Because Organization5 is a parent of Group5 and because there is no existing root-level Policy for Group5’s direct parent, after migration, Policy6 will automatically become an Extension of Policy5, like this:
    • Policy5 (Organization5)
      • “New” Extension (Group5) (Policy6)

For any site and group root-level policy where there is not an existing root-level policy assigned to any parent context of that object, the policy will remain as a root-level policy until and unless a new root-level policy is created for the object’s parent context. Once a new root-level policy is created for the object’s parent context, the existing policy will be automatically nested as an extension of the new, parent’s root-level policy.

NOTE  As part of the merging process, you can also choose to retain a copy of the original root-level policies, however, the separate retained policies will have their context removed to prevent conflicts.

To better explain the migration process, please review the migration examples below: 

Before VSA 10.18: In the example below, notice the various root-level policies, represented by the letters A through E, assigned to various parts of the organizational structure:

Beginning with VSA 10.18: In the example below, notice how certain root-level policies are merged into a hierarchy that follows the organizational structure:

  • Policy A is considered a global policy because it is assigned to All Organizations. Being a global policy, it will now always appear at the top of the Policies list.
    • This policy will be automatically inherited by all organizations which do not have a separate policy directly assigned.
    • In a subsequent release, this type of policy will be more formally designated as a Global Policy.
  • Policy C was automatically nested as a first-level extension of Policy B because B is a root-level policy assigned directly to the parent organization of C.
  • Although Policies D and E are part of the same organization, they remain as separate root-level policies because there is no existing root-level policy for any of their parent context.

    NOTE  If a root-level policy is subsequently created for any parent context of policies D and/or E, they will be automatically merged into that new root-level policy.

Automation Content Management

The hierarchical folder structure which was implemented for scripts and tasks in 10.16 has now been extended to workflows.

NOTE  In a future release, all Automation folders will be consolidated and managed from a single page.

  • Now, Automation > Workflows will have 3 top level default folders:
    • Built-in: Contains default content that is provided with the product (read-only).
    • Content Packages: Contains Kaseya created content delivered from packages or templates (read-only).
    • User Defined: Contains custom content created by product users.
    • Two levels of sub-folders can be created within the default User Defined folder.
    • The Built-in and Content Packages folders are read-only, but content can be copied to the User Defined folder if it requires customization.
    • Existing user defined workflows will be migrated directly into the User Defined top level folder.
  • The folder structure can now be managed from the Scripts, Tasks or Workflows management pages. Changes made from any of these pages will be reflected in all of them.
  • Folder management controls:
    • Create Folder
    • Edit Folder
    • Delete Folder
    • Clone
    • Copy To or Move To another parent folder.
  • Enhanced content grid with additional data columns and filters.

Move fields from Assets to System Fields for macOS and Linux agents

In this release, time zone, manufacturer, and OS type fields are moved from Assets to System Fields for macOS and Linux agents. If the device does not have the corresponding information in System Fields, this information will still be available in Assets. Additionally, policy assignment was optimized based on dynamic targeting filters, such as Manufacturers and OS Type, by moving these fields from Assets to System fields.

By moving the necessary information (manufacturer, OS type, and time zone) to system fields for these platforms, the data in these fields will be updated closer to real-time rather than the previous standard audit timing of 3-6 hours.

Custom installer for macOS and Linux Agents

In this release, configurable group-based, self-registering installers for macOS and Linux agents are now available, allowing for quicker and easier device registration after installing the VSA 10 agent on those device platforms.

MDM: Display property names in MDM profiles

In this release, both title and property name will be displayed for all Apple MDM profile components. Previously, the title property from the Apple GitHub repository was used, however, Apple documentation uses property names/keys, making it difficult to create profiles based on that documentation.

Patch Management

  • The Patch Management module behavior has been updated to include the following changes:
    • Patch Management policies where Windows automatic updates configuration is not set to Turn off automatic updates will no longer be visible on the Patch Management > Patch Status page.
    • Patch Management global OS rules will only apply to devices targeted by Patch Management policies where the Windows automatic updates configuration is set to Turn off automatic updates.
    • Turn off automatic updates is now the default option for Windows automatic updates configuration for new Patch Management policies.
    • OS patching is only executed on devices targeted by Patch Management policies where the Windows automatic updates configuration is set to Turn off automatic updates.
    • The Patch Policy Compliance widget has been updated to indicate that a device is end-user managed if it is targeted by a Patch Management policy where Windows automatic updates configuration is not set to Turn off automatic updates.
    • The Failed patch status will now only take into account failures for patches initiated from VSA 10.

KaseyaOne Unified Login

  • When configuring Access Group mappings, you can now select a default team, and any secondary teams you want to apply to users in that KaseyaOne Access Group.
  • The name of the default KaseyaOne Access Group will now display when configuring the mapping.

Device Management

  • The left navigation menu can now be collapsed or expanded using UI controls or the keyboard shortcut Ctrl+[.
  • The Device Management page has been updated to improve readability.

Team Permissions - Organizations

For this release, the following permissions have been added to the Teams > Permissions tab:

  • Administration
    • View Organization Properties
      • Allows read-only access to organizations, sites, and agent groups and their configuration settings. Organizations, sites or agent group visibility can be restricted in the Access tab.
    • Edit Organization Properties
      • Allows editing of the existing organizations, sites, and agent groups for which the user has Full Access permissions.
    • Create / Delete Organizations
      • Allows creation and deletion of organizations, sites, and agent groups.
      • For any new entity created, the entity will automatically be configured with Full Access permissions within the user’s current operating Team.

Policy Management: Includes extensions when copying, importing and exporting policies.

Previously, when cloning or exporting policies, extensions were not included in the output, which caused more manual work on the tail end to recreate the full policy structure. This update plans to remedy this with the following changes:

  • When cloning, exporting, or importing a root-level policy, there is now an Include Extensions option, which is enabled by default.
  • As part of the cloning and exporting process, any context selection in the root or in any extensions will be cleared. This includes explicit device selections.
  • When importing an exported policy, any profiles associated with that policy will be created if they do not already exist.
  • Tags can now be assigned to a policy during the import process.
  • Extension names can now be reused in other root-level policies.

Integrations

ESET Direct Endpoint Management integration

With this release, we are pleased to announce our new integration with ESET Direct Endpoint Management.

This new integration establishes direct communication between ESET security products on your managed devices and VSA 10.

The new ESET Direct Endpoint Management plugin enables MSPs to monitor installation, activation, protection, scan and threat status and perform on-demand or automated actions on managed devices using workflows or tasks.

After configuration, the integration scripts, policies, profiles and workflows are available in VSA 10 to be adjusted based on your needs.

Main features of ESET Direct Endpoint Management plugin for Kaseya VSA X: 

  • Fast onboarding of ESET security products on your managed devices through VSA 10.
  • Automated monitoring of ESET security product installation, activation, protection, scan and threat status.
  • Automated or on-demand action to remedy issues reported by ESET security products on your managed devices.

For more information on this integration, refer to ESET Direct Endpoint Management plugin for VSA X.

Acronis Cyber Protect Cloud

Built from the ground up, the integration between Acronis Cyber Protect Cloud and VSA 10 supports:

  • Customer provisioning in Acronis based on organizations in VSA 10.
  • Deployment of the Acronis agent through VSA 10.
  • Default protection plan application for mapped customers.
  • Acronis agent status monitoring in VSA 10.
  • Automate Acronis tasks as part of the automated Workflows of Kaseya VSA 10.

Further information on this integration is available in the VSA 10 Integration Configuration Guide.

Fixes

Automation

  • Fixed an issue where workflows queued in the Pending Workflow queue did not automatically execute when the target machine came back online, resulting in stalled automation and missing workflow history entries.
  • Fixed an issue where complex workflows could fail with The reader's MaxDepth of 100 has been exceeded error, ensuring all workflow executions complete successfully regardless of nesting depth.
  • Fixed an issue where removing and re-adding the Last Execution Date and Next Execution Date columns in the Workflow tab now properly retains and displays execution timing data.
  • Fixed search functionality in Workflow History to properly display results when filtering by System/Device Name, allowing administrators to easily track workflow executions for specific devices.

Autotask Integration

  • Fixed an issue with the Autotask integration where VSA Device name and location data were not displayed properly on the associated device record within Autotask. This VSA 10 release addresses the Device name issue. For the location data, the Autotask team is expected to provide the fix within their 2025.3 release.

Apple MDM

  • Fixed an issue where MDM-enrolled devices appeared as Unsupervised despite being marked as Supervised in Apple Business Manager.

Client Portal

  • Fixed an issue where newly created conversations were not visible on the Conversations page.
  • Fixed an issue with the Client Portal Troubleshooter when the End Troubleshooter function was on the same level as Ask Question, it was not possible to add a new answer choice to the question.

Dashboards

  • Fixed an issue where icons were not displaying when adding a widget to a dashboard.

Device Management

  • Fixed an issue in Site Maps where devices were incorrectly showing as offline.
  • Fixed an error that could occur when trying to access the Endpoint Protection > Security page in the Device Card.

KaseyaOne Integration

  • Fixed an issue where users would receive a message stating To enable PSA, please contact sales@kaseya.com when attempting to enable the integration with KaseyaOne.
  • Fixed an issue which prevented more than one active session of VSA when logging in through KaseyaOne.

Mobile application

  • Fixed an issue where notifications were not displayed in the correct order of date and time when using the mobile application on iOS devices.

Organizations

  • Fixed an issue where incorrect messaging was displaying regarding the availability of Organization level policy types.

Remote Control

  • Fixed an issue where the VSA X Manager would not display properly at resolutions less than 1280x720 (720p).
  • Fixed an issue where an error would be displayed for a device shortly after selecting the Remote Control option when using the mobile application.
  • Fixed an issue where Remote Control was not working for Android tablets.

Reporting

  • Fixed an issue with the Advanced reporting > Audit > Remote control sessions report where RC device values weren't displayed, RC Description was empty, and number of records wasn't displayed.
  • The Rmm - Tags data set in Advanced Reporting was fixed and shows only tags assigned to a device.
  • Filters (Organization / Site / Group / Device Name) in the Installed Patches (OS) report are fixed.
  • Fixed an issue in Advanced Reporting which prevented the filtering of individual custom fields when using the Include Custom Fields filter.
  • The Missing Patches (OS) report template now shows the correct value for patched devices.