Redeploying jobSchedule resource from ARM template
Currently Microsoft.Automation/automationAccounts/jobSchedules resources cannot be redeployed from ARM template if there are existing jobSchedules pointing to the same runbook and schedule. The deployment would return:
"A job schedule for the specified runbook and schedule already exists"
Same issue even deploying with a different name (GUID) for the jobSchedule.
Currently the workaround is deleting the existing resource and redeploy, which is a very cumbersome approach for automation.
Yulun Zeng
shared this idea
Redeploying job schedule through ARM template needs a different jobschedule GUID. Even if you delete the job schedule , the GUID is retained in the database , hence a 2nd deployment will succeed only if the GUID is different.
The scenarios where jobschedule GUID cannot be reused is as follows:
1) The automation account is deleted before deleting the job schedule. The job schedule entry is soft deleted but is still present in the database.
2) The automation account is created with the same name again and the same GUID is used for job schedule.
We have identified as a bug & an improvement task is planned. We will pick this up as resourcing allows since this would need some changes in the architecture. As a workaround to this, pls update the GUID for jobSchedule.
13 comments
-
Anti Ohne
commented
I implemented an Azure ARM template based workaround for this issue. It utilizes the deployment script functionality. Read my blog article for more information: https://integrationworkz.antiohne.nl/2021/01/azure-automation-solve-a-job-schedule.html
-
Anti Ohne
commented
This jobSchedule resource is one of the Azure Automation resources conflicting with a fundamental rule of ARM templates documented by Microsoft (https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview)
"Repeatable results: Repeatedly deploy your infrastructure throughout the development lifecycle and have confidence your resources are deployed in a consistent manner. Templates are idempotent, which means you can deploy the same template many times and get the same resource types in the same state. You can develop one template that represents the desired state, rather than developing lots of separate templates to represent updates."
-
Zengxian Chen
commented
Any update?
-
Khaled Moussef
commented
Can we have this fixed please? ARM templates are useless in this respect if they can't be continuously deployed.
-
Christen Kevin, FD/ICT/FIB/FIBI
commented
This should be looked into. Please, this is not a good thing for automation since we have to create an aditional uneccessary step in the pipeline.
-
Yayi Ning
commented
Hi, is there any update?
-
Ning Jiang
commented
That's not automation if this issue cannot be solved. Please fix it. Thank you.
-
Anonymous
commented
Please fix it, this is blocking the whole automation
-
Edwin Tierra
commented
Please someone fix this. It's been a while since this issue was first reported. The schedule is an important component in Azure Automation and it's very ironic that we cannot "automate" the deployment because of this problem
-
Ben Rayment
commented
This was originally raised way back in March 2016 and still not fixed. Ridiculous.
-
Anonymous
commented
If the runbook has passed parameters (see schedule from within the runbook page in the portal) do any of these change? I have noticed that if any of these parameters change at runtime, then the above error occurs.
If you want to apply changes to these parameters, then yes you have to delete the schedule and redeploy again which is annoying...
-
Brian Bauer
commented
please fix this
-
Dexter Lakin
commented
Is there any update on this? Not very idempotent