Azure Automation with Hybrid Workers
Azure as a your center for automation and orchestration tasks. You will not come around Automation Accounts, and neither all of your infrastructure may be located within Azure. This is where Hybrid Workers help out. The idea is to connect to other clouds or on-premises domain VMs and run some kind of automation outside of the Azure boundaries.
Considerations and limitations
Hybrid workers come through the Microsoft Monitoring Agent and Update Management, which is a common solution built on this product. The solution requires to be enabled through Powershell. Hybrid workers (virtual machines, Windows or Linux) can and must be uniquely grouped. Later on, Azure Runbooks can be scheduled to run scripts or programs in a selected language. These tasks are processed on a first-come, first-serve basis by the workers. The worker polls the service every 30 seconds and asks for new jobs. So the thought is on an application workload automation and processing, rather than a broad enrollment of adaptations. The first 500 minutes per month are free to use. See pricing
Install the Hybrid Worker
So I choose any remote VM to run the install commands. Make sure Microsoft Monitoring Agent (MMA) is installed before.
Navigate to this path, and import the module from here.
cd "C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\<version>\HybridRegistration"
Subsequently import the module from here:
Register the Hybrid Worker with this command and change it with your custom arguments.
- Groupname - custom value, that you specify
- URL - can be found under Automation Account>Keys (image)
- Token - same as URL
Add-HybridRunbookWorker -GroupName <String> -EndPoint <URL> -Token <String>
Azure Automation Account
First of all you need an Automation Account, which in turn requires an Azure subscription.
Hybrid worker groups
After you ran the Powershell commands and specified a group in the parameter, you should see that in the Hybrid Worker Groups. Go to Automation Account>Process Automation>Hybrid Worker Groups.
At the top, there are User hybrid worker groups (blue), that hold groups, created manually and System hybrid worker groups (green) are all Azure based workers. (for example Update Management) The difference is, that multiple workers can be member of a worker group for resiliency or high availability reasons.
Runbooks is in the category Process Automation. As you see the types can be Powershell, Phyton, Powershell Workflow, Graphical Powershell or Graphical Powershell Workflow. These can also be imported, but the even better way, is to browse the gallery.
The gallery hosts many Runbook templates from Microsoft and the community, which are found on GitHub or Powershell Gallery.
If we take a closer look to a Runbook there are few options to set. At the core, the code is the most important. You can view and edit this, then if it's ready publish it.
To test the functionality you can either run the Runbook or open a test pane within the edit mode. Here we see the output of the command/script, which is in this case the hostname of the machine, in the worker group.
During that, the communication is established on the Hybrid Worker on Port 443 and the remote code will be run locally and the output is uploaded back to Azure.
Schedules and parameters
So, you may want to run your tasks at a specific time or recur this event. Runbooks can be linked to these schedules. (even to Update Management schedules) The parameters decide, where the Runbook applies; whether to Azure or worker groups.
The Watcher can do similar things like Runbooks, although the principle is more oriented to an if-then mechanism. So if the first script triggers something (Watcher), a second script will then be run (Action). I could imagine that to be used for remediation or backup use cases.