Policies overview

At the core of VSA 10 is a reimagined policy management engine designed to provide technicians with an effective balance of predictability and flexibility. The simple yet powerful way policies work helps arm VSA 10 customers with the tools necessary to build and maintain absolute compliance of their configuration settings.

VSA 10 is in the process of rolling out a less monolithic policy structure and adding quality-of-life improvements to the overall policy management design. As of version 10.6, Device Configuration policies and Monitoring policies will be converted to the new policy structure, and the remaining policy types will be converted in subsequent releases.

What are policies?

Policies are the method in which collections of one or more VSA 10 settings are applied to a specific set of objects, such as devices. VSA 10 is responsible for ensuring a policy's targeted devices receive and remain compliant with the policy’s settings. Policies are distinguished by the type of service each is responsible for. Refer to Policy types.

Policies apply the correct settings to the correct devices. As of version 10.6, policies are non-cumulative, which means only one policy of a given type can be assigned to a given entity.

EXAMPLE Only one Device Configuration policy can be assigned to a specific organization. You could create additional Device Configuration policies, but only one at a time can be assigned to that organization.

Policies support a downward inheritance model in several places, including context.

EXAMPLE When you assign a policy to an organization, the sites and groups of that organization will automatically inherit the organization’s policy since sites and groups are child objects of an organization. However, you can break the inheritance by directly assigning a different policy at each site and/or group level.

Policy types

The following types of policies are available to configure in VSA 10:

Device Configuration
Monitoring
Endpoint Protection (Ransomware Detection and Webroot)
Patch Management

Components of a policy

A policy is the vehicle for delivering and managing settings on devices. Policies have three key components:

Profiles: Containers of settings that serve as the building blocks of policies. Profiles control which settings a policy will deliver. For details, refer to Profiles.
Targeting criteria: Attributes used for automatic assignment of policies. Targeting criteria control which devices will receive the policy. For details, refer to Targeting criteria.
Extensions: Used to change policy settings based on device exceptions. Extensions provide a way to make changes to a policy for a specific subset of devices without requiring creation of an entirely new and separate policy. For details, refer to Extensions.

Profiles

The concept of profiles simplifies the configuration and management of policy settings.

A profile is a small, distinct container of VSA 10 settings grouped by a specific category type (for example, Event Log profiles are a type of Monitoring profile).

Profiles allow for specific combinations of settings to be configured once and reused in more than one policy. This concept also allows the profile to act as a template so that any future changes to it are automatically reflected everywhere the profile is used.

Profiles are designated as either cumulative or non-cumulative, which means that a profile of a given type can either be applied multiple times to a device or applied only once.

Profile Types

There are several types of profile that are split into two categories, Device Configuration and Monitoring.

Review the sections below for more information on the different profiles available.

Cumulative profiles versus non-cumulative profiles

Cumulative profiles are specific types of profiles that can be applied to a device more than once because their settings are considered safe for layering, which means their settings do not exactly conflict if applied more than once. Examples of cumulative profile types can be found in Monitoring profiles. For instance, you might want to have a base set of event logs that apply to all of your Windows devices, so you would create a specific Monitoring: Event Log profile with those settings. Additionally, you may have a more advanced set of event logs that you apply to a subset of Windows devices, so you would create a second Monitoring: Event Log profile with the advanced settings. By leveraging the capabilities within policies, both Event Log profiles can be applied to the devices that require the base and advanced set of event log settings, and the settings will be aggregated. This eliminates the need to duplicate the common event log settings of the first profile into the advanced profile.
Non-cumulative profiles are specific types of profiles that can be applied to a device only once because their settings are considered problematic for layering, which means their settings directly conflict if applied more than once. Examples of non-cumulative profile types can be found in Device Configuration profiles. For instance, you might want to enable Remote Desktop session confirmation for all your devices, so you would create a specific Device Configuration: Remote Desktop profile with that setting. Additionally, you may want to disable Remote Desktop session confirmation for a subset of devices, so you would create a second Device Configuration: Remote Desktop profile with that setting. However, each device can receive only one of these profiles, not both. In this case, when working within policies, intelligence is built in to prevent you from applying a second type of non-cumulative profile to the same targets that already have one assigned, and VSA 10 will present options to correct the conflict.

