How To Automate The Hybrid World Part Two Of Two
Published Jan 26 2023 03:56 AM 3,172 Views

Hi, Jonas here!

Or as we say in the north of Germany: "Moin Moin!"
I’m a Microsoft Senior Cloud Solution Architect – Engineering (or short Sr. CSA-E) and in this article I want to talk about how to automate the hybrid world.

Over the years Microsoft has developed more and more automation tools such as Power Automate, Azure Logic Apps, Azure Functions or Azure Automation. While Azure Automation is not the latest tool in the automation tools family, I dedicate this blog this amazing tool and hopefully provide you with an easy-to-follow how-to guide.

Table of contents

Set rights for run as account
Create and run a Runbook
A more complex runbook
Install required Cmdlets
Create Automation Variables
Add the Runbook-Script
Start the Runbook using the Azure portal
Start the Runbook using a webhook
Start a Runbook using a schedule
Monitoring and Logging
Secure access to Azure Accounts


This is part two of a two part series. If you haven't read the first part yet, I recommend you read part one first and come back to this one since it builds on what I’ve done in part one.

You will find part one in the list of my other articles here:


Now let's finish setting up the Hybrid Worker and start playing with the Runbook feature of Azure Automation.

So, grab a coffee or two and follow along if you like.


Set rights for run as account

You could skip this section if you chose not to use a "run as account" for the Hybrid Worker group. (Described in part one of this two part article)

Since we want to make sure the service account has least privileges possible, let’s configure the following settings:

  • Allow logon locally
  • Deny access to this computer from the network
  • Deny log on as a batch job
  • Deny log on as a service
  • Deny log on though Remote Desktop Services

We can either use a GPO to give the user appropriate permissions or the local group policy editor for testing.

  1. Either way, go to “Computer Configuration” -> “Windows Settings” -> “Security Settings” -> “Local Policies” and “User Rights Assignment”
  2. Set the policies mentioned above: Local Computer Policy - User Rights Assignment DialogLocal Computer Policy - User Rights Assignment Dialog

Create and run a Runbook

It is now time to create and run our first Runbook on the new Hybrid Worker.
Let’s create a quite simple Runbook and validate the output, before we start a more complex approach.

  1. Go to: Azure Portal: Automation Accounts and click on the new Automation Account
  2. Click on “Runbooks” and “+ Create a runbook” Azure Portal Automation Account - Create a Runbook ButtonAzure Portal Automation Account - Create a Runbook Button
  3. Provide a name for the runbook, select “PowerShell” as runbook type and select 5.1 as runtime version Azure Portal - Create a Runbook WizardAzure Portal - Create a Runbook Wizard
  4. Click on “create” to create the new runbook
  5. We now see the runbook editor and can use two basic lines to validate a working hybrid worker.
  6. Copy the two lines below into the runbook
    Get-date -f u
  7. Now click on “Save”, “Publish” and “Yes” for the override question
  8. We should now be able to click on “Start” and choose “Hybrid Worker” and the Hybrid Worker group we created earlier as a target. Azure Portal - Start Runbook WizardAzure Portal - Start Runbook Wizard
  9. The Azure Portal will then open the Job Status Page. After a while, the output of the two lines of code should be visible under “All Logs” like shown below. That’s an indication that everything is working fine. (I used different machines during testing, hence the different server names in the screenshots) Azure Portal - Runbook Job Status PageAzure Portal - Runbook Job Status Page
  10.  Locally on the Hybrid Worker we can also follow along by looking at the corresponding event log entries under “Application and Services Logs\Microsoft-SMA\Operational”. 
    We can clearly see the worker receiving the runbook job (EventID: 15174) and the switch to the run as account (EventID: 7600) as well as the started script (EventID: 2311) Event Viewer (Local) - Microsoft-SMA Operational EventsEvent Viewer (Local) - Microsoft-SMA Operational Events

A more complex runbook

Since everything is set up and working, we can now use a more complex runbook and really automate something.

In this section we will do the following:

  • Install or copy required Cmdlets on Hybrid Worker machine
  • Create some variables in automation account
  • Create a runbook we can start with any available method we want
  • Start the runbook using different start methods


Install required Cmdlets

In the case of ConfigMgr we need to install the ConfigMgr console on the Hybrid Worker server. That gives us access to the ConfigMgr cmdlets. Please refer to the ConfigMgr documentation on how to do so. Or use any other Cmdlet you want to test with. (The example script expects the ConfigMgr cmdlet)


Create Automation Variables

For the Example-Runbook to work we need four variables.

Variable Name Value Description

Create a GUID by running “New-Guid” in PowerShell or use any password like string.

The string is used to validate if the runbook is allowed to run or not.

I will further explain this method when we start the runbook.



Like Var-StartString1 but with a different value



The FQDN of the ConfigMgr SMS Provider.
Example: “server1.contoso.local”



The ConfigMgr site code. Example: “P01”



  1. To create a variable, go to: Azure Portal: Automation Accounts
  2. Click on: “Variables” (under “Shared Resources”)
  3. Click on: „+ Add a variable“ Azure Portal - Add a Variable to Automation AccountAzure Portal - Add a Variable to Automation Account
  4.  Use the list above to create four variables

  5. For the start string variables (Var-StartString1 and Var-StartString2) set the variable to be encrypted Azure Portal - Set Automation Account Variable to EncryptedAzure Portal - Set Automation Account Variable to Encrypted
  6. The list of variables should now look similar to the following screenshot 

    Azure Portal - Automation Account List of VariablesAzure Portal - Automation Account List of Variables


