Feature request - Default email notification group

[ChrisGundry]

Hi all

We have had a few instances where our users have become confused about why they are not getting alarm resolved emails or in fact why they are getting alarm emails in the first place. This confusion stems from the 'default notification group' setting in VeeamONE which is used by default on all default alarms as well as default on any new alarms, unless you specifically define something else manually in the alarm.

The issues are:
1. When the default group is used on an alarm, the condition/status column always shows 'Any state'. You can configure a single recipient in the default group, configure it with warning/alarm only and the alarm will still only show 'Any'. In this case the alarm could accurately reflect that the single recipients status is warning/alarm only, but it does not.

I appreciate that if you have multiple email addresses in the default group then it would not be possible to accurately reflect the multiple status' for each recipient in the current setup, which is I guess why it is not done that way. However, having it how it currently is, with it showing 'Any' is misleading, because the users see 'Any' and expect that they will get 'Resolved' alarm notifications as well as Warnings and Errors. If the default group recipient is set to Warning/Alarm only then this is NOT the case.

2. In a similar way the value/email address column only shows the first recipient in the default group, regardless of how wide you make the column, or how many recipients are in the 'default group'. Again, this is confusing because if there are two recipients, or god forbid distribution lists in the 'default group' then a recipient of an alarm goes into the alarm config and can't see their email address anywhere and doesn't understand why they are receiving the email.

Basic screenshots here just to confirm what I am talking about: https://imgur.com/a/UENzQ1H
Information had to be blurred and I couldn't change the email notification settings to try and clearly show #2 unfortunately, but just add a 2nd recipient to the 'default group' and you will see that it does not appear anywhere in the alarm screen, which is not at all helpful to users.

I have raised these issues under case # 05182511, but have been told that a feature request is required to fix it. I feel that the product is not accurately reflecting information, which is a bug in my eyes., not a feature request. It doesn't require a massive feature overhaul to add some other 'status' to improve #1 until a better way could be implemented. #2 could be adjusted to show a comma separated list or something instead, again not a lot of work there I would imagine. Maybe the ultimate solution could be as simple as when you select the 'default group' that all of the recipients are displayed in several rows, with the 'status' next to each one, all RO of course, but at least visible. Even better would be in some way combining the fix with my actual feature request below so you have a default list of 'ticked' recipients, which is updated when the 'default list' is changed, but you can also tick more or remove some default ticked ones. It is the default after all, but that shouldn't mean it is not changeable easily.

3. My actual feature request is that there be a recipient list definable somewhere so you can simply select a recipient to email, rather than having to select 'send email' then type in the email address each time. I was hoping to be able to achieve something similar by saying all alerts for VMs in the business view 'dev machines' go to email address x, but I can't see a way to do that without a lot of duplication and work. Is there a way? If not can it be added in some way please? I would like to retain the ability to type in a specific address in each alarm as well for edge cases, but having a tick list or a drop down or something would be a lot easier for repeat alarm customization that we have to do all the time.

Thanks

[wishr]

Hi Chris,

Thanks for the detailed explanation. Appreciate that.

