tomasrudh / autoshutdownschedule Goto Github PK

Describe the bug
In the update to use managed identities, if the subscription resides in an environment that is not the Azure public cloud (i.e. azure.com) then the Connect-AzAccount will fail due to a cross cloud request.

For example, I updated the script from 3.6 to 3.8. Our cloud is AzureUSGovernment. (azure.us)

Connect-AzAccount : ClientCertificateCredential authentication failed: AADSTS900382: Confidential Client is not supported in Cross Cloud request.

To Reproduce
Run the workbook in a cloud that is not the default public cloud with a system or user-managed identity.

Expected behavior
Should work as expected, but you will need to specify environment.

Additional context
I will submit a PR shortly to resolve this issue.

I couldn't find any mention of License, is it open source and free for use?

Hello,

Thank you for this very practical script.
I want to use the Managed Identity system but I am getting the following error.

I think he can't do this step:

    $ManagedIdentityId = Get-AutomationVariable -Name "Managed Identity ID" -ErrorAction Ignore
    $RunAsConnection = Get-AutomationConnection -Name "AzureRunAsConnection" -ErrorAction Ignore
    if ($ManagedIdentityId -eq 'System') {
        Write-Output ("Logging in to Azure using the system managed identity...")
        if ($AzureSubscriptionName.Length -eq 0) {
            throw "No subscription indicated"
        }
        Connect-AzAccount -Identity -Subscription $AzureSubscriptionName -EnvironmentName $AzureEnvironmentName > $null
    }

What do I need to do to make the Managed Identity ID work?

Thank you for your help

Describe the bug
When we associate the runbook to a Azure Schedule, the Azure schedule allows us to pass the parameters to the script. We had passed the timezone parameter via the schedule to the runbook.

What happens is, when the script prints the first line mentioning the timezone, it pick it up from the parameter that has been placed in the schedule config, but when the script parses the parameter of the actual tag, it does not consider the time zone parameter and assumes UTC.

Please see the attached screenshot, showing the AEST format in the first line, but then considering the UTS for calculating the day.

If we explicitely mention the Time Zone parameter to AEST, then the script works fine.

To Reproduce
Steps to reproduce the behavior:

1. Create an Azure workbook and use the powershell script
2. Attach a schedule and pass the parameter to the script for the Timezone parameter
3. Execute the script
4. The evaluation of Start/Stop will be done on UTS rather than the timezone specified on the schedule config

Running into an issue with my tags not working. I am getting a Invalid tag message but cannot figure out what the issue is. I have tried multiple formats. Below is the tag I am using and the error message.

AutoShutdownSchedule : 7 PM -> 7 AM, Saturday, Sunday
Invalid tag: '7 PM -> 6 AM, Saturday, Sunday'. Skipping this VM

Describe the bug
When you specify a tag that includes days of the week E.g., '18:00->07:00,Saturday,Sunday'. The time-range (18:00->-7:00) is correctly evaluated using the time zone configured in the TZ variable. However, the days of the week (Saturday, Sunday) ignore the time zone and are evaluated as UTC. In my case TZ is set to 'New Zealand Standard Time' (UTC+13) so this is a major issue, the VMs don't shutdown until 1PM on Saturday.

To Reproduce
Steps to reproduce the behavior:

1. Enable the autoshutdownschedule runbook
2. Set a custom time zone using the TZ parameter
3. Add a tag to a VM including days of the week

Expected behavior
The VM should shutdown at 00:00 according to the time zone in TZ on the specified day.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
The problem code block is below. Notice that 'Get-Date' will always return UTC unless it is modified with Get-Date.AddHours(X).

# If specified as day of week, check if today
if ([System.DayOfWeek].GetEnumValues() -contains $TimeRange) {
    if ($TimeRange -eq (Get-Date).DayOfWeek) {
        $parsedDay = Get-Date "00:00"
   }

I have hacked it to work for my scenario as below by adding 13 hours for NZST.

# If specified as day of week, check if today
if ([System.DayOfWeek].GetEnumValues() -contains $TimeRange) {
    if ($TimeRange -eq ((Get-Date).AddHours(13)).DayOfWeek) {
        $parsedDay = (Get-Date "00:00").Addhours(13)
    }

A proper solution is needed to always adjust Get-Date output according to the UTC offset required by the configured time zone.