3rd party patch management automation dynamic grouping
We came to Atera from using PDQ Inventory/PDQ Deploy and were admittedly spoiled rotten with how well that solution worked. This is in the scope of what PDQ refers to as "dynamic collections" - and this is something Atera would benefit hugely from, should they choose to go after this. I tried to keep this brief, and failed miserably - my apologies in advance, and gratitude to anyone that reads to the end ;)
For full context this video does a good job outlining dynamic collections in PDQ: https://www.youtube.com/watch?v=wVWzNhZHPV4
Here's the scenario:
We have ~50 3rd party software titles that we manage on subsets of computers. In PDQ, to manage 3rd party software we simply created a dynamic collection containing "devices with software 'xyz' installed", which we could then target for automated 3rd party software updates and patches.
Take for example our deployment of Visual Studio Code and AutoCAD Inventor. There's maybe 30 users in our company that require VS Code on their computers, and about 40 that require AutoCAD inventor. These are not mutually exclusive lists; there are some users who require both VS Code and AutoCAD Inventor on their computer, and many others that need only one or the other.
We have "overlaps" like this all across our 3rd party software deployments.
I've worked with Atera Support on this and they offered the solution of using folders for 3rd party patch automation - but unfortunately, as an agent can only be a member of one folder at a time, this doesn't help our "overlaps" discussed above.
For the time being we’ve been able to achieve a “good enough/close enough” solution with Atera using the following:
1.) Create 3rd party software bundle and automation profile
2.) Use custom views in the Devices tab to create our “dynamic collections”
3.) Assign Step 1 automation profile to the devices in this view
It’s Step 3 that gives us the trouble, as the automation profile is assigned to devices in the view, rather than the view itself. When we perform Step 3, it only applies to the devices that were in that view at that specific date/time the automation profile was assigned.
This means that, if we were to repurpose a device and it no longer needed the 3rd party automation profile from step 3, it would still have this automation profile assigned until we remove it manually. Likewise, new devices coming in do not pick up the automation profile either – even though they are dynamically added to the saved view. I think if we had the ability to assign an automated profile to a saved view, rather than the devices in the view at that point in time, that would make Atera even more powerful and beneficial to us.
Thanks for considering!