A few weeks ago, we (Approved) held our annual event called SCOM Day in Gothenburg with about 80 attendees. This year we focused on hybrid monitoring using SCOM 2019/1901 and Azure. It was a full day of sessions where we had Thomas Maurer talking about Azure Stack, Martin Ehrnst who was talking about API integrations in SCOM. And lastly, we had Marcel Zehner who showed us how he monitors and interacts with his Tesla using Azure.
I also held a session along with my colleague Jonas Lenntun about the news in SCOM 2019 and 1901 where we focused on the parts that we think makes most sense and will most likely come to use for most users. The news was announced during Microsoft Ignite that took place in Orlando in September. But to those of you who didn’t attend any of these events, the news is still important to know about.
Lately I have been working a lot with monitoring VMware using SCOM for some of our largest customers and have gotten to think about this more and more. Even though cloud providers such as Amazon Web Services (AWS) and Microsoft Azure keeps on showing great numbers of growth (and profits for that matter), the absolute majority of customers IT are still on-prem. Since about ten years, virtualization has been about the coolest thing there is and the largest player in this area is still VMware.
Thinking about how large this area is and the importance for the organization, we need to monitor the VMware platform. Just as well as we need to keep track of what’s happening with our services, such as web shops or other business critical systems, we need to monitor the foundation it all relies on as well.
As I said in my last post, SCOM 1807 was released a few weeks back and I explained a little about the news and what they meant. This time it´s about showing them off to see how they work and what you can do with it. I have picked out some of the biggest news and played around with it to see how it works.
Removing the APM components from agents
The first new thing I will show is how you can control whether APM should be installed on an agent or not. As I mentioned this has been an issue where APM might cause an IIS application pool to crash, especially concerning SharePoint.
So, the summer is almost over and I´m back from my vacation. In other words, time to dig into things again. A couple of weeks ago Microsoft launched System Center 1807 as an update for the previous version, 1801. So let us dig into SCOM 1807.
When System Center 1801 was launched, it marked the start of the Semi-Annual Channel which means that a new version will be released twice a year. You can read more about the different release models in my blog post here.
So what´s new in SCOM 1807 then?
There are some nice additions in this new version as you can see below;
Configure APM component during agent install or repair
With this new possibility, we get to choose whether APM should be enabled for the agent or not. This was a problem with earlier agents (2016 and 1801) that could cause a crash with IIS Application Pools. This could also lead to a crashing SharePoint Central Administration application pool running .Net Framework 2.0. Now you can enable or disable APM for an agent either during installation or a repair of the agent.
Yesterday the news finally came, System Center 1801 has been relased. An with that, of course SCOM 1801.
This is the first release in the new Semi-Annual Channel which will release twice a year while the Long-Term Servicing Channel will be released at a much lower cadence.
But what´s the difference between these two tracks?
The Semi-Annual Channel
- You will receive the latest updates and features with releases twice a year
- Each build (1801,1807 etc.) is supported for 18 months, then you must move to a newer build
- New features added (all the new features will be put into this channel)
The Long-Term Servicing Channel
- You will receive new versions at a much slower pace (think SCOM 2012 and SCOM 2016 as an example)
- 5 years of mainstream support and 5 years of extended support
- Update Rollups only, mostly fixes and probably around zero new features added
Earlier this year, Microsoft announced a coming big change for the System Center suite. Instead of launching new versions every fourth or fifth year as before, they will now release continuous updates. This means they will launch two new versions per year to fasten up the release cycles and to really keep the products up to date.
This isn´t anything new, it´s been done for Configuration Manager ever since Windows 10 launched about two years ago. This schedule, called “semiannual channel release” will now also include the other parts of the System Center suite. Except for System Center, this goes for Windows Server as well. Besides from Windows Server 2016, you can now download and install Windows Server 1709 (YY/MM).
The first release I will be looking at is the one that in the end will be named 1801. Last week Microsoft launched a Technical Preview of System Center 1711, a preview that will later become 1801 which is meant to be released in January.
It´s time for the second post about load-balancing the SCOM Web Console that I started publishing last week in this two-post series. In the first post I showed how to setup the foundation which in this case consists of a two-node cluster, which I created using Network Load Balancing which is a feature of Windows Server. If you haven´t already read the first post, read it here before diving into this post.
What I will show in this post is how to configure the SCOM web console to allow for us to have Single Sign-On working.
A lot of companies that uses SCOM as a part of their processes wants to delegate control over certain areas to certain teams responsible for different services and areas. Instead of installing the Operations Console on all computers for all users, the web console (which is still in some ways depending on Silverlight) can be used for many cases to deliver information on an alert. Since the web console is used as a working tool, shouldn’t it be made properly available and easy to access to help people get to the alerts in a quick way?
The answer to that question if of course a “yeah, dude” and that´s what I will show in this series over two blog posts. In this first post I will go through how to set up a cluster to build the foundation for the console to be both fault tolerant and load-balanced.
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