The journey of origin of SCOM as a software goes way back to around 2000, when it was known as MOM – Microsoft Operations Manager. Later it was made a part of the System Center Suite of tools and changed its name to SCOM (System Center Operation Manager) as we know it today. The latest version of SCOM as of today is SCOM 2016. This list gives a complete summary of all the SCOM versions.
We’re not really gonna discuss the whole history of what happened when and how, the two versions we’re mostly interested in this article are the SCOM 2007 and SCOM 2012. Why? Because there is a major twist in the way SCOM 12 works over SCOM 07.
So here’s the thing. In SCOM 07 infrastructure, you had a thing called the Root Management Server or simply the RMS (we’ll discuss about this in the next blog), which was the focal point for everything. The first Management Server (MS) you installed was by default the RMS. Everything was ultimately connected to this one RMS – other subordinate Management Servers (MS), the databases, everything. So there was, as you can imagine a very high degree of dependency AND strain on this one server. Moreover, there could be exactly only one RMS. Now, I’m sure you’ve guessed what the problem with this design is. If (god forbid), your RMS went offline for whatever reason, all your monitoring dropped off the ledge. So no monitoring means no alerts. No alerts mean no notifications. No notifications means oblivious admins and oblivious admins means – you guessed it right – disaster!
Then in the 2012 version of SCOM release, Microsoft introduced a new concept, that (pretty much) got rid of an old one. To remove this absurd dependency on a single RMS server, they came with a rather excellent idea of a Resource Pool. Microsoft said, “Let there be no RMS!” and the magic happened. Now, there was no single RMS and subordinate MS’, rather all the MS’ were now peers. So, automatically all the MS in the Resource Pool were distributing the load among them, and take over the other MS’s load if one goes off. And so there was no single point of failure (unless you have only one MS in your infrastructure, of course), and we were assured that the monitoring would not stop even if one of the Management Servers goes down.
However, this does not mean that there is no RMS in SCOM 12 🙂 The difference now is that it is now limited only as an “additional role” that one of the existing (by default the first) MS has to bear. This is to maintain the backwards compatibility for some of the workflows from older SCOM 07 days. We will discuss this in greater detail later when we’ll have a dedicated blog on Resource Pools and how they work (yup, its that interesting!) 🙂
This isn’t the only change that was made in SCOM 12 though. In SCOM 12 they also introduced some fancy – and extremely useful – views and dashboards. You can now view and analyze the trends of the stuff you’re monitoring with your SCOM, using charts and graphs and all that in a visually pleasing manner.
You can go through all the links provided in this community thread here to know more about the differences :
OK then, that’s it for now, we’ll discuss the different SCOM versions in the next one. Until then, keep reading!
PS : Credits to all wherever due 🙂