I’ve recently been working with a  few different organizations on server automation projects.  If you have been following the Microsoft automation space for the past couple of years you have noticed that there are two different overlapping automation engines that are included as part of System Center Orchestrator.  The two engines are System Center Orchestrator and Service Management Automation (SMA).  Recently Microsoft has also released Azure Automation which is the cloud based solution that mirrors capabilities of SMA.  So given that Microsoft now has three overlapping or dare I say competing automation solutions which organization is the right solution for your organization.  In order to answer that question let’s review a bit of history and some of the details of each product.

In 2002, Jeffrey Snover released the Monad Manifesto  where he described the future or automation inside of Windows.  If you haven’t read through that document it is amazing how many of the items that are described in that document are just now appearing inside of PowerShell.  PowerShell was really in its infancy up until the release of Windows Server 2012 and really came into its own in Windows Server 2012 R2.  If you notice there is a time gap there of 10 years, during that time gap the only real remote automation solution was through a company called Opalis.  Opalis had created graphical workflows that allowed administrators the ability to automate challenging IT workflows through a simple graphical user interface.  Microsoft saw the value in this technology and in 2009 purchased Opalis in order to bring that runbook automation capabilities to the Windows platform.  Opalis limped along inside of Microsoft until it was finally integrated as a full fledged product as System Center 2012 Orchestrator.  Orchestrator was/is a great tool for automating complex workflows through simple runbooks that can be created with a simple drag and drop GUI.  By this time though Microsoft had made a clear shift towards PowerShell as the primary management engine in Windows and PowerShell was adopted as a Common Core Criteria for shipping a product on Windows Server.  If you wanted to ship your product, you needed to have PowerShell integration with your product.  Since all of this automation was accomplished with PowerShell, Orchestrator admins often found themselves creating entire runbooks that contained little more than several Run .NET Scripts that called PowerShell scripts to perform the actions needed to automate their solutions.  When Microsoft release System Center 2012 R2 Orchestrator they included Service Management Automation (SMA) on the same installation files as Orchestrator.  SMA is an automation engine that is build entirely off of PowerShell workflows.  Now the automation engine and runbooks could be created entirely out of PowerShell.  The only issue with using SMA is that by doing so an administrator had to give up the graphical authoring capabilities completely and opt to write all of their automation directly with PowerShell workflow code.  Recently, Microsoft released Azure automation as a cloud based automation engine that is also based on PowerShell workflow.  With Azure automation, runbooks could now be authored either directly with PowerShell or through a simple graphical interface.  In order to allow on prem activities, Microsoft introduced Hybrid Worker Roles with Azure automation that allow you to interact with on prem servers as well as cloud based services.  You can even purchase blocks of automation time in Azure automation through the Operations Management Suite

So that takes us to the present.  As an IT organization you now have the option of using Orchestrator, SMA, or Azure automation so which should you use.  As with most things in IT, it really depends on what you are trying to accomplish.

System Center Orchestrator

Orchestrator is still a great tool for automation and authoring runbooks is still very easy within the Runbook Designer.  Orchestrator is also not going away any time soon.  In fact, Microsoft is releasing System Center Orchestrator 2016 which means that Orchestrator will still be supported for at least 10 more years.  Orchestrator still has deep integration through integration packs with all of the Microsoft System Center technologies and also includes integration packs for several server components.  There are however some features that are missing from Orchestrator.  They include:

• 64 bit support for Orchestrator and for 64 bit PowerShell
• Native support for PowerShell 3.0/4.0/5.0
• Automatic distribution of jobs across runbook workers
• Checkpoint support within runbooks
• Full command line administration
• Auditing
• Lack of 3rd Party integration packs
• Ability to work on draft runbooks while still having production jobs running
• Running many actions in parallel

Unfortunately these items are not addressed in System Center Orchestrator 2016.

SMA

SMA is going to be released again as an on prem solution with Orchestrator 2016.  Much of the advantages and disadvantages of SMA will carry forward in the near future.  The advantages of SMA include:

• Native PowerShell 3.0/4.0/5.0 support
• Built in top of PowerShell workflow
• Built in checkpoints and restarts
• Ability to run activities in parallel
• Ability to integrate with most PowerShell modules provided by Microsoft or 3rd parties
• Can edit a runbook while allowing jobs to function

Some of the drawbacks to SMA include:

• No graphical user interface.  Relies on Azure Pack for graphical management
• No graphical authoring capabilities

Azure Automation

Azure automation is a great cloud based solution that provides many of the advantages of both Orchestrator and SMA.  Microsoft is making large investments in Azure Automation and since it is a cloud based solution, expect rapid improvements to the capabilities.  Some of the advantages of Azure Automation include:

• Graphical Management through Azure
• Either PowerShell authoring or Graphical authoring
• All additional advantages of SMA

Some of the drawbacks to Azure Automation:

• Currently only a cloud based solution though the cost is very inexpensive
• Limited out of the box support for PowerShell modules so many modules have to be loaded manually
• Graphical authoring is still not quite as robust as Orchestrator

Bottom Line

So given the pros and cons of each of the solutions which one is best for your organization?  If your organization currently does not have in depth PowerShell knowledge it might be wise to start with Orchestrator and integrate either SMA or Azure automation for activities where there is not a built in Integration Pack.  If you are finding yourself writing a lot of PowerShell scripts for your runbooks then definitely look into using SMA or Azure Automation.  If you cannot use public cloud services due to regulatory compliance then consider SMA however if nothing is blocking you from using cloud services Azure Automation should be used wherever possible.