Schedule Muting of Alerting on Individual Nodes Daily

I've actually updated this script to work without a text file and work using Custom Properties instead.  This gave me the added benefit of being able to update the schedules on an event trigger alert that looked for an event where the custom property was updated. 

Add 2 custom properties with the Date/Time Value.  Call them:

MuteScheduleFrom

MuteScheduleTo

Next, create a ps1 file somewhere on your primary polling engine and paste the contents below and save it.

$SwisHost = "" 
$Username = ""
$Password = ""
$SecPass  = ConvertTo-SecureString -String $Password -AsPlainText -Force
$Creds    = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $Username, $SecPass


if ( -not ( Get-Command -Name Connect-Swis -ErrorAction SilentlyContinue ) )
{
    Add-PSSnapin -Name SwisSnapin -ErrorAction Stop
}

$Swis  = Connect-Swis -Hostname $SwisHost -Credential $Creds

$SwqlForCustomProperties = "SELECT [Field] FROM Orion.CustomPropertyUsage WHERE [Table] = 'NodesCustomProperties'"
$CustomProperties = Get-SwisData -SwisConnection $Swis -Query $SwqlForCustomProperties

$SwqlQueryForDevices = "SELECT [Caption], [IP_Address], [$( $CustomProperties -join '], [' )] FROM Orion.NodesCustomProperties cp INNER JOIN Orion.Nodes nd on cp.NodeID = nd.NodeID"

$Nodes = Get-SwisData -SwisConnection $Swis -Query $SwqlQueryForDevices | ?{$_.MuteScheduleFrom -ne $null} | Select Caption,MuteScheduleFrom,MuteScheduleTo

$Today = Get-Date -Format dd/MM/yyyy

$Schedule = Foreach ($Node in $Nodes){

$Table = [PsCustomObject]@{
                            Node        = $Node.Caption
                            EntityUris  = Get-SwisData $Swis "SELECT Uri FROM Orion.Nodes WHERE Caption IN @captions" @{captions=($node.caption)}
                            TimeFrom    = ($Today +" "+ $Node.MuteScheduleFrom.TimeOfDay -as [DateTime])
                            TimeTo      = ($Today +" "+ $Node.MuteScheduleTo.TimeOfDay -as [DateTime])
            }
        $Table  
        }  
        
Foreach ($object in $Schedule){

$entityUris = $object.entityUris
$entityUris = @( $entityUris |% {[string]$_} )

Invoke-SwisVerb $Swis Orion.AlertSuppression SuppressAlerts @($entityUris, $object.TimeFrom, $object.TimeTo) | Out-Null
}

#Remove Old Entries that have passed -1 day from current date for instances where CustomProperty has been cleared.
#$Remove = Get-SwisData $swis "SELECT ID, EntityUri, SuppressFrom, SuppressUntil FROM Orion.AlertSuppression" | ?{$_.SuppressUntil -as[datetime] -lt (Get-Date) -and $_.SuppressUntil -ne $null}
#If($Remove){
#Invoke-SwisVerb $swis Orion.AlertSuppression ResumeAlerts @(,$Remove.EntityUri) | Out-Null
#}

Get-SwisData $swis "SELECT ID, EntityUri, SuppressFrom, SuppressUntil FROM Orion.AlertSuppression"   

Next create a new a new alert with the following 

Then go to your trigger action and configure the "Execute Program" with the path to PowerShell and argument to call your script.

As the date time field forces the use of Date, and we are only interested in time we strip out the date within the script and replace it with the current Day.  You need to back this up with a scheduled task as well, to make it sure it updates each day.

Responding to why it's not an ootb option,  I've been pushing the idea with SW for years that there would be a use case for a lot more calendar based capabilities,  but so far it hasn't made it up the priorities list. 

So the muting and unmanage functions currently rely on a table that is designed to only ever have a single entry per object, even if you get crazy and start trying to insert additional rows to create a weekly schedule they tend to get cleaned out as part of the normal operations.  Bummer.   

So what I do on my end is kind of similar in concept to your csv, im just doing it in an extra database table.  I've got scripts that read the table and it parses cron format for scheduling recurring and also one time events. If there is an upcoming maintenance that we need the script will see it, check the relevant columns in Orion and update/ insert them as necessary, I just let that run in the background every few minutes adjusting things as we go.   Downside is that it will blow away anything people schedule via the GUI, so I've just had to train my users around that behavior and remind them not to use the native functions. I display the schedules in Orion by using the custom table widget and plain SQL to reach over to my table and pull in whatever we need.  If I was a bit stronger in web development stuff I believe I'd be able to set up custom HTML widgets to manage this all in the Orion console to make it seem more native,  but I continue to suck at webdev so we get by.

Thanks for clarifying that.  It's actually been quite fun learning all this stuff.  I was asked by someone today what happens if a node goes down and you have a schedule on it, how does it alert.  So I created a group called Muted Alerts and I dynamically update the group based on if the time falls within the period then send the group alert to teams as informational alert via a webbook.  Only in rare situations, but learned a lot doing it.  I used a custom table also, works fine.  Get to keep an eye on what is in there.  With what I've learned over the last few days, you realise, that if its not in the system, then you can work it in to there somehow through the backend.

Thanks for clarifying that.  It's actually been quite fun learning all this stuff.  I was asked by someone today what happens if a node goes down and you have a schedule on it, how does it alert.  So I created a group called Muted Alerts and I dynamically update the group based on if the time falls within the period then send the group alert to teams as informational alert via a webbook.  Only in rare situations, but learned a lot doing it.  I used a custom table also, works fine.  Get to keep an eye on what is in there.  With what I've learned over the last few days, you realise, that if its not in the system, then you can work it in to there somehow through the backend.