Monthly Archives: August 2017

powercli script configure vcenter alarm email actions

PowerCLI Script to Configure vCenter Alarm Email Actions

Have you ever gone through your vCenter and configured alarms to email?  If you have, you know that if anything ever screamed for automation within vSphere, it’s this, as it is extremely tedious.  You really want to use a PowerCLI script to masnage vCenter alarm email actions!

For one, the action must be set individually on each alarm. On top of that, you configure each alarm with the email address(es) you want  to be sent alerts.  You can also set repeated email actions on each alarm.  While this provides granularity and customization opportunities, it creates a boring snoozefest, inviting confusion and human error in configuring them.  Plus, vCenter contains many alerts, and many people do not know which ones you should configure for emails, and how critical each one is.

Introduction to PowerCLI Script to Configure vCenter Alarm Email Actions

I found a good script about a year ago to do this with PowerCLI script using a CSV of the alarms.  I cannot seem to find who made it now.  If you stumble on this and know who originally made the similar script, please comment below.  I very much want people recognized for their hard work.

Not to simply take the script, I added additional functionality to it, to provide end to end configuration, including vCenter SMTP email server settings, as well as the ability to configure multiple vCenter servers in one fell swoop.  Also, I really love the design of this script for several reasons:

  • Simplicity rules this script.  Even if you want the script to do something else, it’s easy to follow and adapt.
  • One can easily adapt the script to new versions of vSphere.  Each version of vSphere adds, removes, or changes alarms.  I can easily dump those alarm names into a new CSV and set their values.
  • It provides a three-tiered priority system for email frequency.   Don’t like them?  It’s easy to change them within the script.
  • Ongoing maintenance of the alerts is a snap.  Change the values within the script, and simply rerun it.
  • The CSV file provides an opportunity to track changes to alerts and a deliverable document.  I intend also to maintain the CSV files here as I receive feedback on the alarms.

Ready to use a PowerCLI script to configure vCenter alarm email actions?

Directions for PowerCLI Script to Configure vCenter Alarm Email Actions

This PowerCLI script to configure vCenter alarm email actions is very straight forward.  You simply set the variables at the beginning of the script, which includes info such as vCenter servers, the CSV file to be used, vCenter user name and password, the SMTP server and port to use, etc.

Next, set the values within the CSV according to how you want that alert configured within the Priority column.  The values are as follows :

  • Low Priority – Removal of all email alert actions, and reconfigured to send one email without repeat emails for non-critical alerts.
  • Medium Priority – Removal of all email alert actions, and reconfigured to send one repeated email daily for more serious alerts.
  • High Priority – Removal of all email alert actions, and reconfigured to send one repeated email every four hours for more serious alerts.  (I originally set this to hourly, but customer feedback said this was far too much.)
  • Disabled – Removal of all email alert actions.  Use this on alerts that are far too chatty (looking at you VM CPU and memory usage!), and you wish to turn emails for them off.
  • Blank (aka no value) – Leave the alarm as is in case you manually configured the alert and wish to keep it that way.

$vcenterservers = "vcenter1.vs6lab.local","vcenter2.vs6lab.local"
$vcenterusername = 'administrator@vsphere.local'
$vcenteruserpwd = 'P@ssw0rd'
$alarmfile = import-csv c:\scripts\vsphere60-alarms.csv
$AlertEmailRecipients = @("email1@domain.com","email2@domain.com")
$SMTPServer = "FQDNorIP.domain.com"
$SMTPPort = "25"
$SMTPSendingAddress = "sender@domain.com"

#Import PowerCLI module
import-module -name VMware.PowerCLI

#----These Alarms will be disabled and not send any email messages at all ----
$DisabledAlarms = $alarmfile | where-object priority -EQ "Disabled"

#----These Alarms will send a single email message and not repeat ----
$LowPriorityAlarms = $alarmfile | where-object priority -EQ "low"

#----These Alarms will repeat every 24 hours----
$MediumPriorityAlarms = $alarmfile | where-object priority -EQ "medium"

