Closed joezuchora closed 2 years ago
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @zjalexander
Ok, I spoke to the developers. This is technically intentional because many users do not expect PowerShell to pass in DateTimeOffset, but clearly the behavior here is not any better. I filed an internal tracking bug (5312306) for this but it needs to be prioritized against other work. We don't have an ETA for this right now. Let me look into our documentation and be sure it expresses the correct behavior.
Ok, I spoke to the developers. This is technically intentional because many users do not expect PowerShell to pass in DateTimeOffset, but clearly the behavior here is not any better. I filed an internal tracking bug (5312306) for this but it needs to be prioritized against other work. We don't have an ETA for this right now. Let me look into our documentation and be sure it expresses the correct behavior.
Thank you @zjalexander! Some updated examples would be really helpful in the meantime.
I have an open ticket with Microsoft for this issue as well. I need to open a new one I found today with the -RebootSettings for Linux schedules. No matter what value you give -RebootSettings, it always sets it to the default IfRequired. Anyway, thanks for the detailed GitHub post. I am hoping they fix this soon.
Sorry for the delay @jzuchora87 - had to wrap my head around this. Now that I got it I am asking the writers to update the docs as well.
You can pass in UTC and no timezone. So to get it working:
$startTime = ((Get-Date).AddMinutes(10)).ToUniversalTime()
$rg = "resourcegroup"
$aa = "automationaccount"
$guid = New-Guid
$schedule = New-AzAutomationSchedule -ResourceGroupName $rg `
-AutomationAccountName $aa `
-Name ("OFFSETTIME-"+ $guid ) `
-StartTime $startTime `
-OneTime `
-ForUpdateConfiguration
$target = "/subscriptions/xxx-xxx-xxx-xxx/resourceGroups/ContosoMgmt/providers/Microsoft.Compute/virtualMachines/vm1"
$sucOffset = New-AzAutomationSoftwareUpdateConfiguration `
-Schedule $schedule `
-Windows `
-ResourceGroupName $rg `
-AutomationAccountName $aa `
-AzureVMResourceId $target `
-Duration (New-TimeSpan -Hours 2) `
-RebootOnly
Write-Output "Start time: $startTime"
Write-Output "ScheduleConfiguration: $($sucOffset.ScheduleConfiguration.StartTime) "
Which finally gives me a schedule configuration which is 7 hours ahead but in the +0 timezone for UTC:
Start time: 09/25/2019 21:07:02
ScheduleConfiguration: 09/25/2019 21:07:00 +00:00
e: played around to make it a bit simpler
I had problems creating a schedule in UTC+2 for a fixed day of the month. The desired time (01:00) would be set to 23:00 when being converted to UTC while the day would stay the same since it is fixed (second Thursday of the month). That would result in the schedule time being 2020-05-14 23:00 instead of 2020-05-14 01:00. Here is my solution, maybe it will help someone else:
$TestSchedule = New-AzAutomationSchedule -ResourceGroupName "HHA_CENTRAL_CORE_AUTO_1" `
-AutomationAccountName "HHA-CENTRAL-CORE-AUTO-ACC-1" `
-Name "Test2" `
-StartTime (Get-Date "01:00+00:00").AddHours(24) `
-DayOfWeekOccurrence "Second" `
-DayOfWeek "Thursday" `
-MonthInterval 1 `
-ForUpdateConfiguration `
-TimeZone "Europe/Berlin"
PG team is actively looking into this issue and will provide update once it is fixed.
Currently, team is busy with other high priority items and this would be picked up in CY2021 Q1.
Any update on this? This still seems to be an issue with the current Az module v5.5.0 Also is there a way to query for a list of valid TimeZone strings that can be used with this command? I am trying to use the Windows Time Zone IDs from [System.TimeZoneInfo]::GetSystemTimeZones() but it is ignored and the schedules are converted to UTC.
Any update?
@vikram-m Do you have any updates on this issue.
The schedule's time zone is working fine now. The start time in debug info response is shown by adding the current time zone of the user.
You can check the actual schedule config using - $suc1 = New-AzAutomationSoftwareUpdateConfiguration -ResourceGroupName $rgName -AutomationAccountName $aaName -Schedule $sch1 -Windows -AzureVMResourceId $cidl3 -IncludedUpdateClassification $updates -Duration $duration $suc1.ScheduleConfiguration
You can also check the schedule start time in the softwareUpdateConfigurations using this api. - https://docs.microsoft.com/en-us/rest/api/automation/software-update-configurations/get-by-name?tabs=HTTP
Description
TimeZone is ignored in New-AzAutomationSoftwareUpdateConfiguration.
I first create a schedule in EST - $sch1
I then use that as in input into New-AzAutomationSoftwareUpdateConfiguration and magically 4 hours are added to the schedule and it's updated. You can see the results in the response body that the startTime has magically changed to 10PM when it should be 6PM as it is in the schedule.
Steps to reproduce
Environment data
Module versions
Debug output
Error output