Yes, you can select the desired resolution state in the notification parameters

I believe he was asking if you could mount SAN volumes in addition to the S2D pool, not as drives members of the pool.

Interesting find... Could try modifying your script so that it would return a blank "test1" property instead of not returning it?
Something like
if ($test1 -eq $null)
{
$bag.addProperty('test1', ' ')
}

yes that's what I meant

I have no clue whether that should be considered a normal behavior ("if a replacement fails, stop replacing") or a bug...

You could run a workflow trace, it may show you what's happening : https://monitoringguys.com/2020/12/15/tracing-scom-workflows-with-powershell/

Then I'm out of ideas, sorry...
If at least the output was vastly different or overly long or with weird characters, that would have been something to investigate. But since you say the outputs are identical, that doesn't apply...

I can only make assumptions but I guess that the affected agents had failed over to that MS at some point.
I'm not too sure what's the criteria for an agent to failover, maybe TCP 5723 being unresponsive; which could explain why the agents didn't failover to another MS despite this one being greyed out.

Even right after an agent restart? There almost always is something in the event viewer....
Or sometimes on the management server event viewer

No, not possible.

You could have the powershell script itself run a loop which would check if the issue is fixed and with a 30min start-sleep inside it t, but that would not really be "firing the task every 30min if the monitor in unhealthy"...
Said otherwise, you can do whatever you want inside the script but it will start only once.

And remember to increase the Timeout interval for the recovery task, otherwise the script could get killed prematurly

• Not at all, you can absolutely create classes and their properties (=attributes) in MP Author and I would actually encourage you to do so.
  

• I don't see why you couldn't add multiple monitors inside a single MP
  

• The best way to achieve this in my opinion would be to :
  

• Create a "Application Class" based on a registry discovery, to discover all servers running that application regardless of the actual service name
  

• Create a Service class and discover its instances using a WMI query like "select * from Win32_Service where Name like '%Apple%'", targetting the discovery only at the Application Class and not all Windows Servers
  

• Create a service unitmonitor targeted at the Service Class

  
  

Kevin has various fragments that do more or less these stuffs but you will probably have to adjust them to fit that specific scenario.

That's because there actually is only one "Default Action Account" RunAs profile.
That profile defines the default accounts used to run workflows on the agents, when no specific other RunAs is defined.
On regular monitored servers, this account is usually Local System.
On Management Servers (which also run the agent), it's usually a domain account. So the "Manager Server Action Account" is the account defined for the Management Servers in the "Default Action Account" profile.
You can see the differences between Management Servers and regular monitored servers by having a look at the RunAs accounts listed inside the Default Action Account profile.

And I will definitely agree that using "account" in the name of a profile is confusing.

Well the default installations account is the account listed in the default action account profile for the management servers.
So if the management servers are associated with the local system account inside the default action account profile, then management servers' local system account is your default installation account (and will obviously have no permission on the servers you're trying to push the agent to)

Unfortunately Uservoice has been discontinued and has not been replaced, as far as I know