Asset group creation and policy association are siloed, asset groups are created from the assets module while policies are created in the policy management settings page.

Creating an asset group is cumbersome since you need to manually enter filter conditions. For example, to create an asset group for VIP Servers, a filter condition needs to be set to check the platform category of an asset.

For any client level customizations, an existing policy set needs to be cloned and an additional client filter needs to be added.

No visualization tool is in place to illustrate how the asset groups and policies are organized. Policies are simply listed alphabetically, organized by OS (Mac and Windows). If you have a complex policy setup with a long list of policies, finding the right policy sets becomes difficult and tiresome. There are no visual cues that lead you to the policy set you are looking for.

The advanced policy comes with a set of default device categories that are predefined. You can create custom categories on top of them if required. Device categories are simply asset folders which do not need any filter conditions.

You can create custom device categories and map assets to them at your whim, without worrying about filter conditions. An asset that falls under a custom device category will not be mapped to any of the default categories. Hence, an asset will always only have one device category, and one associated policy set.

It is easy to visualize how policies and assets are organized. Advanced policy follows a tree structure, starting with a root policy set, followed by nested parent and child policy sets. Assets are organized into logical folders called device categories.

Policy sets, device categories, and policy associations are placed neatly in three different tabs. Policy associations can be edited easily.

Since overrides are not possible with the group-based policy, policy sets need to be cloned and customized every time you need to customize an existing policy set for a client.

Policy sets do not interact with each other in any way. All policy sets are siloed based on their groups, without any hierarchy.

With policy inheritance at play, a child policy set will inherit all the traits from its parent.

A new policy that’s introduced at a child level is also inherited backwards into all its parents and root policy sets. Policies inherited backwards are turned off by default. This two-way inheritance ensures no policy is missed in a hierarchy, and minimizes the need for manual effort.

Individual policies can be turned on/off at any level in the hierarchy. This allows for policy customizations at any policy set level.

We have introduced a new policy tab inside clients, which will give you an overview of a particular client’s policy management.

If an asset falls under more than one asset group, a policy overlap occurs. An asset that’s in two asset groups with two unique policy sets will end up having two effective policies, which leads to confusion. The policy associated to the asset group that was created the latest will take precedence in this case, which is not ideal and not easy to track.

Filter conditions for asset groups need to be set carefully to try and ensure one asset doesn’t fall into multiple asset groups.

Policy overlap is non-existent since it is impossible for an asset to be associated with more than one policy set! Since advanced policy follows a linear hierarchy, an asset can only have one policy set associated with it at any given point in time. One device, one policy.

While it is possible to change the policy association of an asset, it is impossible to associate multiple policy sets to one asset.

When you manually approve/reject a patch, it is not possible to restrict the patch to a particular asset group. Any manual patching will apply to all asset groups.

Patching becomes complicated if an asset falls under multiple asset groups and policy sets. The patch policy belonging to the latest created asset group will apply, since it takes precedence.

Patching can be automated at a policy set level, which means that the patch policy will apply to all assets associated with that policy set.

It is also possible to set up overrides for individual patches manually, at a policy level, globally, or at an asset level.

The SuperOps agent cannot be installed based on policy. All assets need to be onboarded first and put into asset groups, then policy sets are associated.

Automatically onboard new clients or new assets for existing clients in bulk using Intune or GPO, with a unique script based on the device category. This means that as soon as the agent is installed on an asset, the corresponding policy set associated to the asset’s category will immediately start applying.