Why dynamic scheduling Azure runbooks is tricky
I’ve been working with Azure Automation for a while now and using it mostly to automate administrative workloads on SharePoint Online. In one of my latest endeavours I tried to orchestrate multiple runbooks using dynamic scheduling. Here’s how that went down.
Creating schedules dynamically
In my case I wanted to use my runbook named DynamicSchedulingRunbook to create a schedule in my Azure Automation account that triggers another runbook called DynamicSchedulingTask with some parameters. Not only should DynamicSchedulingTask be scheduled, it must also restart DynamicSchedulingRunbook with different parameters when the workload is done so we get some sort of batched chain of workloads. A simple flowchart would look like this.
As it turns out, the code to get this chain running is really simple (I use PowerShell for the runbooks). First you need to import the Modules Az.Accounts and Az.Automation (in that order) from the Modules gallery.
Then to create a schedule and register this in the DynamicSchedulingRunbook, I used these lines:
New-AzAutomationSchedule -AutomationAccountName “Automata” -Name “Task_Batch” -StartTime $StartTime -OneTime -ResourceGroupName “Automata-Demo”
Register-AzAutomationScheduledRunbook -AutomationAccountName “Automata” -Name “DynamicSchedulingTask” -ScheduleName “Task_Batch” -ResourceGroupName “Automata-Demo” -Parameters @{“BatchNo”=$BatchNo;”BatchSize”=$BatchSize;”TaskName”=$TaskName}
When registering the scheduled DynamicSchedulingTask, I pass the parameters “BatchNo”, “BatchSize” and “TaskName”.
A side note on Start time
The -StartTime parameter on the New-AzAutomationSchedule command must be set to at least 5 minutes after the schedule is created. When creating schedules automatically, the actual creation will take up some (mili)seconds and setting for instance the $StartTime variable to (Get-Date).AddMinutes(5) will not succeed because of those seconds. Setting it to (Get-Date).AddMinutes(6) is safer, assuming it will not take Azure a full minute to create the schedule.
Reusing automation schedules
At first I hoped, since my schedule is set to OneTime, it would be automatically disposed in Azure. After testing this through I found out this is not the case. Any schedule is preserved and is given an “expired” state when done. So I started to think these schedules are reusable, and I found out they are!
When registering the next batch from DynamicSchedulingRunbook it seems that when using the same name “Task_Batch” with a different start time, this schedule is actually reused. I found this out because there was something wrong with this run. It ran with my old parameters.
Not all properties are overwritten
Since DynamicSchedulingRunbook is passing parameters to the schedule, I found out that indeed the schedule is reused and the new start time is set, but the parameters that where passed the first time are not overwritten. Yikes! Do we have a bug here? I tested this multiple times with different parameters but unfortunately a schedule, when reused, always uses the parameters from the first registered runbook.
How to work past this
To work past this, you need every schedule to be unique. You can either specify a unique dynamic name by for instance using one of the parameters that increments to the name of the schedule. In our case we can use the batch number.
Another way is to cleanup the schedules after the task has run. Because we only use OneTime schedules and don’t want to reuse them, it’s good practice to dispose them ourselves. You can do so using this line of PowerShell:
Remove-AzAutomationSchedule -AutomationAccountName “Automata” -Name “Task_Batch” -ResourceGroupName “Automata-Demo” -Force
Hopefully this will post helps you out when facing the same issue. I wrote more on Azure Automation and specifically this topic on our company blog. The first story in that series: Azure Automation — Part 1: Create a SharePoint site (portiva.nl)
If you have any questions feel free to reach out!
