How to Setup an Azure Automation Hybrid Worker

In a previous post, I went into some detail about Azure Automation and the advantages of using it in your Azure environment. But I wanted to elaborate more on one aspect of Azure’s Automation capabilities: Hybrid Workers. To recap, typically an Automation Account would only have access to the Azure resources in your tenant. However, the Hybrid Worker adds the option for your runbooks to run in, and interact with, your local environment.

The Hybrid Worker setup is relatively straightforward and easy to run. The server itself can run on OS’s as far back as Windows 7 SP1 or Server 2008 SP2, so even those still tied to an older OS can still utilize the Hybrid Worker service. Other requirements are fairly minimal (note that you will also need to have .NET Framework 4.6.2+ and Windows PowerShell 5.1+ installed) and the service itself only requires port 443 access to connect to the Azure Cloud.

You have two options for how to install the Hybrid Worker service: either an Automated or a Manual deployment. The Automated deployment involves downloading a PowerShell script (New-OnPremiseHybridWorker.ps1) and supplying the required parameters to connect to your Azure tenant and Automation Account.

You will also need a Log Analytics workspace to set up the Hybrid Worker service. The deployment process can create one for you, but if you prefer to have your Azure resources follow a specific naming convention, then you should create it beforehand and supply the OMSResourceGroupName and WorkspaceName parameters in the deployment script.

Assuming this all goes well, you should now see the option to start Azure Runbooks on the Hybrid Worker server.

One thing to note with running scripts on the Hybrid Worker server is that it will only run using the local SYSTEM account by default. However, you can change this setting in the Automation Account by tying a Run As Account to the Hybrid Worker server. This account should have the required privileges on any servers or devices that you wish to manage through Azure Runbooks.

To create and assign the Run As Account to the Hybrid Worker, you will need to create a Credential object in the Automation Account. There are several types of Shared Resource objects that can be used by the Solutions/Runbooks tied to the Automation Account. One of these object types is Credentials, which allows you to add the username/password information for an account (local, domain, UPN format, etc) without exposing sensitive password information (the password value is encrypted and cannot be viewed in plaintext).

Create the Credential here and then assign it to the Hybrid Worker settings to configure the server to use another account. This will allow you to run your runbooks on the Hybrid Worker server and be able to authenticate to other machines in your environment.

Now, you may have noticed that when starting a Runbook, you have the option of running it from Azure OR from the Hybrid Worker. But what if you have a script that needs to run on resources in your Azure tenant AND devices in your local environment? Fortunately, this is possible! And this scenario is the exact reason I would highly recommend using an Azure VM for your Hybrid Worker server rather than a non-Azure machine.

There are two sets of instructions for configuring your Hybrid Worker server to work with both your local environment and your Azure tenant: the Managed Identity method and the Certificate method. The Managed Identity method is the preferred option, but it requires that your Hybrid Worker server be running on an Azure VM; if the Hybrid Worker is not on an Azure VM, then you will need to use the Certificate method.

The Managed Identity method simply requires registering a system-assigned managed identity on your Azure VM, applying the needed RBAC rights in your Azure environment, and then adding a line to your runbook scripts to connect to Azure via managed identity (Connect-AzAccount -Identity).

The Certificate method consists of a script to export the Run As certificate from your automation account and then importing/installing said certificate on the Hybrid Worker. While it sounds simple in practice, note that you will still need to renew this certificate every year, which could cause issues if it is not renewed in time.

Essentially, the Managed Identity method has less administrative overhead and is more of a one-time setup than having a unique certificate that you would need to manage on each Hybrid Worker server that you have running.

Hopefully, this will help those of you in the Azure space with designing and building your own Automation setup. The flexibility of having your scripts running on your Azure environment, your local environment, or both at the same time can be very helpful for getting all your automated tasks/processes in a centrally managed and easily visible space. Would you like help in getting Hybrid Workers setup in your environment? Or would you just like to have a conversation about Azure in general? We at Anexinet would love to talk, so please reach out to us. Let’s walk your Azure journey together.