#----These Alarms will repeat every 4 hours----
$HighPriorityAlarms = $alarmfile | where-object priority -EQ "high"

foreach ($vcenterserver in $vcenterservers){
Disconnect-VIServer -Confirm:$False
Connect-VIserver $vcenterserver -User $vcenterusername -Password $vcenteruserpwd
Get-AdvancedSetting -Entity $vcenterserver -Name mail.smtp.server | Set-AdvancedSetting -Value $SMTPServer -Confirm:$false
Get-AdvancedSetting -Entity $vcenterserver -Name mail.smtp.port | Set-AdvancedSetting -Value $SMTPPort -Confirm:$false
Get-AdvancedSetting -Entity $vcenterserver -Name mail.sender | Set-AdvancedSetting -Value $SMTPSendingAddress -Confirm:$false

#---Disable Alarm Action for Disabled Alarms---
Foreach ($DisabledAlarm in $DisabledAlarms) {
Get-AlarmDefinition -Name $DisabledAlarm.name | Get-AlarmAction -ActionType SendEmail| Remove-AlarmAction -Confirm:$false
}

#---Set Alarm Action for Low Priority Alarms---
Foreach ($LowPriorityAlarm in $LowPriorityAlarms) {
Get-AlarmDefinition -Name $LowPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail| Remove-AlarmAction -Confirm:$false
Get-AlarmDefinition -Name $LowPriorityAlarm.name | New-AlarmAction -Email -To @($AlertEmailRecipients)
Get-AlarmDefinition -Name $LowPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Green" -EndStatus "Yellow"
#Get-AlarmDefinition -Name $LowPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Yellow" -EndStatus "Red" # This ActionTrigger is enabled by default.
Get-AlarmDefinition -Name $LowPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Red" -EndStatus "Yellow"
Get-AlarmDefinition -Name $LowPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Yellow" -EndStatus "Green"
}

#---Set Alarm Action for Medium Priority Alarms---
Foreach ($MediumPriorityAlarm in $MediumPriorityAlarms) {
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail| Remove-AlarmAction -Confirm:$false
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | Set-AlarmDefinition -ActionRepeatMinutes (60 * 24) # 24 Hours
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | New-AlarmAction -Email -To @($AlertEmailRecipients)
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Green" -EndStatus "Yellow"
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | Get-AlarmActionTrigger | Select -First 1 | Remove-AlarmActionTrigger -Confirm:$false
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Yellow" -EndStatus "Red" -Repeat
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Red" -EndStatus "Yellow"
Get-AlarmDefinition -Name $MediumPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Yellow" -EndStatus "Green"
}

#---Set Alarm Action for High Priority Alarms---
Foreach ($HighPriorityAlarm in $HighPriorityAlarms) {
Get-AlarmDefinition -Name $HighPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail| Remove-AlarmAction -Confirm:$false
Get-AlarmDefinition -name $HighPriorityAlarm.name | Set-AlarmDefinition -ActionRepeatMinutes (60 * 4) # 4 hours
Get-AlarmDefinition -Name $HighPriorityAlarm.name | New-AlarmAction -Email -To @($AlertEmailRecipients)
Get-AlarmDefinition -Name $HighPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Green" -EndStatus "Yellow"
Get-AlarmDefinition -Name $HighPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | Get-AlarmActionTrigger | Select -First 1 | Remove-AlarmActionTrigger -Confirm:$false
Get-AlarmDefinition -Name $HighPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Yellow" -EndStatus "Red" -Repeat
Get-AlarmDefinition -Name $HighPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Red" -EndStatus "Yellow"
Get-AlarmDefinition -Name $HighPriorityAlarm.name | Get-AlarmAction -ActionType SendEmail | New-AlarmActionTrigger -StartStatus "Yellow" -EndStatus "Green"
}
}

File downloads:

PowerCLI script to configure vCenter alarm email actions

