Thursday, November 24, 2016

But seriously...someone explain Management Packs to me

1:21 PM Posted by Adam Dzak No comments


If you're new to the Microsoft System Center realm (and as I often joke) I have but two simple words for you:

Buckle up

When you're getting started in SCOM or SCSM you will very quickly run into the concept of management packs. Regardless of how little or much experience in you have in IT, if you've never used System Center then you've probably never had to come around to this concept of a management pack. As it was first explained to me...

Management packs store customizations that extend the core platform

And while it is most certainly a factual description, there isn't really anything tangible about that statement. I would argue that's the kind of statement that you come to understand with experience and less of a reasonable explanation to any newcomer of the platforms. Since there isn't any use in making you feel like an outsider, let's break down the roles of SCOM/SCSM first which may help you to come to understand what these things are and the architectural reasoning behind them.


SCOM/SCSM really can't do all that much out of the box...
The opening to this may come as a bit of a shock to some but like any new tool in an IT environment their is a degree of mandatory required configuration.

So let's start with possibly the most cliche of analogies - if you were building a house, you'd need to pour the foundation and get basic infrastructure up. After you have the core structure setup, you're free to add whatever you want onto it. Hardwood floors, solar panel roof, etc. The point here is that you probably intuitively understand their is a clear separation between the core house/infrastructure that was built and all of the amenities you choose to place inside of it.

It's with this said SCOM/SCSM are no different in that they are both core pieces of infrastructure and don't really provide much measureable value until you start customizing them to your particular needs. This is where the idea of Management Packs come in.


"Well the product doesn't do this natively. It could, but..."
So let's go through a brief exercise and we'll pretend you, the reader, are Microsoft. I mean, you are all of Microsoft. The all powerful Zoltar..err Microsoft. You need to create a piece of software that any customer could use and tailor to their needs but one that you could still upgrade, patch, etc. at whim without disrupting A SINGLE ONE of their customizations. How would you achieve this?

Again, returning to our house analogy - Microsoft has constructed the houses of SCOM and SCSM. But they've left it up to you to design, customize, and tailor what's inside of it. What's more, the only thing you can't do is touch the core infrastructure. You can build off of it, you can copy the work and built duplicates inside but you cannot touch the core infrastructure. You could even hire contractors (vendors) to do some of this improvement for you. Enough analogy, let's get practical with examples of two such customizations.


A Service Manager example...

Show me a view of all Incidents, that are in an Active status, created in the last 4 days.

While a perfectly reasonable view you may want to see of Incidents, is it a view that all customers who deploy SCSM want? Wouldn't it be easier to leave this kind of custom views to customers? Does it not make more sense to leave these kind of things to "organizational processes" and less "enterprise standards" ?

So if Microsoft won't roll this out of box for you, it makes sense to leave this kind of customization up to you. How could this be done? With a custom, unsealed, management pack.

Create an MP in SCSM, store all of your custom views per your needs inside of it. Problem solved.


An Operations Manager example...

I need to alert on a group of network devices, that are switches, whose location is data center 12

As it would stand to reason, no two customers are alike, and certainly their naming standards would vary dramatically. Your network engineers more than likely (or hopefully) have written the location attribute of network devices onto switches, routers, etc in your environment. You load all of these network devices into SCOM, but you want to alert now on a minority of them. How could this be done? WIth a custom, unsealed, management pack.

Create an MP in SCOM, create a Group in the Authoring pane, and create a dynamic membership rule that says something to the effect of All Network Devices, that are of class Switch, whose Location contains the words ''data center 12". Problem solved


Alright, I'm following you so far. Those are clearly customizations unique to me the customer. But those seem simple. What about MPs that change/alter/enhance functionality?


3rd parties, vendors, and the open source community...
In the above two examples I'm really addressing some very, very, very basic customizations to the platform. I would argue they are foundational configurations that everyone in the platforms will inevitably perform but do not address MPs of true function. So let's turn to SCOM for the next example.

Out of the box, SCOM comes with some management packs for monitoring basic Windows concepts. But if you want to monitor SQL specific concepts, you head over to SCOM, you request to download MPs from the catalog, search for SQL, and import those MPs. BOOM! You can monitor SQL.

Well I'd hope so! SQL is a Microsoft product. Exchange, IIS, these also seem all too obvious. What about my Cisco UCS chassis? What about monitoring Certificates in my environment that are about to expire?

While some of these MPs to monitor/discover things in your environment are a bit obvious and an assumed fact given they are Microsoft technologies what about the other stuff? This is where 3rd parties, vendors, and the open source community comes into play. So let's talk about those two aforementioned examples.

Want to monitor a Cisco UCS chassis? It isn't a Microsoft technology so the chances of Microsoft having an MP for this are highly non-existent. But Cisco, the manufacturer of said product does in fact provide an MP for SCOM to monitor their equipment. AWESOMETOWN!

