Table of Contents
Disclaimer: this is a work around that is not always useful
I am currently hired by a client who has one Hybrid Worker Group (and to whom we are not allowed to make any adjustments).
There are runbooks that have to work with the data from other runbooks, but because the data is so much and this is edited by another team, they chose to generate the data first and then edit it in parts over 4 days.
This ensures that we now have 2 schedules where one is for Runbook1 and the other is for Runbook2 where schedule 2 starts 4 days in a row and continues to convert the data.
The disadvantage is that the data is stored on a Hybrid Worker and then the 2nd schedule starts on another Hybrid Worker.
You would think, why don’t you have a file share?
Unfortunately, that’s not possible within the environments either.
Because we are imposed all kinds of restrictions, we are often creative.
Because of this I came up with the following function which is explained in the next paragraph.
But what do I mean with the disclaimer?
Basically what the function does is restart the Runbook until it runs on the correct Hybrid Worker.
This is still possible with two to five Hybrid Workers.
If you have more than five, the question is whether you want to do it that way? The chance that the right Hybrid Worker is chosen becomes smaller and smaller the more Hybrid Workers you have.
Maybe you should just look at one separate Hybrid Worker Group with one Hybrid Worker on which these types of runbooks can run.
Let’s start a runbook on a specific Hybrid Worker in Azure Automation
So how does the function work in short?
When the runbook is not running on the Hybrid Worker you prefer.
It will re-start the runbook and goes asleep for the value described in parameter StartSleep.
Because the Runbook is still in sleep mode it will use a Hybrid Worker that has more performance capacity.
After the timer exceeded it will stop the runbook with statement Exit
.
Keep in mind that it can go in to an infinite loop when the Hybrid Worker name is incorrect! Read the HybridWorker parameter carefully.
Get the function from Github
It’s important to read the HybridWorker parameter before you start using this function.
The function is placed in a Github repository.
You can copy the function from Github and put it in Azure automation.
You can then dot source the function into your Runbook with the following:
. .\Start-SpecificHybridWorker.ps1
And just call the function by it’s name (function name not runbook name):
Start-SpecificHybridWorker -(including parameters)
Let’s go through the function
The function has 4 parameters:
Runbook (mandatory)
This parameter is mandatory, but it’s an easy one.
This is the runbook you want to start in Azure Automation.
The name is sufficient and you don’t have to put a .ps1 after it.
In my examples I’ll use the following:
. .\Start-SpecificHybridWorker.ps1
Start-SpecificHybridWorker -Runbook 'Runbook1'
HybridWorkerGroup (mandatory)
This parameter is mandatory.
This is the HybridWorkerGroup that contains the relevant Hybrid Worker.
You can see the group names and which Hybrid Workers are a part of this group in the Azure portal.
Open the appropriate Azure Automation environment and search for and open Hybrid Worker Groups.
In the tab on the right you see the Hybrid Workers under User Hybrid Worker Groups.
These are the Hybrid Workers that you can run a runbook on.
So the parameter expects the Group Name and not the Hybrid Worker itself.
My group name is ‘Test‘.
So the cmdlet now looks like this:
. .\Start-SpecificHybridWorker.ps1
Start-SpecificHybridWorker -Runbook 'Runbook1' -HybridWorkerGroup 'Test'
HybridWorker
This parameter is not mandatory! Weird eh? Well, not really.
For when you do use the parameter
Remember that if you enter a wrong name you will get an infinite loop. So make sure that the name is correct and that when the server is phased out, you also change it manually.
The name is the same as the name you get back from $env:COMPUTERNAME
.
If we took my laptop as an example, it would look like this:
$env:COMPUTERNAME
DESKTOP-1SDR953
So the cmdlet would be:
. .\Start-SpecificHybridWorker.ps1
Start-SpecificHybridWorker -Runbook 'Runbook1' -HybridWorkerGroup 'Test' -HybridWorker 'DESKTOP-1SDR953'
For when you do not use the parameter
If you do not enter a name, the function simply grabs the first Hybrid Worker in the Hybrid Worker Group.
If you don’t use the parameter HybridWorker, the function does require some more functionalities from Azure Automation.
We then need an extra function, enable managed identity and 3 variables in Azure Automation.
New-ManagedIdentityAccessToken function
We need the New-ManagedIdentityAccessToken
function. This can also be found on Github.
Place it in Azure Automation in the same way as the Start-SpecificHybridWorker
function.
You don’t need to dot source it. This is done automatically by the function itself.
Enable Managed Identity
We need to enable Managed Identity in Azure Automation and give it contributor permissions for itself.
Check out the screenshot below or use these two tutorials to do this:
- Using a system-assigned managed identity for an Azure Automation account | Microsoft Docs
- Delegated permissions with a Client Secret by adding roles to a Service principal
New Azure Automation variables
We also need 3 new Azure Automation variables.
All of them are strings.
- AzureSubscription
This is your AzureSubscriptionId. - ResourceGroupName
The ResourceGroupName that contains the AutomationAccount. - AzureAutomationAccount
This is the AutomationAccountName
You can follow the Microsoft Docs to add variables.
StartSleep
To make a runbook start on another Hybrid Worker, I use the Start-Sleep
cmdlet.
Otherwise I’m afraid the right Hybrid Worker won’t be chosen because the Runbook goes back and forth between Hybrid Worker 1 and 2.
The default value is 30 seconds. When you’ve got more than 2 Hybrid Workers I’d up this to at least 60 seconds.
By customizing StartSleep the cmdlet would be:
. .\Start-SpecificHybridWorker.ps1
Start-SpecificHybridWorker -Runbook 'Runbook1' -HybridWorkerGroup 'Test' -HybridWorker 'DESKTOP-1SDR953' -StartSleep 60
After the timer, the function stops the runbook with the statement Exit
.
A real example of Start-SpecificHybridWorker
In the screenshots below you can see that the runbooks starts the runbook again and goes into sleep mode for 60 seconds.
After 7 tries the 8th try was on the correct Hybrid Worker.
And with the end result: