Last week I wrote about some of the fun I have had with job schedules and ARM Templates. In short ARM cannot re-deploy job schedules and so you have to delete them prior to re-deploying, or do a sort of merge statement. But because time is short deleting them seems to work well enough. Something like this:

$automationAccountJobSchedules = Get-AzureRmAutomationScheduledRunbook -AutomationAccountName $AutomationAccountName -ResourceGroupName $resourceGroupName -ErrorAction SilentlyContinue
        Write-Host "Removing any job schedules off automation account $($AutomationAccountName): this is because of this bug
        https://feedback.azure.com/forums/246290-automation/suggestions/33065122-redeploying-jobschedule-resource-from-arm-template "
        $automationAccountJobSchedules
        foreach ($JobSchedule in $automationAccountJobSchedules) {
            Write-Host "Removing $($JobSchedule.ScheduleName) from $($JobSchedule.AutomationAccountName)"
            Unregister-AzureRmAutomationScheduledRunbook -AutomationAccountName $JobSchedule.AutomationAccountName -RunbookName $JobSchedule.RunbookName -ScheduleName $JobSchedule.ScheduleName -ResourceGroupName $JobSchedule.ResourceGroupName -force
        }

So once they’re deleted we can deploy from ARM. At least, so I thought. Come to find out that if you re-use the same GUID then you still get the error. This means you have to delete the schedule entirely, or create a new GUID for each deployment. Thankfully in PowerShell there is a New-Guid cmdlet to create one. It is a bit rubbish you have to do this but at least it is pretty straightforward to have to workaround and you don’t really care what the GUID is anyway. What is interesting is that the GUID is non-optional in an ARM template but when using register-AzureRmAutomationScheduledRunbook to do the same thing you don’t need to specify a GUID. So maybe it is pretty pointless to use an ARM template at all when deploying job schedules.