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.
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.
One of the things I work with in my role as a product manager for Operations Management Suite (OMS) is the automation part of the suite. In this case, it means Azure Automation that can do a lot for us in terms of automating our recurring tasks. This post will be the first post about what you can do with Desired State Configuration (DSC) as a part of Azure Automation.
Before we get started there are some things worth knowing. As a part of OMS, the licensing for DSC is based on per-node and the listing price is at $10 per node/month. This means that each server you want to configure using DSC is assigned this license.
Before we get started there is one prerequisite you need to take care of; the latest version of WMF 5 (Windows Management Framework) needs to be installed on the server about to be configured as a DSC node. This makes is possible for the node to communicate with Azure Automation. You can find WMF 5 here. This isn´t necessary if you’re running Windows Server 2016 as I will be doing for this post.
The first thing we need to do is to create a file stating what to communicate with and what to do. This is called a MOF file and is what makes is possible to retrieve configuration, but also to register the server as a node to Azure Automation DSC.
In about a week from now (April 12th), my employer Approved is running a webcast together with OpsLogix about our analytics solution for SCOM.
You will get to know more about “IT Service Analytics” and what it can do for you and your organization. I have previously mentioned “IT Service Analytics” in my blog, and if you want to know more right away you can do so here at SCOM Reporting made easy and intuitive and here at Creating dynamic distributed applications in SCOM.
Also check out Kevin Greene´s post here; Scandinavian SCOM solutions with global reach.
“IT Service Analytics is a free plug ´n play business intelligence and process support platform for Microsoft System Center. IT Service Analytics enables your IT organization(s) to make qualified decisions based on intelligent and accurate information gathered throughout your IT landscape.”
A while back I wrote a post where I went through the basics and how to get started with the new feature Service Map, which is a part of OMS nowadays. Read the post here. That post only showed how to get started and what kind of information you will get from the solution, but it didn´t say anything about troubleshooting. And at last, it did just explain how to get started with your Windows servers (or clients for that matter).
Today I will go through how to get up and running with Linux servers as well, as well as some troubleshooting.
When considering the Service Map agent, the following Windows operating systems are supported.
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows 10
- Windows 8.1
- Windows 8
- Windows 7
So the time has come for the second update rollup of this generation of System Center 2016 Operations Manager to be released. Microsoft made it available today through the update catalog for us to download it. I have been waiting for this update for a while now since Update Rollup 2 for System Center 2016 has been partially release over the past few weeks.
The update rollup solves the following issues
- When you use the Unix Process Monitoring Template wizard (adding a new template) to monitor processes on UNIX servers, the monitored data is not inserted into the database because of the following failure:
Log Name: Operations Manager
Source: Health Service Modules
Event ID: 10801
Task Category: None
Description: Discovery data couldn’t be inserted to the database. This could have happened because of one of the following reasons:
– Discovery data is stale. The discovery data is generated by an MP recently deleted.
– Database connectivity problems or database running out of space.
– Discovery data received is not valid.
For the past two years or so I have been talking a lot about how to monitor business services, and most of the time I have done this with Savision Live Maps as a great solution for this. But what about those that haven´t invested in Live Maps? Are they left out of this great way of monitoring? The short answer to this question is no.
When using Live Maps to monitor the services we´re using Distributed Applications which is a big part of SCOM and has been for a long time now. A while ago a colleague of mine, Mats Augustsson came up with a brilliant idea of how to make dynamic Distributed Applications (DA´s) a lot easier (and better). Often when creating DA´s you´re pointing out single objects to include in the service which of course is a great way of doing it, but it doesn´t make it easy to maintain.
Do you have questions about SCOM 2016? So does every other SCOM user. Luckily, Savision will be hosting a session featuring great experts that are prepared to answer all the questions you have about SCOM 2016. You can’t miss Savision’s upcoming session entitled: ‘Passport to SCOM 2016’.