During that session (about 34mins) we were shown a very brief glance of the new azure portal with Azure Automation present inside it with the promise that it would be developed in Azure first and then brought back on premise.
Azure Automation and it's on-premise father SMA (SMA came first!) are both already available and in use, but both of these were basically management portals for importing, managing and scheduling PowerShell Workflow scripts.
The biggest draw for Orchestrator, for me, was the GUI. This enabled non-Devs or IT Pros who weren't hard core to get to grips with designing graphical process workflow automations and the idea that we would be left with everyone having to dive into deep scripting to even get the simple tasks done was certainly daunting, especially as I see Orchestrator being regularly used in conjunction with the Service Desk teams where that skill is usually not present.
Well today, we see where Microsoft have been aiming to go with this.
From the new preview Azure Portal we can now access any existing Azure Automation accounts that were previously created, or create a new one.
The first new cool feature is Assets.
This now gives us the ability to centrally control and reuse within our Runbooks:
- Schedules - When Runbooks should run
- Modules - Ability to upload PowerShell modules for use within Runbooks
- Connections - Currently just to Azure but more will come
And now the thing that you've been waiting for... Graphical Editing!!
I'm going to be doing some deeper diving into this starting from now so watch out for more info.
However, the fun doesn't stop there!
From that TechEd Europe session, it was also mentioned that the approach would be one of consistency across Azure and On-premise, so expect these features to be coming with vNext of WAP and Orchestrator/SMA/Whatever name it ends up with.
We're also being treated to a new management layer for PowerShell Desired State Configuration.
You see this option when you choose an optional extension to add and configure when deploying a new VM into Azure.
Using Azure Automation you will be able to author new DSC resources (and import existing) and use a cloud based Azure Automation DSC Pull Server which you target nodes (cloud and on-prem) will then use to get and report their configuration to.
Here comes the curve ball...
While some customers will undoubtedly require a fully On-Premise version, be it for secure isolated environments, regulation or whatever reason, with this announcement of enhanced Automation via the new Azure Portal also comes another very interesting scenario...
With these new features now comes the ability to utilise On-Premise Runbook Workers.
This allows for creation and management of automation via the Azure Portal and Azure Automation service, but to selectively choose to run some Runbooks On-Premise, negating the need to design scripts to reach back into our environments and also having to expose systems out to the wider world and instead use a server sat within our network boundary to execute the automation Runbook and simply report it's execution back to your Azure subscription.
This requires use of the newly announced Microsoft Operations Management Suite (More details here) and through adding the Automation Solution to allow configuration of an On-Premise Runbook Worker server.
Once you've added the Automation Solution pack and have the target server installed with a Microsoft Management Agent and connected to the service, it will be a simple case of running some PowerShell commands (e.g. Add-HybridRegistration, Add-HybridRunbookWorker) to enable it as a Hybrid worker for you to start using it.
I'll have some more posts soon running through setup etc.