Azure Automation资源模板创建JobSchedule时遇404资源未找到错误求助

I’ve dug into your ARM template and that odd HTML 404 error you’re hitting when creating the jobSchedules resource—let’s break down the root causes and fix them step by step.

1. Fix the JobSchedule Naming Format #

The biggest red flag here is how you’re naming the jobSchedules resource. Azure requires job schedule names to follow the format {automationAccountName}/{jobScheduleGuid}—you can’t use a friendly descriptive name like pauseResourcesAtEndOfWorkDay-<guid>. That’s almost certainly why Azure is throwing a 404—it can’t resolve the non-GUID name you’re using.

Update your jobScheduleName variable to use a pure GUID for the job schedule segment:

"jobScheduleName": "[concat(parameters('accountName'), '/', parameters('ingestSchedulerGuid'))]"

You can reuse your existing ingestSchedulerGuid parameter since it’s already a valid GUID, or create a dedicated jobScheduleGuid parameter if you want to keep schedule and job schedule GUIDs separate.

2. Correct Nested Resource Naming for the Schedule #

Looking at your schedule resource definition, you’re using a full path (including the automation account name) for the name field:

"name": "[variables('endOfWorkDayScheduleName')]",
"type": "microsoft.automation/automationAccounts/schedules",

Since this is a nested resource under the automation account, the name should only be the schedule’s unique name—not the full path. Change the schedule’s name to use your endOfWorkDayScheduleNameEnd variable instead:

"name": "[variables('endOfWorkDayScheduleNameEnd')]",

This ensures Azure correctly registers the schedule under your automation account, so the job schedule can find it later.

3. Clean Up DependsOn References #

Your current dependsOn list for the job schedule has redundant and potentially misaligned entries:

"dependsOn": [
  "[parameters('accountName')]",
  "[concat('Microsoft.Automation/automationAccounts/', parameters('accountName'), '/runbooks/', variables('pauseResourcesRunbookName'))]",
  "[concat('Microsoft.Automation/automationAccounts/', parameters('accountName'), '/schedules/', variables('endOfWorkDayScheduleNameEnd'))]"
]

• Remove the [parameters('accountName')] entry—it’s redundant because nested resources inherently depend on their parent automation account.
• Double-check that the runbook and schedule paths in the remaining entries exactly match the names of those resources (with the fix from step 2, the schedule path should now be correct).

4. Align API Versions Across Automation Resources #

You’re mixing older preview API versions (2015-01-01-preview for runbooks/credentials) with a newer stable version (2015-10-31 for schedules/job schedules). While this might not be the direct cause of the 404, version mismatches can lead to unexpected resource resolution issues. Update all Automation-related resources to use the same stable API version (e.g., 2023-11-01 is the latest as of now, or stick with 2015-10-31 if you need backward compatibility).

5. Verify Runbook Publishing Completion #

When using publishContentLink to deploy a runbook, ARM sometimes doesn’t wait for the runbook to finish publishing before creating the job schedule. To mitigate this, ensure your runbook is marked as published (the publishContentLink should handle this, but adding an explicit dependency on the runbook’s published state can help if issues persist).

After applying these fixes, redeploy your template. The 404 error should disappear because Azure will now be able to correctly locate the dependent schedule and runbook resources, and the job schedule will have a valid GUID-based name that Azure recognizes.

内容的提问来源于stack exchange，提问作者chestercodes