Add the Runbook-Script

Download or copy the example runbook from here: ConfigMgr-RunbookExample1.ps1 and create a new runbook as we did earlier.  (Described in Create and run a Runbook)

The script is designed to run in Azure automation using any of the available start methods, in PowerShell ISE or in Visual Studio Code for example. This makes testing really easy and gives you enough examples to create more complex Runbooks.

The example script contains comments to explain the inner workings, but it basically does the following: 
Script Process Flow DiagramScript Process Flow Diagram

Start the Runbook using the Azure portal

If we start our new Runbook, as we did before with the simple one, we will be asked for parameter values this time.


Since we’re not using a webhook (a webhook will be explained in the next step) and we read  “ProviderMachineName” and “SiteCode” from Azure Automation variables, we only need to fill four variables as illustrated in the screenshot.


As “STARTSTRING” use one of the values of Var-StartString1 or Var-StartString2. The two strings act as a password-like string to prevent anyone from starting the runbook not having the correct start string. (It might make more sense in the next example)


As “SYSTEMNAME” use anything you like.


As “SYSTEMMACADDRESS” use a valid Mac address


As “COLLECTIONNAME” us a valid ConfigMgr collection-name

Make sure to choose the Hybrid Worker Group down below and click “OK” to start runbook execution.


We will then be redirected to the “Job Status Page” to see the result of the execution.


Start the Runbook using a webhook

A webhook is an URL you can use to directly start a runbook without the need to click on “Run” in the Azure Portal.
The Azure Portal treats each webhook as a password and will only show the full URL once. That’s because it is kind of having a password to start the runbook and we don’t need any extra authentication method. That is also the reason why we use the parameter “StartString” and the two “RunVariables” to have some kind of extra validation layer before we let the runbook fully run its actions.
NOTE: Always treat the URL as if it were a password and store it safely.

  1. On the Runbook page go to “Webhooks” and click on “+ Add Webhook” Azure Portal - Automation Account Add Webhook ButtonAzure Portal - Automation Account Add Webhook Button
  2.  Choose “Create new webhook(1)

  3. (2) Give the webhook a name and set “Enabled” to “Yes” and Copy the URL (it is visible just this once). Click on “OK
  4. Choose “Configure parameters and run settings(3)
  5. Set the “Run on” setting to “Hybrid Worker” and choose the Hybrid Worker group we created earlier. (4) Azure Portal - Automation Account Add Webhook WizardAzure Portal - Automation Account Add Webhook Wizard
  6. Click "Create" to create the webhook.

We can now post data to the webhook URL to start our Runbook from anywhere and from any application that supports the post method.

Use the following example script to start the runbook using the webhook via PowerShell for example. 

  1. Open a PowerShell ISE or Visual Studio Code and copy the example script shown below
  2. Replace the “$webhookURL” value with your webhook URL
  3. Replace the other variable values in line 9-12 as well
  4. Replace the “StartString” value with one of the two Automation variable values “Var-RunString1” or “Var-RunString2”.


# URL of the webhook
$webhookURL = '[tokenvalue]'

# A header
$header = @{message='We need a new machine'}

# The body contains the neccesary parameter values
$body = @{
        CollectionName = 'All Systems' 
        StartString = '64fe693f-150e-4593-a1e1-6cb0f3f11114'
    } | ConvertTo-Json # we need to convert the body to JSON

# A simple POST invokes the runbook
Invoke-RestMethod -Method Post -Uri $webhookURL -Headers $header -Body $body



Start a Runbook using a schedule

In the case of the example runbook a schedule does not make much sense, because we use it to import computer information into ConfigMgr and we have changing parameter values.

But it’s important to know that we could also create a schedule to run the runbook periodically.


Monitoring and Logging

To view runbook states we have multiple options. We used some of them already.

  • Azure Portal (Job state for example)
  • Local event log
  • Own script log file stored on the Hybrid Worker (wasn’t part of the example script)

It is also possible to export Azure Automation related events to a Log Analytics Workspace to have more reporting capabilities and the ability to use “Azure Workbooks”.
Go to your Azure Automation account and click on “Diagnostic Settings” and “+ Add diagnostic setting” to configure the export if you like.


Secure access to Azure Accounts

There are multiple built-in roles for Azure Automation and Arc connected machines such as:

  • Automation Contributor
  • Automation Operator
  • Automation Job Operator
  • Automation Operator
  • Automation Runbook Operator

For Azure Arc connected machines:

  • Hybrid Server Onboarding
  • Hybrid Server Resource Administrator

Use the built-in roles or create custom ones to restrict access to the Automation Account and Arc enabled servers.


I hope you had fun following along to automate the hybrid world.
Keep in mind that you can do a lot more with an Azure Arc enabled server as just running runbooks on a Hybrid Worker.
Azure Automation and Azure Arc are amazing tools, and both can help you automate and simplify server-, process- and service-management. Have fun with them!



Stay safe! 

Jonas Ohmsen 
Microsoft Germany 



This posting is provided "AS IS" with no warranties and confers no rights.


Version history
Last update:
‎Jan 26 2023 05:51 AM
Updated by: