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.

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.

For more details on what profiles are available for configuration, view the list of Profile types below.

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.

Device Configuration profiles define how users can interact with and view devices.

These profiles can only be applied to Device Configuration policies.

The following Device Configuration profiles are available: 

Monitoring profiles allow you to configure which events and metrics you'd like to raise alerts on when they occur on monitored devices.

These profiles can only be applied to Monitoring policies.

The following Monitoring profiles are 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.

As the name implies, targeting criteria expose various attributes that can be selected within each policy and its extensions so you can explicitly and implicitly control where a policy should be applied. This means you can set up your policies once and know they will automatically be applied to any device that matches the targeting criteria, including existing devices and newly provisioned devices.

As follows are examples of targeting criteria:

  • Context: Refers to the organizational structure of devices.
  • Device Type: Refers to the primary type of device.
  • OS Type: Refers to the operating system of a device and includes major versions.
  • Manufacturer: Refers to the manufacturer of a device.

An extension allows you to adjust a policy’s settings for a subset of the policy’s targeted devices, making it easier to apply policy changes to specific devices without having to rebuild your policy structure. Additionally, child extensions can be created within existing extensions in certain situations, allowing you to account for complex situations.

There are three targeting modes that can be used when configuring a policy extension: 

  • 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: This mode assigns the extension directly to the selected context.
    • This mode supports direct child extensions using any targeting mode.
  • Device Targeting: This mode requires manual selection of the devices the extension will target.
    • This mode does not support child extensions.

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:

  1. Create an initial policy and assign the relevant profiles for the broader set of devices.
  2. 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. Refer to Configuring policy extensions.

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.

In order to configure a policy extension: 

  1. Navigate to Administration > Configuration > Policies, hover over the policy you wish to create an extension for, and click the Create Extension button.

  2. Configure the Name of the policy extension, and optionally provide a Description of what this policy extension was created to achieve. Type will be automatically configured based on the policy type the extension is for.

  3. Choose the extension's Targeting Mode and click Next to define the target. 

    NOTE  Configuration for each targeting mode differs. Please expand the applicable section below on the targeting mode that you wish to configure for further guidance: 

    Select Dynamic Targeting if you need to target devices based on device type, OS type, and/or manufacturer. This is useful for scenarios where a policy needs to be configured differently for devices based on the makeup of the device, and it needs to automatically apply when a device meets the extension target parameters. You can use any combination of device type, OS type, and/or manufacturer when configuring a Dynamic Targeting extension.

    For example: 

    • Different policy profiles for Windows devices than macOS or Linux devices.
    • Different policy profiles applied based on their OS version (for example, Windows Server 2025 versus Windows Server 2008, etc).
    • Different policy profiles for devices from different manufacturers (for example, HP versus IBM, etc).

    To configure: 

    1. From the Targeting menu, select which target criteria you want to configure:

      • If you want to target all device types that exist in the original policy context, leave Inherit From Parent selected.

      • If you want to target only specific device types for this policy extension, click Select Device Types and then click Edit Device Type.
      • In the pop-up that appears, check the box next to each device type you want this extension to apply to, then click Save to apply your changes.

      • If you want to target devices of all OS types that exist in the original policy context, leave Inherit From Parent selected.

      • If you want to target only specific OS types for this policy extension, click Select OS Type and then click Edit OS Type.

      • In the pop-up that appears, check the box next to each OS type you want this extension to apply to, then click Save to apply your changes.

      • If you want to target devices from all manufacturers that exist in the original policy context, leave Inherit From Parent selected.

      • If you want to target only devices from specific manufacturers for this policy extension, click Select Manufacturers and then Edit Manufacturers.

      • In the pop-up that appears, check the box next to each manufacturer you want this extension to apply to, then click Save to apply your changes.

    2. Once you've configured your Dynamic Targeting settings, continue to the next step.

    Select Organizational Targeting if you need to target devices based on the sites or groups they reside in within the original context of the policy. This is useful for cases where policies need to be configured differently based on where a device resides.

    NOTE  Organizational Targeting mode extensions are not supported for global policies (a policy that is applied to All Organizations). You can refine the context of a global policy by editing that policy directly.

    For example: 

    • Limiting or removing remote control options for devices at a sensitive location.
    • Modifying monitoring profile settings for devices depending on which organization or group they are a part of.

    To configure: 

    1. From the Context menu, click Select Context in the upper right corner.
    2. In the pop-up that appears, select which sites and/or groups you want to assign the extension to. Child items will automatically inherit assignment from their parents. When done, click Save to apply your changes.
    3. The Context menu will now show the updated extension targeting.

    Once you've configured your Organizational Targeting settings, continue to the next step.

    Select Device Targeting if you need to manually select devices within a site or group to receive different policy profile settings than the other devices in the same container.

    For example: 

    • Disable or modify Remote Control and File Browser profile settings for a handful of sensitive devices at a location, such as the CEO's device.
    • Add monitoring for a specific service or event log to a specialized server
    • Test a modified profile on a single device before widely applying the policy changes.

    To configure: 

    1. From the Context menu, click Select Context in the upper right corner.

    2. In the pop-up that appears, select the device(s) that you want the extension to apply to. When done, click Save to apply your changes.

    3. The Context menu will now show the updated extension targeting.

    Once you've configured your Device Targeting settings, continue to the next step.

  4. With your targeting mode configured, click Next.

  5. Click Assign Profile.
  6. In the pop-up that appears, check the box next to each profile that you want this policy extension to apply to the targeted devices. You can search keywords and/or filter by profile type at the top of the window. When done, click Assign to save your selections.
  7. When your selected profile(s) have been added, you can click a profile to view it's settings, edit a profile, or delete it from the extension.
  8. Once finished, click Create and confirm your choice in the pop-up message to save and immediately apply your policy extension to the applicable devices.
  9. Once created, the extension will be nested below the policy on the Policies page when expanded.

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.

Various profiles with common configurations are available in VSA 10. These can be found by navigating to Administration > Configuration > Profiles and are grouped by folders or content tags.

EXAMPLE  The built-in Device Configuration and Monitoring profiles are grouped as Basic Device Profiles.

You can export profiles to a .pcmpr file by hovering over the profile and selecting the export icon: 

NOTE  The exported file is proprietary and is not intended to be modified before import.

Using the Import Profile button, you can import profiles that were previously exported from VSA 10 in the form of .pcmpr files.

The built-in policies are named similarly to the profile grouping name.

EXAMPLE  The Device Configuration and Monitoring policies are named Basic Device Configuration Policy and Basic Device Monitoring Policy, respectively.

The built-in policies include several of the built-in profiles, and each policy contains two extensions: one for Windows servers and one for Windows workstations.

For new customers, each root policy is already configured to target All Organizations, which means that it is active and will automatically apply to any devices with an Agent you onboard.

NOTE  If you were an existing customer when the package was introduced with VSA 10 version 10.6, the root policies are not configured with a context target, which means the policies will not be automatically assigned to any devices. To use the policies, simply assign the root policy to any context (that is, organization, site, group).

You can export profiles to a .pcmpol file by hovering over the profile and selecting the export icon: 

NOTE  The exported file is proprietary and is not intended to be modified before import.

Using the Import Policy button, you can import profiles that were previously exported from VSA 10 in the form of .pcmpol files.