1. The default notification group has a dedicated configuration that works on a per-user basis - that's why "Value" and "Condition" within the alarm notification settings become locked when that action is selected. The values you see in these columns will become enabled only if you select an action that supports them.
2. This column does not show the recipients defined in the default notification group - it shows the recipients you have added with another action being selected (#1).
3. Hopefully, I have understood the request correctly. If not, please let me know. You may define Business Group owners within Business View group settings which allows specifying several recipients separated with ";" or "," and a space. You will not be able to re-use the entered values in other groups, but this way you can at least define notification behavior for a specific piece of the infrastructure. To apply specific notification settings to multiple alarms, you may bulk-select them using CTRL and then change the notification settings for all of them in one turn (for example, set the "Send email to the Business View group owner" option).

[ChrisGundry]

1. Your explanation doesn't make sense to me. They are greyed out because the 'default group' is selected, there is nothing changeable because the settings come from the 'default notification group', no? So they never become un-greyed out if 'default notification group' is selected... Of course if you select another option like 'Send email' or 'Run script' then you get other options. But that is not the issue I have raised. The issue I have raised, and provided a screenshot for is that the 'status' in the column says 'Any', which is not accurate. I don't know how else to explain the issue!
I also don't follow your comment about the default group being 'per user', the default notification group is a server setting, which applies to all alarms where you configure the 'default notification group', no?

2. I don't understand this explanation either. You are right, on reflection it does not show the default group email, we changed the default group email the other day, which has confused me as it is now the same. I do not understand your explanation of where the email address is coming from though. I don't understand

it shows the recipients you have added with another action being selected (#1).

3. No, my request is to have a re-usable list of recipients, which can be selected from a list, rather than typing each time. I guess I should have added a #4

4. Have a way to group resources such as VMs in a way that allows you to have alarms generated for them go to specific addresses, but other alarms still go to existing addresses.
I don't follow your explanation again. We have a load of business views/group, most of which are just used for excluding resources from alarms for various reasons. However, one contains 'Dev' machines, which I would like to have their alerts go directly to the Dev team. I suspect I can do that somehow with the Business Group owner email setting, but I can't understand how. If I edit a business view category I don't see any way to add an owner, or email address etc. So I am not sure where the 'owner' element sits?

[wishr]

1. The "Any" status you see in the "Condition" column within the alarm settings is not applicable when the default notification group option is selected - that's why this column is locked, meaning it does not have any impact in such circumstances.
When you are configuring the default notification group settings, you can define a specific notification level for each user.

2. The explanation for this is the same as in #1. These two columns are not applicable when the default notification group option is selected. The reason you see the email address here is that at some point you had another action selected there and at that point set these email addresses. You can safely remove them by choosing an action that allows editing this column and remove the entire value, then switch the action back to the default notification group. Put it simply, the "Value" and "Condition" columns in the alarm notification settings are not intended to inherit the settings you set within the default notification group settings - they are completely independent.

3. Got it, thanks for clarifying.

4. It's already possible. You may have most of the alarms going to the default notification group, then create alarm copies and configure them to be sent out only to specific recipients or to the business view group owner, for example. For information on configuring business view group owner, please refer here (step 10). Alternatively, you may modify alarms in bulk using the aforementioned method.
The common practice is to have various business view groups for different pieces of infrastructure and configure a specific set of alarms with desired notification settings for each of these groups. This way, each dedicated team will only be receiving the alarms that are relevant for them.

Thanks

[ChrisGundry]

1. OK, I understand what you are saying, but that is exactly the point I am trying to make. The 'Condition' column isn't applicable, it is showing 'Any' for no reason whatsoever. The actual 'status' that is used is the one from 'default notifications', but yet, in the alarm it says 'Any'. This combined with the email address mentioned in #2 makes users think that they will get an email to address x (from #2), when 'Any' status change is detected for the alarm. This is misleading and confusing for users, hence raising the support case and this request. Just because you and I as more experienced Veeam ONE users know that the greyed out settings are irrelevant, doesn't mean they are not confusing for users who are less well versed in Veeam ONE. And the information is factually wrong, so it should not be there. There is no need for the 'address' or 'status' column to show any information at all when the 'default notification group' is selected, which would be much clearer for users. Or, as per my request, a comma separated list of all the 'default notification group' email addresses, or some better way to show the real status. But just having nothing would be 10x better than showing the wrong email address and status.

2. OK, I see what you are saying now, it took me a while because it just isn't logical for it to behave in that way IMO, so I didn't understand what you meant... In response, mostly see #1, except I think it is much more important that this issue is fixed than #1. It is showing the wrong email address, an address not related to what you have selected, which is the 'default notification group'. If you select the 'default notification group', then it should be showing no email address at all, or a comma list from the 'default notification group' email addresses. It should NOT be showing some random address that you entered into some alarm at some other point in time in the past, that is just super confusing for users. That may be how it is working now, but that is not how it should be working, that just makes no sense at all. I never noticed the issue before because I know that default means ignore it, so I just never looked at it at all, because it is greyed out. But as I said, this is causing confusion for our users.

3. Great

4. Ah that link helped, thank you. The bit I was missing was that the notification setting is at the next level down. So if you have a category for 'Dev VMs' you will have a group that is say 'Is a Dev VM' (matches condition x) and it is at that 2nd level where the notification option appears. This of course makes sense, but I was looking for it at the 'Dev VMs' level. I don't do a lot of playing around in business view to be honest, I mainly use it for bulk excluding objects from alarms in an automated way with VMware tags. I will do some testing when I have more time in the NY and hopefully that will help us achieve what we want to.

[wishr]

1. Yes, I see what you are saying. I guess we could just remove the values in the columns if they are incompatible with the selected action. That would make sense.

2. Same as #1 then.

4. Great. Let us know how it goes.

Thanks