Multiple policies on one folder

I’m currently struggling with the amount of work we’re going to have to do to get policies assigned the way we’d like them. If I have four policies I’d like to apply to all of one customer’s machines, there’s not a reasonably good way for us to do this, especially when different policies won’t apply to all customers. If all the settings applied everywhere I’d obviously just bake them into the default, but not all customers will have the same set of policies/settings.

One option is to create multiple levels of folders and assign one policy to each, then move all the computers and servers into the bottom folder. The problem with this is that I have to create all those folders at each customer, which is a nuisance, and then computers that get Syncro newly installed will be placed into the top-level folder instead of the one where they belong. That leaves us having to constantly hunt for new machines and move them appropriately.

Another option would be to create multiple “default” policies to wrap up the settings we want into one policy instead of four, then apply that to the top level of a customer. The problem with that is if we want to make a change to the “default”, we have to make sure that it’s done the same across multiple “default” policies. If I have one regular “default” policy that applies to everyone, and three other policies that will only apply to a few customers each, with some getting all and some getting only one or two, then I’ll end up with eight different “default” policies and will have to maintain them all, instead of maintaining four.

Maybe this is trivial to some people, but the more policies we end up having, the more complex this gets. Thing would be so much easier if I could just assign policies ABCD, ABD, AC, or whatever to the top level. Obviously if they conflict that’s a problem, but if inheritance and override can happen between folders, it should be possible to just say “Apply the policies in the order BDCA” on the top level folder.

It’s not possible to have multiple policies against one folder. To answer some of your questions specifically:

1.) If there are four policies you want to apply to all of a customer’s machines, I’d just make that into one policy, apply it to the top-level folder for the customer, and you’re done.

2.) What most folks do is find what is common amongst all their assets. For example, most folks would want to be notified if hard drive space is running low. So that becomes an item that is present in your “default” policy, and that gets bulk applied to your top level folders. Anything else is your variances. So if you have a server/workstation policy, make server and workstation subpolicies and apply what is specific to each (on top of your default policy) respective folder.

3.) I am not sure how many combinations of top-level policies you have, but you might be able to just make X amount of policies that encompass what you need and apply them as necessary at the appropriate customer’s top-level folders. Here, though, you run the risk of needing to make a global change and now you have to make it against multiple policies instead of a single top-level policy. That’s the trade off with this approach.

4.) New customers being assigned to the top-level folder… this is really an onboarding flow issue. When you create a new customer, part of that flow should be creating applicable policies and policy folder structure, and then deploying assets after that process. Then everything gets exactly what it needs to the moment the agent gets deployed.

5.) Many policy items can be overridden, though some cannot. So if you want a monitor at your top-level folder, for example, and you have one asset that doesn’t need it, you can just make a policy with that monitor added, but disabled, and then apply it directly to the policy. If you have a bunch of assets that need an override, that’s when I would recommend making a subfolder, applying the override policy to that, and placing qualifying assets there.

I fully understand that it’s not currently possible. That’s why I posted in the Feature Request section.

  1. Yes,I could do this, but then I end up with more top level policies to maintain than I want.

  2. Obviously everything that applies to everyone goes in the default policy. My problem is that the potential number of variances is going to cause me a lot of headaches.

  3. Same as 1.

  4. Are you saying there’s a way to specify per-customer which folder new assets should automatically deploy to? I was under the impression that new assets always deployed into the top-level folder. For new client setup obviously I can just move everything into the correct folder when I set them up, but for new computers after that or for computers that maybe weren’t powered on because someone was on vacation they’ll deploy to the top level folder later when the agent installs. Then I’ll have to do maintenance all the time to make sure that the computers get into the right folders.

  5. For necessary overrides the folder structure works just fine. I’m not worried about that part. I’m concerned about the maintenance of either so many policies, or so many nested folder structures.

Just curious, how many top-level policies would you wind up with if you had to guess? Curious if it’s like 10 or more like 100.

There is a way to install an agent right into the applicable policy folder. So for example if you have a small office and the only real variance is workstation/server for policies, you might have your structure setup with a top-level folder, and then two subfolders (servers, workstations). When you create an agent installer, you will need to define the folder that installer will drop your machines into. So it could be the Top Level Folder, Top Level Folder > Workstations, or Top Level Folder > Servers. So if you were going on site to do this for example, you could just bring a USB drive with your servers installer and your workstations installer. You should never need to do maintenance after the fact unless you are looking to modify or update your structure for some reason.

I wouldnt mind having the same though. For example, clients may add some computers with backup and others with not - but in those same groups - devices with AV or other task still broken down into server and desktop.

So it would be nice to see a more compact folder designs where you could place more than one policy into the group. This isnt the first time someone requested something like this even before the change to policy a year ago. Same with me asking about it for API/Code reason as well.

This way you can just still have that high level policy - Default Plan follow by another folder: Workstations and Servers then add AV Plan and Backup Plan without having to create more folders. Of course, if you need to - you could for other reasons.

Then when it comes to billing, I could check list those items that are being apply vs having to find 3 different items (AV, Backup, AV + Backup). Also one less policy I have to update in the future if anything changes for Backup (like in the case of Snycro dropping backup support). “Backup Plan” is just an example of a policy change in this statement.

Right now it looks more like:
Default Plan folder → Server, Workstation
Server: Backup → AV → Managed ( Folder + Policy )
Server: Managed + Backup + AV ( Single folder with a single policy (that covers all those services) )
Server: Managed → Backup OR Server: Managed → AV (Same as the first, but more broken down to a single extra service)
Server: Managed | Unmanaged → etc etc

Lots of options there… granted in the future we are looking into adding scripts that can look for the software instead and then do checks from there - but goes again to needing to know what is managed and what level … something that was missing in the API. In the mean time I have policy/scripts that add it in instead for now to get around this, but still a bit of a pain:)