Inside Central Podcasts–Episode 12–OpsMgr 2012 Command Shell
Last week I had to some long car drives to one of our customers and had plenty of time to listen to some of my favorite podcasts like the PowerScripting Podcasts and Inside Central Podcasts. And in Episode 12 both of my favorite topics where discussed, PowerShell and Operations Manager.
In this episode Pete Zerger and Dan Kregor discuss some of the changes you can expect to see to the Command Shell in OpsMgr 2012. And to my surprise they mentioned some of the PowerShell and OM12 stuff I blogged about
And because I love to dive into the new OM12 Cmdlets and Functions here some more things to explore.
If you looked at my blogpost about what’s new in OM12 for PowerShell you may have noticed that in OM12 we don’t have the Resolve-Alert in OM12. We now have the Set-SCOMAlert Cmdlet.
If we look at the help for the Set-SCOMAlert Cmdlet we see the following:
get-help Set-SCOMAlert NAME Set-SCOMAlert SYNOPSIS Changes the properties of the specified alert. SYNTAX Set-SCOMAlert [-Alert] <MonitoringAlert[]> [[-CustomField7] <String>] [[-CustomField8] <String>] [[-CustomField9] <String>] [[-Owner] <String>] [[-ResolutionState] <Byte>] [[-TicketId] <String>] [[-Connector] <MonitoringConnector>] [[-CustomField1] <Strin g>] [[-CustomField10] <String>] [[-CustomField2] <String>] [[-CustomField3] <String>] [[-CustomField4] <String>] [[-CustomField5] <String>] [[-CustomField6] <String>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]] [<CommonParameters>] DESCRIPTION The Set-SCOMAlert cmdlet changes the properties of the specified alert. RELATED LINKS Online Version: https://go.microsoft.com/fwlink/?LinkID=187701 Get-SCOMAlert Get-SCOMConnector REMARKS To see the examples, type: "get-help Set-SCOMAlert -examples". For more information, type: "get-help Set-SCOMAlert -detailed". For technical information, type: "get-help Set-SCOMAlert -full". |
Do you see there is no Comment property like we had in the OpsMgr 2007 Resolve-Alert Cmdlet?
Look at the examples:
get-help Set-SCOMAlert -examples NAME Set-SCOMAlert SYNOPSIS Changes the properties of the specified alert. -------------------------- EXAMPLE 1 -------------------------- PS C:\>Get-SCOMAlert -ResolutionState 15 | Set-SCOMAlert -ResolutionState 255 Description ----------- This command gets all alerts with a resolution state of 15 and then uses the pipeline operator (|) to pass the alert objects to the Set-SCOMAlert cmdlet which closes the alert by setting the resolution state to 255. -------------------------- EXAMPLE 2 -------------------------- PS C:\>Get-SCOMAlert -Name "Failed Accessing Windows Event Log" | Set-SCOMAlert -Owner "CONTOSO\Isabel" -CustomField1 "Root Cause - Permissions" Description ----------- This command gets all alerts named "Failed Accessing Windows Event Log" and then uses the pipeline operator to pass the alert objects to the Set-SCOMAlert cmdlet which changes the owner and sets the value for CustomField1. |
When we look at the help for the OpsMgr 2007 R2 Resolve-Alert Cmdlet we see the following:
>get-help resolve-alert NAME Resolve-Alert SYNOPSIS Resolves an alert. SYNTAX Resolve-Alert [-Alert] <MonitoringAlert> [[-Comment] [<String>]] [-WhatIf] [-Confirm] [<CommonParameters>] DESCRIPTION Resolves an alert. RELATED LINKS Get-Alert Get-AlertHistory REMARKS To see the examples, type: "get-help Resolve-Alert -examples". For more information, type: "get-help Resolve-Alert -detailed". For technical information, type: "get-help Resolve-Alert -full". |
This Cmdlet has different parameters then the Set-SCOMAlert Cmdlet, so we need to find some workarounds to solve this.
If we still want to use the Resolve-Alert Cmdlet in OM12 we can easily create a function that does the same as the old Resolve-Alert Cmdlet. We just need to use Set-SCOMAlert with a ResolutionState of 255 to achieve the same result as
the old resolve-alert cmdlet.
Open your favorite PowerShell Editor and create a new Resolve-SCOMAlert Function.
<# .SYNOPSIS Resolves an Alert .DESCRIPTION Resolves an Alert .PARAMETER Alert Specifies the alert to resolve. You can use Get-Alert to create an object to pass as the value of this parameter. .PARAMETER Comment Specifies a comment to associate with the resolved alert. .PARAMETER WhatIf Describes what would happen if you executed the command without actually executing the command. .PARAMETER Confirm Prompts you for confirmation before executing the command. .EXAMPLE C:\PS\get-SCOMalert | where-object {$_.Owner -eq "kenmeyers"} | resolve-SCOMalert -comment "Resolving all of Ken's alerts." This command uses Get-SCOMAlert to retrieve all alerts. It then pipes the results to Where-Object to only select the ones owned by Ken Meyers. The alerts that pass the filter are piped to Resolve-SCOMAlert to be resolved with the comment, "Resolving all of Ken's alerts." .EXAMPLE C:\PS>$alerts = get-scomalert | where-object {$_.ResolutionState -eq 0} foreach($alert in $alerts) { resolve-alert -comment "Resolving Alert" -Alert $alert } This command uses Get-Alert to retrieve unresolved alerts. Unresolved alerts have a resolution state equal to 0. The command then loops through all the unresolved alerts, calling Resolve-Alert to resolve each of them. The comment "Resolving Alert" is associated with each resolved alert. #>
function Resolve-SCOMAlert { <# -Mandatory - a boolean saying whether the parameter is required or not. A mandatory parameter that is not specified generates a run time exception. -Position – an integer specifying where parameter’s order. As you can see in the above example, the $User paramater is the third parameter, while $domain is the first and $computer the second. -ValueFromPipeline – a boolean indicating if the parameter can come from the pipeline. #> [CmdletBinding()] PARAM( [Parameter(Position=0, ValueFromPipeline=$true, Mandatory=$true)] $Alert , [Parameter(ValueFromPipeline=$true,Mandatory=$false)] [AllowEmptyString()] [string]$Comment , [Parameter(Mandatory=$false)] [boolean]$Whatif , [Parameter(Mandatory=$false)] [boolean]$Confirm ) #Set Resolutionstate Parameter for Set-SCOM Alert $RState = "255" set-variable $RState -option constant # The constant option write protect the resolutionstate property. # Call now the Set-SCOMAlert with the default parameter –ResolutionState 255 if ($PSBoundParameters.TryGetValue('Comment', [ref]$Comment)) { #There is no Comment Parameter in the Set-SCOMAlert Cmdlet, so we use CustomField1 for the Comment. $PSBoundParameters.Remove('Comment') | Out-Null $PSBoundParameters.Add('CustomField1', $Comment) } #Call the new OM12 Set-SCOMAlert Cmdlet with the correct parameters Set-SCOMAlert @psboundparameters -ResolutionState $RState } |
We start the new function with some help info. I just copied the help info from the old Resolve-Alert Cmdlet and only changed Resolve-Alert to the new naming convention in OM12 Resolve-SCOMAlert.
Then I created a new Function called Resolve-SCOMAlert, which has the same parameters as the old Resolve-Alert Cmdlet, with a default value of 255 for the ResolutionState parameter.
Because the Set-SCOMAlert is missing the Comment property we need to remove the Comment parameter from the $PSBoundParameters and replace that with a new CustomField1 property.
Ok, let’s check if our new Resolve-SCOMAlert Function is working the same as our old Resolve-Alert Cmdlet in OpsMgr 2007.
Open the Operations Console and pick an Alert we want to resolve.
We are going to resolve the “IIS Restart is required” Alert using our new Resolve-SCOMAlert function.
Open the Operations Manager Shell and load the new Resolve-AlertSCOM Function by dotsourcing the above script.
We can now show the help of the new Resolve-SCOMAlert function with the usual get-help cmdlet.
Now we can try to use the resolve-scomalert function on our “IIS Restart is required”
We first need to get the “IIS Restart is required” alert using the new OM12 Get-SCOMAlert Cmdlet.
When we use some formatting and extra properties we see that this is our Alert we want to resolve.
The final step is resolve this alert and add a comment.
get-scomalert | where {$_.Name -eq "IIS Restart is required"} | resolve-SCOMAlert -Comment "Resolved with new Resolve-SCOMAlert Function"
Now let’s check if our Alert is being resolved and has the Comment in CustomField1.
It worked!
If you want to use the Whatif or the Confirm parameter you just need to add $true after those parameters. Example:
Disclamer: Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Included script is an example script.
Comments
Anonymous
January 01, 2003
Is there a way to extract the event parameters from get-scomalert?Anonymous
November 26, 2011
Thanks alot for this guys. The screencaps really helped.Anonymous
December 13, 2011
Great post Stefan. Can't believe I missed this (and your tweet). I really need to stay on top of things! Also, thanks for the plug :)