SCOM is a great product, but sometimes I would have liked that they spent a bit more time on implementing the silverlight dashboards, especially the performance one.
The reason? The usage of the hardcoded GUIDs to populate the performance counters.
Let’s back up a bit, before going on, and talk a bit about the usage scenario. Creating these dashboards using the GUI is fine, though if you need to create a lot of the same type of dashboards, just with different targets. The GUI route can become a big timesink. Also one usually want to keep these types of dashboards in an unsealed management pack so one can do adjustments as necessary on the fly without having to go the way through Visual Studio to seal the MP anew each time a change is needed. VS still has some complexity tied to it and not everybody wants to invest time into learning this tool.
I really like this script for sending SMS using SCOM. Though it has some bugs in it’s current form. I also do not have a Twilio account. That is why I decided to rewrite some of the logic to use generic HTTP SMS gateways. Currently it is set up for using pswincom sms gateway, though this can easily be changed to some other service. Though you will need to find out how to construct the URL for that service and change the code in the CreateSMSurl function to match.The PSWinCom details are here.
I really like this Wei Out there template, and also this that gives a overview of the Send Queue Size of the SCOM agent. Though I’m lazy and do not like that I have to click the performance counter column so it will sort by it. That is why I have added some code so it will, though you will lose the state column to the sorting logic. But I’m fine with that. I also added the option to only show the Top N highest values.
Here is the changed code:View the code on Gist.
I recently did some work on publishing internal legacy applications using WAP and ADFS for pre-authentication. Wrapping of the production part of these components I wanted to get full visibility into how they performed over time. To do this I added in SCOM management packs for both products. As monitoring kicked in I started seeing that the health of the overall ADFS farm always defaulted to a warning state. Delving a bit deeper into why, I found that it was the “MEX Endpoint Is Unreachable”-monitor that was keeping the farm in this state.
I always try not to have to do too much repeat work, so when I have some extra time I like to make some stuff easier. This time I threw together a quick and easy way of adding the needed firewall openings to servers for SCOM Agent push installs.
One little note; the commands used here are only present on 2012 R2 with PS 4.0 and newer servers.
$SCOMmgmtServers = @("IPscommgmtserver1","IPscommgmtserver2")
New-NetFirewallRule -DisplayName "SCOM Agent TCP" -Direction Inbound –Protocol TCP –LocalPort "5723" -Action allow -RemoteAddress $SCOMmgmtServers
New-NetFirewallRule -DisplayName "SCOM Agent Push Install TCP" -Direction Inbound –Protocol TCP –LocalPort @("135","139","445") -Action allow -RemoteAddress $SCOMmgmtServers
New-NetFirewallRule -DisplayName "SCOM Agent Push Install UDP" -Direction Inbound –Protocol UDP –LocalPort @("137","138") -Action allow -RemoteAddress $SCOMmgmtServers
New-NetFirewallRule -DisplayName "SCOM Agent Push Install RPC" -Direction Inbound -Program "%SystemRoot%\system32\svchost.exe" -RemoteAddress $SCOMmgmtServers -Protocol TCP -LocalPort RPC