Moving an Azure VM Auto-Shutdown from 10 PM to Midnight (Without Breaking the Email)

This is the fast path, and for most people it’s the only one they need.

• Open your Automation Account and select Schedules under Shared Resources. (You can also get here from Runbooks → your runbook → Resources → Schedules.)
• Click the schedule you want to change — Nightly-VM-Shutdown-2200-ET.
• Edit Starts to tomorrow’s date at 12:00 AM. Confirm Time zone reads (UTC-05:00) Eastern Time (US & Canada).
• If your recurrence has a day-of-week selection, fix it now — see the date-boundary warning above. Monday–Friday becomes Tuesday–Saturday.
• Click Save.

That’s it. Same schedule, same resource ID, every runbook link intact. Nothing to relink.

Two things worth knowing. If the current start time is in the past, the portal won’t let you save until you push the start date into the future — bump the date first, then set the time. And if the schedule name now describes the wrong time, consider renaming: you can’t rename an Automation schedule in place, so that’s the one scenario where create-relink-retire earns its keep. A schedule called Nightly-Shutdown-2200-ET that actually fires at midnight will confuse someone in six months.

Step 3 — The PowerShell version

Here’s where the cmdlets let you down. Set-AzAutomationSchedule can’t touch the start time, so you call the REST PUT operation directly. Invoke-AzRestMethod uses your existing Az context, so there’s no extra authentication to wire up.

<#
.SYNOPSIS
    Changes the start time of an existing Azure Automation schedule in place.

.DESCRIPTION
    Set-AzAutomationSchedule wraps the Automation PATCH operation, which
    accepts only description and isEnabled. This script calls the PUT
    (Create Or Update) operation instead, which accepts startTime, timeZone,
    frequency, interval, and advancedSchedule. Updating an existing schedule
    this way preserves the schedule name, resource ID, and all runbook links.

.NOTES
    Author  : John O'Neill Sr.
    Company : Azure Innovators
    Version : 2.0.0
    Requires: PowerShell 7.2+, Az.Accounts 3.0+, Az.Automation 1.10+
    Prereqs : Automation Contributor on the target Automation Account.
#>

$ErrorActionPreference = 'Stop'

$subscriptionId = '00000000-0000-0000-0000-000000000000'
$rg             = 'acs-eng-test-eastus-rg'
$account        = 'aa-vmops-eng-test-eastus'
$schedule       = 'Nightly-VM-Shutdown-2200-ET'

# Anchor to the next midnight. Start time must be in the future.
$startTime = (Get-Date).Date.AddDays(1).ToString('yyyy-MM-ddTHH:mm:ss')

$body = @{
    name       = $schedule
    properties = @{
        description      = 'Nightly tagged-VM shutdown, 12:00 AM Eastern.'
        startTime        = $startTime
        timeZone         = 'Eastern Standard Time'
        frequency        = 'Week'
        interval         = 1
        advancedSchedule = @{
            weekDays = @('Tuesday','Wednesday','Thursday','Friday','Saturday')
        }
    }
} | ConvertTo-Json -Depth 5

$path = "/subscriptions/$subscriptionId/resourceGroups/$rg" +
        "/providers/Microsoft.Automation/automationAccounts/$account" +
        "/schedules/$schedule" + '?api-version=2023-11-01'

$response = Invoke-AzRestMethod -Method PUT -Path $path -Payload $body

if ($response.StatusCode -notin 200, 201) {
    throw "Schedule update failed ($($response.StatusCode)): $($response.Content)"
}

Write-Output "Schedule updated. Status $($response.StatusCode)."

Get-AzAutomationSchedule -ResourceGroupName $rg `
    -AutomationAccountName $account -Name $schedule |
    Select-Object Name, StartTime, TimeZone, NextRun, IsEnabled

A 200 response means the existing schedule was updated. A 201 means you accidentally created a new one — check the schedule name for a typo. If you get a 409 Conflict, the service is refusing the in-place change for that schedule; fall back to create-relink-retire, covered below.

Send the complete properties block, not just the fields you’re changing. This is a PUT, not a PATCH — anything you omit gets reset to its default. Run Get-AzAutomationSchedule first and mirror what’s already there.

Step 4 — Azure CLI

Same story: az automation schedule update only carries description and enabled state, so use az rest.

SUB=00000000-0000-0000-0000-000000000000
RG=acs-eng-test-eastus-rg
AA=aa-vmops-eng-test-eastus
SCHED=Nightly-VM-Shutdown-2200-ET

az rest --method put \
  --url "https://management.azure.com/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Automation/automationAccounts/$AA/schedules/$SCHED?api-version=2023-11-01" \
  --body '{
    "name": "'"$SCHED"'",
    "properties": {
      "description": "Nightly tagged-VM shutdown, 12:00 AM Eastern.",
      "startTime": "2026-08-11T00:00:00",
      "timeZone": "Eastern Standard Time",
      "frequency": "Week",
      "interval": 1,
      "advancedSchedule": {
        "weekDays": ["Tuesday","Wednesday","Thursday","Friday","Saturday"]
      }
    }
  }'

az automation schedule show -g $RG --automation-account-name $AA -n $SCHED \
  --query "{name:name, startTime:startTime, timeZone:timeZone, nextRun:nextRun}"

Step 5 — The create-relink-retire fallback

You need this in three situations: the schedule name should change to match the new time, you’re switching frequency types, or a PUT came back 409.

$params = @{
    ResourceGroupName     = 'acs-eng-test-eastus-rg'
    AutomationAccountName = 'aa-vmops-eng-test-eastus'
}
$runbook     = 'Stop-TaggedVMs'
$oldSchedule = 'Nightly-VM-Shutdown-2200-ET'
$newSchedule = 'Nightly-VM-Shutdown-0000-ET'

[System.DayOfWeek[]]$runDays = @(
    [System.DayOfWeek]::Tuesday, [System.DayOfWeek]::Wednesday,
    [System.DayOfWeek]::Thursday, [System.DayOfWeek]::Friday,
    [System.DayOfWeek]::Saturday
)

New-AzAutomationSchedule @params -Name $newSchedule `
    -StartTime (Get-Date).Date.AddDays(1) `
    -TimeZone 'Eastern Standard Time' `
    -WeekInterval 1 -DaysOfWeek $runDays `
    -Description 'Nightly tagged-VM shutdown, 12:00 AM Eastern.'

Unregister-AzAutomationScheduledRunbook @params `
    -RunbookName $runbook -ScheduleName $oldSchedule -Force

Register-AzAutomationScheduledRunbook @params `
    -RunbookName $runbook -ScheduleName $newSchedule

Set-AzAutomationSchedule @params -Name $oldSchedule -IsEnabled $false
Remove-AzAutomationSchedule @params -Name $oldSchedule -Force

Two details. If the runbook takes parameters, Register-AzAutomationScheduledRunbook needs them passed again via -Parameters — they don’t carry across from the old link. And the new schedule’s start time must be at least a few minutes in the future or the create is rejected; (Get-Date).Date.AddDays(1) gives you tomorrow at exactly midnight local, which satisfies both conditions.

Path B: Azure Logic App

Logic Apps are the friendlier half of this story: the Recurrence trigger is genuinely editable in place. No create-relink-retire dance.