Tuesday, February 23, 2016

Microsoft SystemCenter 2012 R2: A Sour Suite

Microsoft SystemCenter 2012 R2 is a collection of systems management applications that aim to facilitate the administration of a Windows-centric technology infrastructure. Whether you're attempting to patch one thousand Windows Servers, or monitor the health of a dozen SQL servers, or just do some basic VM management on Hyper-V hosts, SystemCenter is a reasonable place to get these tasks done. At least, you'd think.

The truth is that the SystemCenter suite is quite sour; using the applications as standalone products is acceptable, but when you switch between several components during your work, you'll immediately get the feeling that Microsoft just blended a bunch of in-house tools with acquired products into a "suite" and rushed it out of the door. And I'm not just referring to the mismatched aesthetics of the thing. In some cases, what you would expect to be core functionality, like interoperability between SystemCenter components, is missing.

Example: Patch Management using SCCM and SCOM

First, a primer for those who are fortunate enough to not use SystemCenter on a regular basis.

  • SCCM - SystemCenter Configuration Manager. Think of this as a sophisticated software management tool. I'm not being sarcastic, for once. SCCM is decent.
  • SCOM - SystemCenter Operations Manager. Think of this as a sophisticated monitoring tool, minus the sophistication.
  • SCORCH - SystemCenter Orchestrator. It's okay to like this one, because it's functionally identical to pretty much every other orchestration tool that's on the market. And it's got a killer nickname to boot.
  • POSH - PowerShell. Wait, PowerShell isn't part of the SystemCenter suite, you say? Technically, you're right. But MSFT was smart to build modules for most of the SystemCenter components that lets a PowerShell-savvy engineer string cmdlets together to automate routine SystemCenter tasks. This is important, for reasons that will be totes obvs in just a minute.

So let's say that you've got 100 Windows Server that you're managing, which means you are responsible for the availability, performance, and security of these systems. Your Microsoft account team was slick enough to bundle SystemCenter into your EA, so you've got access to SCOM and SCCM. You enable SCOM monitoring for your servers, and you validate that you're getting health and performance data.

When it's time to roll out patches, you decide to lean on SCCM. You create a few collections, assign them to groups of servers, and you schedule the deployment.

Before you deploy the patches, however, you have a great idea: I'll go back into SCOM and enable Maintenance Mode  (hereafter MM because lazy) for all of my servers. That way, as they are being patched and rebooted, I won't be flooded with alerts from SCOM. And you can do that.

But you're going to run into a problem. Because you're a good engineer, and you like to automate stuff, and you like to work smart, and you like to use the tools you have to the best of their ability. So you think to yourself, "I bet I can configure SCCM in such a way as to put the servers into MM as part of the patch deployment." I mean, of course you think this. You'd be silly not to. Because you're working with two components of a single "suite." And after years of experience in IT, you know that suite means a collection of tools that are tightly integrated in order to manage the full spectrum of tasks.

The problem is that you can't do what you want to do in SystemCenter 2012R2.

You can't have SCCM put a server in MM, even though you will certainly fall for the trap MSFT has set for you:


The problem here is that these options, specifically the first, are described quite literally. In your haste, you may think that selecting the first option (Disable Operations Manager alerts while software updates run) will effectively put the servers in MM before patching. But no. This option will only prevent SCOM alerts while the updates are running. We all know that patch installations require reboots, and it's these reboots that will still cause SCOM to generate an alarm, even with this option selected.

Microsoft should have included an option to put the servers in MM while the patches are deployed. I mean, remember that SystemCenter is a suite. Its components should seamlessly interoperate. Is that a word? It should be.

POSH: Gluing Together SystemCenter's Components

PowerShell is amazing, for myriad reasons. Among these reasons: it's easy enough for anyone to learn, even people who are too lazy to learn Perl (and admit it: you've got to be pretty lazy to not know Perl).

Because there are PowerShell modules for SCCM and SCOM, you can pull together some one liners to do what the GUIs in these products can't: quickly and easily place groups of servers into MM for a duration of your choosing. The syntax of the command.... isn't the point of this post. I mean, if you really want to know, just google it. A dozen other posts can explain that for you. But you don't need that info; you're smart. Just do what I do and tab-complete your way to PowerShell god mode.

The point of this post is to highlight the obvious shortfall of the SystemCenter 2012 product: it's a suite of applications with half-assed interoperability and integrations that prevent you from working smartly and efficiently. And it depends heavily on PowerShell to glue these disjointed pieces together. Sure, you can use SCORCH as a band-aid, but you shouldn't need to.

Hope For The Future: SystemCenter 2016

"The next version will be better." ~every vendor, every release
2012R2 is a bit long in the tooth, and its replacement is preparing for its debut. With luck, Microsoft has addressed the core issue here: unify these components into a true suite of components that work well without any POSH magic. Time will tell.

And maybe this post is really just a bit of catharsis after wrestling with this stupid software for a few months now.

Tuesday, February 9, 2016

Temporary Maintenance

Pretty sure that the change manager who approved a "temporary maintenance" that collides with the VMware event today has been sacked.


Mastodon