Automation profiles are making life harder rather than easier. Bulk add or remove issue persists

reza
reza Member Posts: 3 ✭
in Patch Management

Hey everyone,

I have 201 automation profiles which need to be applied amongst customers and different type of devices. There are different scenarios I followed:
-If I need to apply Profile 1 to multiple devices, I can create folder A and assign the profile. But when a device needs to be on Profile 2 it needs to either to have Folder B or simply be added as a second profile to Folder A again. But there are many devices that will end up in one of these folders which then need Profile 3 be applied to them but the device is already either part of folder A or B and there is no way to create a Folder C to be able to apply Profile 3 to it because the device is already added to other folders. So if there is a device in one of the folders which I need another profile to be assigned to it but don't want it to also have other profiles to be pushed to this device, then I am at a loss.

-So I am left with assigning Profiles to individual devices which you can guess with 500+ devices and 200+ automation, the number of combinations that I am left with goes so high it is not worth trying to go to each individual device page and add them.

I tried seeing if there is a possibility to list the devices in the page of the profile assignment and select them there, but they won't show there and you have to go to device page and assign them. Removing them from a profile is also a one by one action which takes so much time that it is not feasible.
I am checking with other RMM providers to see if they have a solution for it and try that in Atera, which seems they have but I cannot find any of those in Atera. If anyone has any ideas, please let me know.
Best,
R.

at.PNG

Tagged:

Comments

  • COOLNETAU
    COOLNETAU Member Posts: 44 ✭
    edited July 18

    If Atera would call folders what they really are, as there is no inheritance (sub folders should be a thing) - I suggest that Atera implement a Policy tag feature, which could work similar to current folder+policy thing, but with inheritance.

    or just fix folders

    FOLDERLEVEL1=PolicyA
    Folderlevel2underFOLDERLEVEL1=PolicyA, any changes from POLICYA-Level2 overriding any settings in PolicyA
    FolderLevel3underFolderlevel2underFOLDERLEVEL1 does same, taking the effective policy from Folderlevel2underFOLDERLEVEL1 and over-rides again

    any folder under another folder SHOULD inherit the main folders settings, and then override any changes based on the policy changes

    MAXRMM - now owned by I think solarwinds (hound dog → GFI → LogicNow → solarwinds) did this really well

    might be an idea for someone at Atera to sign up for a trial over there

    Now called solarwinds RMM I believe

Topics