Advice to the reader
This posting is part of a series of articles. In order to get a full grasp of it, I strongly advise you to start at the beginning of it.
Other postings in the same series:
01 – Kickoff
02 – SCCM
04 – SCDPM
05 – SCSM
06 – SCVMM
07 – SCOM
In the third posting of this series I’ll write about how System Center Orchestrator (SCOrch) relate to Microsoft’s Mobile First – Cloud First strategy. And as stated in the end of the second posting of this series, SCOrch isn’t in a good shape at all…
SCOrch
Sure, there is SCOrch 2016. And YES, it has the Mainstream Support End Date set on the 11th of January 2022, just like the whole SC 2016 stack. Also the Integration Packs for SCOrch 2016 are available for download. So on the outside all seems to be just fine. SCOrch is alive and kicking!
But wait! Hold your horses! Because here the earlier mentioned iceberg comes into play. Time to take a look what’s UNDER the water line, outside the regular view…
Yikes! x86 (32-bit) ONLY…
The day 64-bit workloads were special are long gone. All important Microsoft products and services are 64-bit based. Meaning, x86 (32-bits) isn’t default anymore. None the less, SCOrch 2016 is still x86 based and there aren’t any plans at Microsoft to rewrite the code to x64.
Therefore SCOrch native PowerShell (PS) execution runs in a V2.0, 32-bits PowerShell session, causing all kinds of issues. Sure, there are workarounds for it, but still they are workarounds.
Even though SCOrch packs some serious power, the x86 limitation is something to reckon with.
The ‘Engine’ & the ‘Graphical Editor’
These are crucial parts of any automation tool, SCOrch included:
- The ‘Engine’ enables the automation tooling to ‘translate’ the defined activities as stated in the runbook (eg. running a script, stopping a service, creating a folder, etc etc). SCOrch runs it’s own runbook engine, using it’s own proprietary runbook format.
- The ‘Graphical Editor’ allows for a ‘drag & drop’ experience when creating new runbooks/workflows (Eg: When the printer spooler service stops, restart it. Wait 2 minutes, check the state of the spooler service. When started, close the related Alert. When still not running create a ticket and escalate it to right tiers).
SCOrch brought this ‘drag & drop’ experience to a whole new level because it doesn’t require any scripting. Just drag & drop the required activities – from the loaded integration packs - to your ‘canvas’, connect them as required, apply filters/criteria and so on and be ‘done’ with it. Of course, good Runbook authoring is far more complicated, all I am trying to do here to share the basics of how it’s done. The gest of this is to say that even without any scripting skills, one can build advanced runbooks with SCOrch.
However, things have moved on. In today’s world many times the on-premise/data center based workloads are connected to the cloud. Whether we’re talking Azure IaaS/PaaS/SaaS or Office 365 for instance here. Whenever automating management of cloud based workloads, PS is a hard requirement, whether you like it or not.
The challenges
And here SCOrch has two serious issues/flaws:
- By default SCOrch PS execution runs in 32-bits PowerShell session, missing out many advanced PS features introduced in the x64 editions;
- By default the SCOrch engine isn’t PS based.
As such, there will always be a translation from the native SCOrch engine to PS. On top of it, there will be ALSO a translation form x86 to x64 and vice versa…
And as it goes with every translation, there will be a performance penalty. Even worse, the whole chain (SCOrch > AA/SMA > targets to hit with a runbook/workflow) becomes longer and therefore more vulnerable to (human) errors. So why not cut out the ‘middle man’ or in this particular case, SCOrch and start directly with PS? Because SMA and AA both use an identical runbook format based on Windows PowerShell Workflow, x64 based.
No more translation, neither from a proprietary runbook format, nor from x86 PS execution to x64. Nice!
Port SCOrch to x64 and native PS?
For sure. Microsoft could solve it all by rewriting SCOrch in such a way that it would run natively x64 and use the identical runbook format based on Windows PowerShell Workflow. However, Microsoft isn’t going to do that.
Already in 2014(!) Microsoft was pretty clear about the ‘future’ of SCOrch. In 2015 Microsoft published the SCOrch Migration Toolkit (still in beta?!). Around the same date Microsoft also released the SCOrch Integration Modules, being converted SCOrch Integration Packs, ready for import in AA. In 2016 Microsoft published a blog posting about how to use the previously mentioned tools and modules.
And that’s about all the efforts Microsoft aimed at SCOrch specifically… Instead Microsoft tries to push you to AA or (in some cases) SMA, when using WAP. For most people however, AA is the future (at least Microsoft hopes).
Verdict for SCOrch and it’s future
Yes. SCOrch 2016 is available. And it still packs a lot of power. BUT at the end of the day, SCOrch 2016 is dead in the water. Not too many efforts, budget nor resources are allocated to it. Only the bare minimum. Sure it has gotten the 2016 boiler plate AND the related Integration Packs (IPs) are updated to support the 2016 Windows Server workloads. But that’s it.
Nothing new coming out of that door. End of the line for SCOrch 2016 after the 11th of January 2022. Even the recent posting of Microsoft about the new delivery model for the System Center stack is pretty clear about SCOrch: Not a single word about it. Which is a statement on it self.
What to do?
When not using SCOrch, but using other System Center 2016 components of the stack: Think twice. Sure, you already got the licenses for it. But please keep in mind that every effort and investment for SCOrch must be doubled: One time to get it into SCOrch and the second time to get it out to another automation tooling, no matter what you choose for.
When using SCOrch already, it’s time to look for alternatives. Also look OUTSIDE the Microsoft boundaries please. POC the alternatives and look at the possibilities to export the SCOrch based runbooks to your alternative choices. Also test the connectivity with the cloud and on-premise/datacenter based workloads. And TEST and EXPERIENCE how the graphical editors are functioning, how easy they are to operate and last but not least, how easy it is to catch errors and act upon them. AA still has some challenges to address, like the easiness of operation and capturing errors…
Coming up next
In the fourth posting of this series I’ll write about SCDPM (System Center Data Protection Manager). See you all next time.
No comments:
Post a Comment