The new Advanced Policy Framework offers a more flexible, hierarchical approach to managing policies, with a focus on automation and efficiency. This guide will help you understand the differences between the group-based policy and the new advanced policy, along with some recommendations on how to organize your assets effectively so that you make the most of this powerful framework.

Device Categories as Folders

Think of device categories as “folders” that let you organize assets, without the need for any conditions. Unlike with an asset group, you do not have to set conditions that an asset needs to meet in order for it to fall into a device category.

Flexible Policy Association

In the older group-based system, changes to client tiers or services required updating custom fields or groups, which could lead to errors if fields were missed, and was a tiresome task to do. Now, assets flow freely between device categories without any conditions, since they are essentially “folders” that automatically inherit the correct policies, based on the policy association.

Two-way Policy Inheritance

Policies are organized into a parent-child hierarchy where the root policies apply to all assets in a category. Child policies allow specific changes without reconfiguring the entire set and reducing time and effort required in setting up your use-case based policies. Policies set up at the root are automatically inherited downwards, with their status maintained. On the other hand, if a new policy is introduced at a child level, the same is inherited backwards as well, in the disabled state.

One Device, One Policy

With the advanced policy, every device is associated to only one policy, without any policy overlaps or clashes. Since every device falls under a unique device category, multiple policy sets will never apply for the same device. This single policy method gets rid of confusion, minimizes the need for overrides, improves visibility and makes asset management a lot more efficient.

Let’s look at a few sample setups to see how you can organize your asset groups into device categories in the advanced policy, based on a few use-cases.

Let’s look at an example of an MSP that caters to schools, and has over 20 managed clients in SuperOps. This MSP does not charge clients based on plans, but rather has custom contracts for each client. Because of this, some clients may need specific policies that are customized just for them, while 3-4 clients with similar contracts will follow the same policy.

The MSP manages Windows workstations for all their clients, since they cater to schools, they take care of both student and staff machines that are connected to the school’s network.

GROUP BASED POLICY SETUP

Here’s what the setup would look like:
​

Filter Conditions:

Client is {Client} + Client does not include {exceptions} + Platform Category is Windows + Device Type is {Staff/Server}

Policy Associations:

In the group-based policy, the MSP will need to create separate asset groups and policy sets for each school, and under each school, for staff and student separately. They will also need to keep in mind that any changes to policies that are common between staff and student policies of a school will have to be changed together, if there are any changes in the contract of that school.

This can lead to a lot of confusion and lead to errors if the updates are not done correctly. Besides, it is cumbersome to have to repeat the same configurations for every single school, even for ones that do not have any client-level customizations.

These drawbacks mean that the group-based policy is not the ideal framework for such a complex setup. Let’s now look at how the advanced policy framework simplifies things and helps the MSP set up an efficient, organized, and easy-to-manage policy demography.

ADVANCED POLICY SETUP

Here is where the advanced policy’s powerful capabilities come into the picture. The MSP can start by defining a root Workstation Policy that will include all their standard alerts, patches, software, and more. Under the root, the MSP can define two policy sets - Staff Policy, Student Policy. These two can include all the standard policies that a staff machine and a student machine will require. For example, staff policy could include software such as Zoom, Figma. Whereas, the student policy could include Google Drive, ChatGPT.

Now, for client-specific customizations, the MSP can simply define further child policy sets under the Staff and Student parent policy sets. For Dunder Mifflin, the MSP can define “Dunder Mifflin - Staff” and “Dunder Mifflin - Student”, and override the policies here. Similarly, the MSP can define as many child policy sets as required, based on the number of client-specific customizations they need.

Student Policy Hierarchy

Staff Policy Hierarchy

Schools that don’t need specific customizations will be governed by the parent policy sets directly (Staff Policy & Parent Policy).

Filter Conditions:

None, since device categories are condition-agnostic “folders”.

Policy Associations:

Here’s how the policy associations could work for three of their clients: Stark Industries, Dunder Mifflin, Acme Inc.

Client: Stark Industries

Client: Dunder Mifflin

Client: Acme Inc

Overall Policy Hierarchy

In this example, the policies are set up based on the contract plan that a client has purchased, the device manufacturer, and customizations on the antivirus policy. Let’s take a closer look below.

GROUP BASED POLICY SETUP

Filter Conditions:

Agreement level (client) + platform category + client custom field(s) + asset custom field(s)

Policy Associations:

In this scenario, you would have to create two separate asset groups with filter conditions to be checked for an asset to fall into it. Corresponding to each asset group, you will need to create policy sets manually, by configuring every individual alert, script, patch, and antivirus policies.

ADVANCED POLICY SETUP

Filter Conditions:

None, since device categories are condition-agnostic “folders”.

Policy Associations:

With the advanced policy, you can simply configure all your alerts, scripts, and patches at the root policy level and let the framework automatically pass on the configurations to its child policy sets. You can always customize settings at any of the child levels, which is what is done in this example.

For assets that fall under the Gold Plan, the policy set associated with this asset has SentinelOne enabled as the antivirus. Similarly, for Silver Plan, the antivirus is going to be Webroot. In this fashion, you can customize your inherited policies at the child levels as required.

Overall Policy Hierarchy

Root Policy: Windows Servers

Applies to all Windows servers across all clients, including patching logic, alerting, and scheduled scripts. Antivirus is not defined at this level.

Child Policy 1: Dell - SentinelOne

Inherits all root-level settings, but you can add custom alerts or scripts specific to Dell servers and enable SentinelOne as the antivirus for this policy.

Child Policy 2: Dell - Webroot

This is a child of Dell - SentinelOne, where Webroot is turned on, and SentinelOne is disabled.