Azure Automation – Hybrid Worker Setup

It is May 4th which marks the start of Microsoft Ignite 2015 and of course new Azure features start to appear. So first Azure Automation is now available in the preview portal:

This new experience also gives you the option to create graphical runbooks:

Although this looks great I think I will still prefer writing text runbooks (PowerShell) but this will be useful for less PowerShell experienced folks.

Now lets move on to the more interesting feature and that is Hybrid Worker. Hybrid worker let’s use execute Runbooks on on-prem machine instead in Azure. If you click on that tile and configure you will see how to enable that:

So in short Azure Automation uses Azure Operational Insights for deployment of the bits of the Hybrid Worker on on-prem machine. After that you can logon locally on the machine you need to execute a cmdlet in order to connect the Hybrid worker to your Azure Automation Subscription. It is still uncertain for me if the Hybrid worker will use OpInsights’ proxy if you do not have direct connection to Internet.

Lets see how we can do all these steps.

First I go to my Operational Insights workspace and add Automation Intelligence Pack:

After that the bits needed for Hybrid Worker will be deployed on all your directly attached agents:

What I’ve noticed that those bits are not deployed to connected  SCOM server and agents connected trough SCOM. So you should use directly connected agents from OpInisghts.

After that you can logon to a machine with direct agent and execute cmdlet to connect that machine to Azure Automaton and basically promote it as Hybrid Worker.

The cmdlet in question is Add-HybridRunbookWorker and we first need to find in which module is that found. After some digging I’ve found that all Azure Automation Hybrid worker bits are locate in the following directory:

C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomationFiles

and in HybridRegistration folder you will find a module that you can import:

Import-Module “C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomationFiles\HybridRegistration\HybridRegistration.psd1”

After that you can see what cmdlets are available:

get-command -Module HybridRegistration

Looking at the help of Add-HybridRegistration we can see what parameters are available:

Seems Endpoint, Token and Name are mandatory but where I can find those? Actually two of them are easily to find at the Azure Automation account information. Just go to your Automation Account main page and on tip there is a key icon that you can click which will give you Primary Access Key, Secondary Access Key and URL.

Your Primary Access Key is your Token parameter, URL is your Endpoint parameter and for Name parameter you can choose whatever makes sense for you:

Add-HybridRunbookWorker -EndPoint https://we-agentservice-prod-1.azure-automation.net/accounts/XXXXXXXXXXXXXXXXXXXXXXXXXXX -Token “XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX” -Name StanHW

After that you should see immediately your Hybrid worker on the portal:

Now you can create a simple runbook like this:

workflow TestHybrid
{
Write-Output $env:computername
}

for tests.

If you run it and choose Azure:

Output will be “Client”:

But if you execute at your Hybrid Worker:

The output will be “DC01” which is the name of the server I’ve added as Hybrid Worker:

When you execute runbook on Hybrid Worker you will see process Orchestrator.Sandbox being started:

So a few summaries from me on this:

• Seems this feature works currently only with OpInsights Direct Agent and not with SCOM connected servers.
• It is not clear if Hybrid worker uses the proxy of OpInsights Direct Agent if there is one.
• Executing runbooks in Azure looks a little bit faster.
• Seems currently you cannot scheduled runbooks to be executed on Hybrid worker.
• You cannot do tests of runbooks on Hybrid Worker. you have to publish the runbook and execute it.
• Seems you are billed the same way if you are executing runbooks on Azure or Hybrid worker.
• Tile for Automation in OpInsights is currently empty and unclickable.
• PowerShell modules uploaded to Azure Automation are not distributed to Hybrid Workers.
• If you give the same Name for Hybrid Worker when register it to more than one server they will work in high-availability/load balancing mode. I am not sure what happens if node is down.