Just a warning on endpoint identity groups, the more you have the slower the ERS API runs. This is due to how the RBAC is evaluated while making API calls.
I have two suggestions that you could use here.
- Append something like SAL (static allow list) to the beginning of all of your identity groups that are used for statically assigning endpoints to. With this you can use specific purge rules such as these two. Delete anything that's been inactive for more than 30 days that's not in a static "SAL" id group. Then Purge any statically assigned "SAL" endpoint that's been inactive for more than 180 days.
- The next option would be to use a custom endpoint endpoint attribute, assign the value of True to any static endpoint. This would be done when assigned the endpoint to a static group and would be an extra step. Bulk editing this would be pretty easy via CSV import or API.
I honestly suggest purging all endpoints, static or not, but treating them differently. If an endpoint hasn't connected in 180 days, or whatever is deemed appropriate then purge it. This avoids having ID groups full of stale decommissioned endpoints with minimal risk and rework.
Your first option is interesting. I hadn't considered it. I was thinking about creating a parent group for all my static endpoint groups and adding that parent group to the purge exception list. But this would mean that I would never purge anything in that group. That's been the most difficult part of making this decision...I'm scared to purge a static endpoint that was somehow still in use.
I have been looking at endpoint purge in a more granular way, but you're showing me here that I can really get away with just two purge rules with this method. I've also been focusing on Elapsed Days instead of Inactive Days, but maybe I should switch that as well.
