using ePO and groups to manage Solid Core mode?

[taylorfusion]

We have 150 endpoints receiving ePO policies, Solid Core etc. I learned the hard way that I couldn't just create groups and drag my endpoints into them that were previously receiving firewall policies and retain those earlier policies. In other words, I thought an endpoint could be part of more than one group/sub-group.

Can ePO be setup to group endpoints for the  selective Task of setting Solid Core modes?

When we patch, we want to only set an endpoint into "update" mode, patch, then end update mode. We would follow suit for the other groups.

Possible with ePO? If so, how?

thanks

[cdinet]

You can use policy assignment rules based on tags, users or system tree location to accomplish what you want.  

https://docs.trellix.com/bundle/trellix-epolicy-orchestrator-on-prem-5.10.0-product-guide/page/GUID-...

[taylorfusion]

Documentation not helping much I'm afraid, Can you provide an example that collects two 'groups' to set endpoints in Update mode?

[cdinet]

To automate things, create a query as a table for system names, filter the query for those 2 groups, then set up a server task to run that query and as secondary action, apply specific policy.

Or, go to system tree to one of the groups, policy assignment page, then break inheritance at that group and assign the desired policy.  Repeat for second group.

[taylorfusion]

Thanks....for that second solution, will the ' break inheritance at that group' cause the earlier assigned policies to cease to function?

[cdinet]

A client will only use what policies are assigned to it.  Lets say you have groups a, b and c, you break inheritance on b and c and assign a different policy.  group a will continue to use original policy, groups b and c will apply the newly assigned policy.  

[taylorfusion]

Then that isn't going to work...Sounds like ePO isn't the right solution to manage Groups of endpoints for Tasks like placing servers in Update mode.

We have these ePO groups like these:

DCs

LAG servers

MIM servers

PKI servers

PAWs

Utility servers

...each group may get different firewall rules, solid core rules etc

However, all (150) of them have Solid Core installed.

When we get to monthly patching, we utilize AD Security groups to neatly encompass the patching effort in Azure, spread across several days. We push patches to the (azure/AD groups we see).

The way ePO displays these 150 servers is either through the System Tree en masse, or in the various aforementioned sub groups.

When we get to a particular patching day, we wanted to see if ePO can let us essentially group those 150 servers in similarly named ePO groups (or other mechanism) to then sort by those "ePO Patching Groups" and place that group in update mode, patch then turn off update mode. Move on to next group, etc

Doesn't sound like ePO can do this without breaking the various ePO policies they respectively receive?

[cdinet · Accepted solution]

Well not necessarily.  It looks like you need something that will dynamically assign a policy regardless of their location on a temporary basis to put them in update mode for the patching.  There is a solution for that.

1.  Create a tag for solidcore update mode and don't set any criteria for it - it would be a manual assignment.  

2.  For the systems you want to patch one week or day, make a list of them, then use a server task to upload systems by file, then secondary action assign tag and assign those systems that tag.  

3.  Create a policy assignment rule based on that tag and assign it the policy to set systems in update mode.

4.  Once the systems are patched, create second server task to load that same list, then secondary action to remove the tag.

When you use policy assignment rules, the policy is applied as long as the rule applies to the system.  When the rule no longer applies, then the client uses the policy that is assigned at the system tree level.  That way you don't have to mess with system tree assignments or broken inheritance.  Policy assignment rules take precedence over system tree assigned policies.

[taylorfusion]

Thanks, will give it a shot

[cdinet]

With that, your list can change as needed for different systems and it will only affect the tagged systems.  All that also depends on the clients checking in to get an updated policy, so you might have to add a second action to wake up systems.  I would only do that if your list is relatively small.  Otherwise, give yourself at least a couple of asci lead time before patching takes affect for clients to apply the policy.