Certificates expiring in your environment? The Certificate Authority MP provided by Microsoft really only tells you about health of your CAs. But it does almost nothing in the way of telling you about individual certificates. But with a little searching - clearly someone/a group of people were frustrated at this lack of functionality so they custom authored and made a management pack available to perform this very task. MOST EXCELLENT!

Turning back to Service Manager, wouldn't it be great as a CMDB to sync things like Projects into it? Fret not, because vendors have got you covered. What isn't made available by Microsoft, 3rd party products, or the open source community - vendors are ready to develop and extend the core functionality of the products to make them infinitely more flexible. But it goes without saying, for a price.

But what if no one in the community, 3rd party, or vendor makes something that is highly unique to organization? Good news - you can author your own MPs!

  • Alter the SCSM Incident form so the Description field automatically expands
  • Build a custom SCOM Windows Server class based off of the Microsoft one to monitor an application unique to your organization
  • Extend the SCSM Service Request class to feature true/false values to use in all of your Request Offerings (bool01, bool02, bool03)
  • Network engineer? Get friendly with XML and build a custom SCOM network monitoring MP to get even more data than what native SCOM provides.

And again - management packs are all done in the name of making both products highly modular, highly customizable, and allowing Microsoft to patch core infrastructure without disrupting your/3rd party customizations. Well ok, there was that one time with that UR9 for SCSM...


So what gives with this lock icon on some MPs but not others? Or rather, what is with this concept of sealed vs. unsealed management packs?


When we talk about the concept of sealed (lock icon) vs. unsealed (no lock icon), what we're talking about is along the lines of permissions with respect to that specific MP. Hrm...alright let me try again:

Unsealed Management Pack (no lock icon): An unsealed MP is one that customers create and modify somewhat regularly. They could contain things like SCSM Incident templates unique to the org, they contain custom alert groups for SCOM per devices in their environment. The point is they are custom, can be modified directly within the SCOM/SCSM console or via export and editing their XML.

Sealed Management Pack (lock icon): A sealed MP is one that authors (3rd parties or even customers) create to help further define and or extend the platform. Let's look at SCOM, there is a sealed Windows Server MP written by Microsoft. To prevent customers from intentionally or accidentally modifying it, the MP has been signed (sealed with a secret key generated and held unto Microsoft). This MP contains the matching/discovery criteria for finding Windows Server in an environment with respect to SCOM. It makes perfect sense they don't want customers to potentially modify this! Turn to SCSM, the Incident library contains all the element that define what an Incident is in SCSM - again, it makes perfect sense that Microsoft doesn't want customers modifying core pieces of infrastructure in these platforms. But what if you wanted to add a new Text Field to the Incident class/form? You can't touch their MP, but you can create your own sealed MP that extends the core class. Thus introducing the concept of MP dependency (i.e. for your MP to be imported, the core Incident class must exist first). This new MP you create would be signed/sealed with a secret key that you/your organization generates unique to your deployment.

Hrmm...I'm...I think I get the difference your making. But...well I'm just not sure.

So the stock Microsoft MP for Incidents contains all those fields/relationships and you want to introduce a new one like "Estimated Downtime". Per standard SCOM/SCSM MP architecture you are actively prevented from touching the Incident class because its in a sealed MP as defined by Microsoft. So how do you get this new thing? Using the SCSM Authoring tool you grab this MP that contains the stock Incident class and choose to Extend the Class. The Authoring tool stops you immediately and says "This is a sealed MP. I can't let you do this. Please pick a custom, unsealed MP to store you customization." So you create a brand new MP (*.xml). It now has a dependency on the core Incident class. In your new MP you say "Create Property" and name your new property something to the effect of "EstimatedDowntime."

You save the *.xml/MP file.
You seal this new MP (which converts the *.xml to *.mp)
You import this new sealed MP into SCSM

Wait a second. Why do I have to seal my new MP? I'm extending their core class with a custom thing of mine and you said I keep customizations in an unsealed MP...

Wait! Wait! Just think about this for a second! WAIT! Alright here's why - because YOU want to prevent unauthorized customizations from being made to YOUR new MP within YOUR organization/team of people. That and from a technical/Microsoft documentation perspective, class extensions should be stored in sealed MPs.

That...wow...So that means Microsoft plays by its own rules, 3rd parties play by those rules, and I in turn do as well. It's like this is some kind of standard!

So all of this means that every Incident in the entire SCSM system (new and old) gains this new text field of "EstimatedDowntime." Sooner or later when the MPSync job runs for SCSM and its Data Warehouse, you'll see your new field along side all the stock fields. Letting your customizations ride directly alongside Microsoft's but still fundamentally keeping them separate (from an MP perspective). This concept of extending the (Incident) class is fundamentally no different than extending your Active Directory schema.


In closing - this post isn't meant to be a "in defense of...", this isn't meant to be a "this is why these platforms are bad/good" - this is just simply the kind of plain English, non-technical thing that I wish existed when I was just getting started in System Center and it's one that I truly hope makes the whole concept behind management packs in SCOM and SCSM a bit more digestible.


So more confused? Less confused?
Leave a comment and I'll gladly expand or even update this post!

0 comments:

Post a Comment