Sometimes when working with SCOM, one hears that “SCOM is slow” or “the console is taking forever to do this and that”. I won’t be speculating about the reason to why it might be slow with this post though, this could be to many reasons. But let´s say that you move your databases from one SQL Server to another for example, wouldn’t it be great to be able to measure the time it takes to execute several PowerShell commands both before and after the change to see the difference?
That´s exactly what I will provide in this post. In the beginning of the summer I came in a discussion about how to measure the performance of SCOM. Okay, this won´t give a complete picture of how the console works with but it will provide you with some valuable data.
It consists of a PowerShell script that you need to run from a management server or from a server that has the Operations Console installed.
I have rewritten parts of the script to function with SCOM 1801 and newer as well. The script in this post is meant to run on SCOM 2016, but the steps you shall pursue are the same for 1801 and newer as well. You´ll find the correct download links further down in the blog post.
Are you a SCOM admin? Have you ever received a call or an e-mail from a user or technician asking you to put a server in maintenance mode in SCOM? You have? Then I think you have something in common with most SCOM admins out there. Today, I will share a solution letting you put a server into maintenance mode directly from the server itself.
This will help your technicians by letting them put the server into maintenance mode themselves, and it will save you from some phone calls.
The solution consists of a PowerShell script that will be placed on each server, and a shared folder containing some DLL files and the Operations Manager PowerShell module.
To get it running, you need to perform the following tasks;
- Create a share on one of the management servers
- Download the script to a server and edit the script
- Copy the DLL and PowerShell files needed to run the script
Back in January this year I wrote a post about how you can install the OMS agent using PowerShell. Now the time has come to include the Service Map agent in the equation as well since this is a feature that recently got Generally Available. You can find the original post about installing the OMS agent here. What´s new in this script is that I have added a section for downloading and installing the Service Map agent as well. Enough talking, let´s get to it!
A while back I got a question from a customer who wanted to update some of their alerts with the name of the server generating the alert. This can somewhat be found already by looking at the Path of the alert but this wasn´t good enough and they wanted to see just the server name, not the FQDN. My idea was to solve this using a PowerShell script which updated the alert with the server name and injecting it into Custom Field 1 of the alert.
To do this I am using the mentioned script along with the notification functions in SCOM. It´s really easy and fast to set up, see how it´s done below.
The first thing you need to do is to download the script from my TechNet Gallery here and place it in the same folder on all your servers that are part of the Notifications Resource Pool. To find out which servers are members of this resource pool, navigate to Administration and then Resource Pools.