Maybe an analogy will help. Imagine your office goes from sending out legal documents via fax, to sending out legal documents via email. Now your staff is complaining, I can’t send documents to a phone number anymore. Please make it so I can send emails to phone numbers. First off, people shouldn’t be using phone numbers anymore, because using emails is so much better. Second, you can’t just rip the guts out of your old fax machine, and put them into a computer. It would require a significant redesign. Plus how would you handle a Reply All? Fax machines (phone lines) aren’t capable of that.
In much the same way, Syncro can’t just re-enable the old Policy Assigned filter logic. That too would require a significant redesign. Take if from someone who’s worked with databases for 13+ years, the backend on Policy Inheritance (PI) is going to look completely different than the old “Flat” Policy Assignments.
IMO, this would be a nice to have (not required) feature. My primary goal was to do Policy Management and Cleanup, which requires knowing where policies are assigned, not specifically where they’re applied. In the old Flat Policy Assignment methodology, “assigned” and “applied” were effectively the same thing. But this is no longer the case with Policy Inheritance (PI).
-
Assigned - The linking of a policy to a single Policy Folder or Asset (even in PI, you can still link a policy at the asset level).
-
Applied - When the settings within a policy modify the asset’s Effective Policy in some way.
From an engineering perspective, calculating where a policy is assigned is much easier than calculating where it’s applied. Syncro has limited resources and a budget, so they’d be wise to focus on the features that provide the most benefit for the least investment. Also, if you structure your policies to overlap nicely, then knowing where they’re assigned is more useful than knowing where they’re specifically applied (more on that later).
Active Directory GPOs
Let’s take a brief look at Active Directory GPOs. That’s another type of Policy Inheritance model. You can view what OU(s) a GPO is linked to, but you can’t see the specific workstations and users that the GPO is applied to. This is not be accident. Yes, you can run the Group Policy Results wizard to see how GPOs are applied to a specific user and computer, but Syncro has an equivalent feature too. It’s called View Effective Policy. Syncro also gives us View in Policy Folder to help us quickly see where the asset resides in the PI hierarchy. These two features allow us to successfully manage policies on a single asset. But what about multi-asset policy management?
Policy Inheritance: Multi-Asset Policy Management
This is where we need to start having a PI mindset, and stop trying to keep track of where every single policy is being applied. Instead we should focus on understanding where our policies are assigned. When policies are structured to overlap with one another (an key tenant of good Policy Management) it’s easier to conceptualize how they apply to groups of assets. Organize similar assets into groups (Policy Folders) and ensure the policies applied to the groups make sense. Don’t worry about the individual assets.
Why not try to calculate all the assets that a given policy touches?
When using PI, this is not a great strategy for multiple reasons:
- Enterprise networks are big. Trying to track 10s of policies across 10s of thousands of endpoints is a losing battle.
- It’s very complex and costly (from a database resource perspective) to calculate which policies effect change across multiple assets. First, you have to determine where the policy is assigned (the goal of my Feature Request). Next, you have to JOIN all the assets that are located in each of the policy folders (or the asset itself). Then look at each asset and determine if it has any policies assigned below the level at which the target policy is assigned. Then compare each lower level policy to the target policy, and determine if the target policy is being superseded. This can be tricky, because some policy sections “stack” together, while other sections overwrite. Now imagine doing that for thousands of assets. To do this effectively, Syncro would need to employ a pre-calculate applied policy table, which would add even more complexity.
- It’s not all that useful. Depending on where an asset lives in the Policy Folder structure, and what parts of the policy are defined, and what other policies are defined before or after it, the effects of the policy may be different. As assets move around, and other policies are modified, you can’t rely on a single policy having the same effect across multiple assets.
Conclusion
Instead of asking “What assets does this one policy affect?” you should be asking “How does this one policy affect the whole hierarchy of policies?”. Another good question to ask is “Does this policy fit into my policy layering strategy?”
