Today at Ignite, Microsoft announced the next version of the portal for Azure Automation.
This portal is part of the new Azure Portal, and you can try it out right away!!
It has some great features in the interface and
It enables proper Hybrid Cloud Automation!
Execute Azure Automation runbook on-premise and trigger them from on-prem solutions!
Can I get a Woohoo!?
In this article, I will explain each feature in details
- New Graphical Runbook Designer interface (similar to the classic Orchestrator runbook designer)
- Hybrid Worker Role!!
- Web Hooks
- New portal design with better overview over runbooks, Assets etc.
You should be aware that the new portal is still in preview, and not yet complete.
In the coming time, I will post more about the advanced details and “How to’s” of each feature.
Here is a screenshot of the first screen of the new GUI:
In my opinion, the future looks bright for Azure Automation, of cause there might be things that need change (well it is a preview!)
but this is a big step in connecting the Public Azure Automation system with the existing servers on-premises!
Here is some more details on each feature:
Graphical Runbook Designer
The new designer lets you create and design runbook using a graphical interface.
It works a lot similar to the classic Orchestrator runbook designer, and lets you insert activities and connect them using links.
Since Azure Automation (and Service Management Automation) is based on PowerShell, the activities you drag in can either be
- Cmdlets
- Functions (from a PowerShell module)
- Script block using the “Workflow Script” activity
- Other Runbooks
While some might argue that writing PowerShell is faster than using a graphical designer, I think there is still a good use for a graphical view of runbooks/workflows.
For instance a process workflow might include several runbooks (new user, create mailbox, create home folder etc.), we could name them stages.
Each of these stages could be connected together using the graphical designer, to keep a new overview of the entire process.
Other advantages might include easier communication between the developer/scripter and the people who actually know how the process is done in the company.
Hybrid Workers
The second major addition is the Hybrid Worker Role.
A Hybrid worker is a very similar to a Runbook Worker in Service Management Automation. It executes the actual runbooks.
A challenge ever since the Azure Automation was released, was to automation On-Premise servers.
While there is a blog post describing a clever way to do this, it did require extra code and other sorts of problems such as the dreaded double hop issue in PowerShell (and then requiring CredSPP).
The Hybrid Worker on the other hand is a worker you install on one of your On-Premise server (or server in Azure IaaS).
It then connects to Azure Automation and picks up jobs directly when a job is assigned to the worker.
To enable load balancing, fail-over and scalability, a Hybrid Worker is member of a “Hybrid Worker Group”.
These groups are where the job are assigned to, and then one of the servers in the group picks up the job and executes the runbooks on-premise!
When you choose to create a new hybrid worker, there is a nice step by step guide:
Web Hooks
Third by not least is the Web hooks.
The web hooks address another challenge in hybrid automation.
The challenge of triggering from on-premise or other systems.
When you add a web hook to a runbook, you can call from an external system to start a runbooks.
Sending a JSON payload into the runbook which includes any data you want.