The following diagram shows how a profile works using Monitoring policies as an example.

EXAMPLE Two separate Monitoring policies require the same set of event log settings, which means you can create a single Event Log profile with the required settings and assign the profile to both policies. An additional benefit of this structure is change management. If the event log settings need to be changed, they only need to be changed within the single profile, not within each policy.

Extensions

An extension allows you to adjust a policy’s settings for a subset of the policy’s targeted devices.

Use case

You have a specific combination of settings that apply to a set of devices, but for a subset of those devices, a slight adjustment of the settings is required.

In typical policy implementations, you may be required to do either of the following:

Create a second policy with the specific settings for the subset of devices and all the same settings as the first policy that are also required for those devices. The result is two policies with potential overlap in the settings. If a change is needed among those shared settings, both policies would need to be updated individually.
Create an override for each of the devices, which is typically done directly within each device. The result is a decentralized manual deviation from your centralized configuration, often with no association or visibility outside each device level.

Both of the preceding examples create unnecessary complexity, incomplete visibility, and a lack of control. Also, you typically need to perform manual work when reconciling for compliance.

The concept of extensions solves these problems and more by creating what is effectively a child policy that remains associated with its parent. The extension automatically inherits the settings and targeting criteria from its parent; however, you can adjust the targeting criteria to refine your device selections and you can add, change, and remove profiles while leaving any relevant profiles from the parent intact.

Referring to the original use case referenced, you would solve this by performing the following steps in VSA 10:

Create an initial policy and assign the relevant profiles for the broader set of devices.
Create an extension to the policy, configuring the relevant profile changes (add, change, remove) and refining the targeting to apply only to the smaller subset of devices.

The result will be that the subset of devices targeted by the extension receives the profiles within the extension, while the remainder of the devices targeted by the parent policy will receive the profiles within that policy.

VSA 10 policies support multiple extensions at the same level and the ability to extend an extension.

EXAMPLE You may want to create an extension that changes some parent settings for Linux devices and, at that same level, create a different extension that changes some parent settings for macOS devices. Further, you may want to create an extension of the macOS extension to refine some settings for macOS 12 devices.

The following diagram shows how the policy extension concept works.

EXAMPLE You can think of each extension as a higher priority policy, as each extension refines its targets with more granularity than the extension’s parent. For example, the Windows 11 devices will receive only Extension 1.1 because they are more specifically targeted versus the criteria used within Policy 1 and Extension 1. However, if you were to delete Extension 1.1, all Windows 11 devices would automatically adopt the settings of Extension 1 since that extension is targeting all Windows devices.

The policy extension model helps you to build your policies more broadly at the root levels, covering more devices with common settings while allowing you to use extensions to granularly refine the targeting criteria and setting adjustments to deal with exceptions, special situations, and advanced service levels.

Effective settings

Even the best policy management implementation can fail if the solution does not provide comprehensive visibility of the impact it will have, does have, or is going to have across your environment. VSA 10 provides visibility of impact on the front end while you are building and configuring your policies as well as on the back end once policies are set.

While you are configuring policies, the editor will show you what VSA 10 objects will receive that policy before you save it. Once the policies have been configured, effective settings provide visibility of the policies, their profiles, and the settings that have been assigned and applied at all levels of your VSA 10 environment. This includes organizations, sites, groups, and devices. For example, when you are working on a device and need to quickly see what settings might be impacting a certain service area, effective settings will help you understand this information while allowing you to maintain the context of your operational workflow.

Basic profiles and policies package

To provide you with a jump-start and to help you understand the policy concepts explained in this topic, VSA 10 includes a basic set of profiles and policies preconfigured with a few extensions.

	Need troubleshooting help? Open the Kaseya Helpdesk.
	Want to talk about it? Head on over to the Community!
	Have an idea for a new feature? Want to learn about upcoming enhancements? Visit the Ideas forum!
	Provide feedback for the Documentation team.