I've been playing around with Slack a bit lately. I don't see us using it internally as a collaboration tool - we're an MS shop that's more likely to go Lync - but I have been using it as a way to get Nagios notifications to my phone. That works really well and means that I don't have to tie my personal phone to my work email so I can get notifications about important stuff but not random email.
I've also been doing a bit of custom monitoring with various PoSH scripts. Checking backups have ran, that shadow copies are working, that sort of thing. That got me thinking, it would be pretty cool to have those PoSH scripts also post to Slack if they come across something I should be aware of, right? And a great excuse to have a play with RESTful web services through PoSH into the bargain :)
Slack has an integration called Incoming Webhooks that can be used for custom integrations such as this. Long story short, you can send a JSON payload to Slack which ends up in a channel on your network. It's very easy to setup too!
I started at Christopher Maneu's post here where he describes how to post to slack using the Invoke-RestMethod cmdlet. Slack's Incoming Webhooks documentation has everything else you need to know to get this working.
Your finished script will look a little like the one below. You'll need to use your own Slack network name and token. I've also included a specified default icon to use with the post if you don't specify one with either the -IconEmoji or -IconURL parameters but that's optional. If you don't do that, the default icon you configure in Slack for the Incoming Webhooks integration on your network will be used instead. I've also used parameter sets to make sure that only the -IconEmoji or -IconURL options can be specified but not both. A very useful feature!
Enjoy :)
We were doing a bit of housekeeping today. We've already moved our vSphere Centre from 5.0 to 5.5 and it's time to update the hosts. That should be straightforward; each host should be put into maintenance mode while ESXi is updated then the host is brought back into the cluster. One possible problem though, is VM CD Drives.
I'm terrible for not managing VM CD Drives properly. I have an annoying habit of uploading an ISO to a host's local storage and making it available to a VM. Or, I'll stick a CD in the host and pass it through to a VM. These are both really bad things to do in VMware. When a VM has a CD Drive attached to an ISO stored locally on the host or to the host CD device then it cannot be vmotioned. That means when the host goes into maintenance mode, you're going to have a problem. The best thing to do is to check the CD drives first. The easiest way to do it is in PowerShell with PowerCLI.
VMware PowerCLI is, according to VMware, "a Windows Powershell interface to the VMware vSphere and vCloud APIs". This means we can perform operations from within PowerShell that we would normally do from the vSphere GUI. Sometimes it's quicker and simpler to use the GUI but we can automate from PowerShell. When dealing with a lot of objects, that can be a huge time saver.
Back to my original problem - finding any VMs that have a CD Drive connected. Once you have PowerCLI running and you've connected to a vCenter (Connect-VIServer servername) We can start with:
Get-Command *CD*
Sensible place to start. This will show us all commands that include the term CD. This actually returns 39 commands, many of which are not relevant, but one looks very promising. Get-CDDrive.
That's what I'm looking for. The syntax shows me I can give it a VM name and find CD drives on that VM.
Nothing attached here. If I pipe that command through Format-List, I can see all attributes that are available to me.
I'm interested in the Parent, which is the name of the VM that the CD Drive is connected to and the ConnectionState of the CD Drive. Using both those parameters I can see which VM I have and the state of any CD Drive attached. It would be really useful to see that for all VMs at once though.
Get-VM without any parameters returns an array of objects, each object being a VM in your vCenter.
Trust me, there are VMs under there. That means, I can pipe those results to our earlier Get-CDDrive command and add a little formatting to select the Parent and ConnectedStat properties to get a nice list!
After all that, I was worrying about nothing, everything showing as NotConnected. Still, at least now I can upgrade with confidence!