Recommended alarm configurations for vSphere 5.5

Recommended alarm configurations for vSphere 6.0

Recommended alarm configurations for vSphere 6.5

These CSV files include the alarms for each version, what I’ve found with customer feedback so far as the best values for each one, a notes field that has any relevant info that may help you decide how to configure each one, and an IfUsed column for each one I’ve set to disabled if you want to enable it what I would recommend.

When to Run PowerCLI Script to Configure vCenter Alarm Email Actions

I designed the PowerCLI script to configure vCenter alarm email actions not just for initial configurations, but also to set any changes that are made.  That’s why the script removes any email alarm actions for Low, Medium, High, and Disabled.  If you wish for the script to not change an alarm’s configuration, leave the Priority column blank for the alarm.

This way, you will have a current documented configuration of alarms that you can simply update and run the script again.p

powercli

Document DRS Rules with PowerCLI

As a consultant, I find myself doing a lot of reconnaissance within customers’ vSphere environments.  Here’s how to document DRS Rules with PowerCLI.

DRS Rules – Why have them?

You can use DRS rules for numerous purposes.  Use them to provide better reliability for applications and services.   You can also use them to ensure licensing compliance, and for other pragmatic purposes.

Here’s a very quick set of hand rules for DRS rules:

  • Use VM anti-affinity DRS rules to ensure redundant VMs are not running on the same host within a cluster.  In these configurations, having only one of the VMs up keeps the service or application online.  Examples include cluster members, web farm members, domain controllers, DNS servers, etc.  (Note: for Microsoft clusters, don’t forget to include File Share Witnesses in the rule as well as the nodes!)
  • Use VM affinity DRS rules for VMs that in total comprise a service and/or application.  In these configurations, downtime for any single VM in the group causes the entire application or service to be inoperable.  Examples include a web front end server, an application middleware server, and database backend server.  Or perhaps an email fax server that depends upon an email server.
  • Use VM host affinity/anti-affinity should DRS rules to try to ensure a VM runs or doesn’t run on specific hosts, but it can violate the rule if required, such as possible preferred nodes are down.  An example would be for vCenter to run on a specific host in case the vCenter VM goes down.  You then likely know which host to log directly into to start it back up.  Otherwise, if that preferred node is down, the VM can run on another node.
  • Use VM to host affinity must DRS rules to ensure a VM will only run on specific VMs, even if that results in downtime if those hosts aren’t up.  Must rules generally should only be used for licensing compliance purposes, where the software vendor licenses the product on all possible potential physical nodes it can run on, not how many hosts it could be actively running on at any given point in time.

Document DRS Rules with PowerCLI – Rules

DRS rules are a little bit of a challenge.  Members are a multi-valued property with VM IDs, which isn’t particularly useful.  We need to work a little magic to translate VM IDs to VM names, and then join the multi-valued property to allow it to be exportable into CSVs, etc.

This can be accomplished using the Get-DrsRule cmdlet.

Get-DrsRule -Cluster ClusterName | Select Name, Enabled, Type, @{Name="VM"; Expression={ $iTemp = @(); $_.VMIds | % { $iTemp += (Get-VM -Id $_).Name }; [string]::Join(";", $iTemp) }}

Now you can tack on an export-csv or what not to it, and it’s readable with useful information us humans would understand.

Note, there is also a specific cmdlet to get DRS to host rules only if that’s what you’re looking for : Get-DrsVMHostRule, but the above gets all DRS rules.

Document DRS Rules with PowerCLI – Groups

DRS rules can also have groups, so it’s important that they’re documented as well.  Members are a multi-valued property, but that’s the only challenge here.  We just need to use a join method to make it readable.

This can be accomplished using the Get-DrsClusterGroup cmdlet.

Get-DrsClusterGroup -Cluster ClusterName | select Name, Cluster, GroupType, @{Name="Member:"; Expression={[string]::Join(";", $_.Member)}}

Now you can tack on an export-csv or what not to it.