Test-VmPowerSchedule

Every path into the catalogue goes through this, which is why it reports instead of failing at the first problem: somebody validating twelve schedules wants all twelve answers, not the first one. Set-VmPowerSchedule calls it and refuses to store anything that does not pass.

Valid and useful are different questions. A schedule can be well formed and still be one the deployed controller never sees open, because it is sampled on a timer that cannot run more often than hourly: a window narrower than that, or a startGraceMinutes shorter than that. Both come back in Warnings rather than Problem: nothing is wrong with the schedule, but left alone it would do nothing and say nothing about it.

It also checks the things a schema cannot: two schedules with the same name, and a catalogue whose names would not survive being turned into the allowedValues of a policy.

Pass -Detailed to get the expanded schedule back alongside the verdict, which is what Show-VmPowerScheduleCalendar consumes.

Syntax

Test-VmPowerSchedule [-Schedule] <Object[]> [-Detailed] [<CommonParameters>]

Requirements

Parameters

Examples

Example 1

# Validate a catalogue read out of a file before it goes anywhere near a deployment
Get-Content ./catalog.json -Raw | ConvertFrom-Json | Test-VmPowerSchedule | Format-Table Name, Valid, Problem

Example 2

# The one-liner before storing
New-VmPowerSchedule -Name office-hours-ch -TimeZone 'Europe/Zurich' -Weekdays '07:30-18:30' | Test-VmPowerSchedule

Output

• AzureVMPowerManagement.VmPowerScheduleValidation