Connect-AZAccount -Identity problem

JohnSebastian-3934 441 Reputation points
2022-12-12T21:59:20.717+00:00

I'm trying to use a System Assigned Managed Identity with my Azure Automation Account. I have the System Defined Managed Identity tied to my Automation Account and I have granted it the ability to deallocate/start/restart VMs in my Subscription.

I am now reading and following this documentation: https://learn.microsoft.com/en-us/azure/automation/enable-managed-identity-for-automation

According to the documentation, the suggestion to connect to the Managed Identity uses this code:

Ensures you do not inherit an AzContext in your runbook

Disable-AzContextAutosave -Scope Process

Connect to Azure with system-assigned managed identity

$AzureContext = (Connect-AzAccount -Identity).context

set and store context

$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext

When I run the above code in my runbook, I get this error when executing the statement: $AzureContext = (Connect-AzAccount -Identity).context

Could not convert string to DateTimeOffset: 1670968014. Path 'expires_on', line 1, position 1555.

I have no idea how to debug this. I'm trying this in the Test Pane of the Azure Automation Runbook. It is really a horrible debugging experience. I see no way to try and figure out what is going on.

Can someone help?

Azure Automation
Azure Automation
An Azure service that is used to automate, configure, and install updates across hybrid environments.
1,359 questions
0 comments No comments
{count} vote

Accepted answer
  1. Rahul Sharma 76 Reputation points
    2022-12-14T15:07:00.593+00:00

    Hello John Sebastian

    Connect to Azure with an authenticated account for use with cmdlets from the Az PowerShell modules.

    Syntax

    Connect-AzAccount
    [-Environment <String>]
    [-Tenant <String>]
    [-AccountId <String>]
    [-Subscription <String>]
    [-AuthScope <String>]
    [-ContextName <String>]
    [-SkipContextPopulation]
    [-MaxContextPopulation <Int32>]
    [-UseDeviceAuthentication]
    [-Force]
    [-Scope <ContextModificationScope>]
    [-DefaultProfile <IAzureContextContainer>]
    [-WhatIf]
    [-Confirm]
    [<CommonParameters>]

    The Connect-AzAccount cmdlet connects to Azure with an authenticated account for use with cmdlets from the Az PowerShell modules. You can use this authenticated account only with Azure Resource Manager requests. To add an authenticated account for use with Service Management, use the Add-AzureAccount cmdlet from the Azure PowerShell module. If no context is found for the current user, the user's context list is populated with a context for each of their first 25 subscriptions. The list of contexts created for the user can be found by running Get-AzContext -ListAvailable. To skip this context population, specify the SkipContextPopulation switch parameter. After executing this cmdlet, you can disconnect from an Azure account using Disconnect-AzAccount. Apart from this if you want to learn something new course then rails certification. This includes features, MVC, Router, Scaffolding, Views, the Hello World example, bundlers, migrations, layout, the CRUD example, interview questions, etc. covered in this course.

    Thanks & Regards,
    RahulSharma


3 additional answers

Sort by: Most helpful
  1. JohnSebastian-3934 441 Reputation points
    2022-12-14T14:43:45.393+00:00

    Hello,
    I have this figured out.
    The Modules screen is a bit confusing. There is no indicator on the main screen as to which modules were manually updated vs which ones were installed when the main Az module was either installed or updated. According to the documentation as I understand it, if you have manually updated some of the sub-modules under Az (like Az.Compute or any of the ones it is complaining about in the previous screen I posted), then the update of the Az module will NOT overwrite or update any of those "custom" updates you have made. Unfortunately there is no easy way to know from the Modules screen which ones were manually upgraded beyond looking at each module's version number. Since there are so many sub-modules this is not an easy task.

    The documentation suggests to Delete the module that you upgraded manually and then re-upgrade the Az module. Once again, from the main Modules screen, there is no indicator about which modules can easily be deleted. You have to open them one at a time and see whether or not the Delete button is active. So in my case, as I started going looking at each module one at a time, some of them had the Delete button activated and some had it greyed out. It turned out that all of the ones listed in my previous screen had the Delete button activated so I removed each one of them. Once I did this, I tried to upgrade the Az module again but since the module was already at 6.4.0, the option to upgrade was greyed out. So I was not able to re-attempt a module upgrade as the documentation suggests. However, after I removed Az.Automation, Az.Compute, Az.KeyVault, Az.OperationalInsights, Az.PolicyInsights, Az.Storage and Az.Resources (all the ones that it complained about), even without upgrading the Az main module, my runbook worked.

    I think there is a ton of room for improving the user experience here on managing modules. I'll also mention that I don't ever remember upgrading any of the above mentioned modules in my environment which makes it doubly irritating and confusing to me as the end user. I'm the only one working with run-books and automation in my environment so I would probably have remembered this. Anyway, if it were easier to identify which modules are deletable and have been manually upgraded from the base version that comes with the main Az module, it would have been much easier to figure this all out.

    Thanks for responding. This issue is now closed.

    1 person found this answer helpful.

  2. Stanislav Zhelyazkov 27,716 Reputation points MVP Volunteer Moderator
    2022-12-13T11:27:47.067+00:00

    Hi,
    Please check two things:

    • that you have imported latest Az.Accounts module
    • you are using runbook of type PowerShell.

    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.


  3. JohnSebastian-3934 441 Reputation points
    2022-12-13T17:45:52.387+00:00

    I am using Powershell in Azure automation yes.
    I've clicked the Update Az Modules in my automation account. I'm running Runtime version 5.1 with Module version 6.4.0
    Issuing $psversiontable from the runbook returns this when I execute it:

    Name Value

    ---- -----

    PSVersion 5.1.15063.726

    PSEdition Desktop

    PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}

    BuildVersion 10.0.15063.726

    CLRVersion 4.0.30319.42000

    WSManStackVersion 3.0

    PSRemotingProtocolVersion 2.3

    SerializationVersion 1.1.0.1

    I'm finding the Azure Automation environment to be an astounding confusing environment to work in.
    According to my list of modules, I have Az version 6.4.0 installed. This appears to be installed under the Runtime version 5.1.
    I also have Runtime version 7.1 installed with Az module version 8.0.0.
    I'm really unclear how to specify which runtime environment to use from the runbook that I'm working on but as I have shown above, it appears that my runbook is using a 5.1 runtime environment.

    If I also add the following command after the $psversion table command:
    $psversiontable
    Get-InstalledModule -Name Az

    and execute the runbook, I get this message:

    No match was found for the specified search criteria and module names 'Az'.

    So, I then add the import-module az to the beginning of my powershell script under the assumption that I need to load the Az module. So the code looks like this now:
    import-module Az
    $psversiontable
    Get-InstalledModule -Name Az

    When I execute the runbook, it then returns:

    The specified module 'Az.Automation' with version '1.7.1' was not loaded because no valid module file was found in any module directory.
    The specified module 'Az.Compute' with version '4.17.0' was not loaded because no valid module file was found in any module directory.
    The specified module 'Az.KeyVault' with version '3.5.0' was not loaded because no valid module file was found in any module directory.
    The specified module 'Az.OperationalInsights' with version '2.3.0' was not loaded because no valid module file was found in any module directory.
    The specified module 'Az.PolicyInsights' with version '1.4.1' was not loaded because no valid module file was found in any module directory.
    The specified module 'Az.Resources' with version '4.3.1' was not loaded because no valid module file was found in any module directory.
    The specified module 'Az.Storage' with version '3.11.0' was not loaded because no valid module file was found in any module directory.

    Name Value

    ---- -----

    PSVersion 5.1.15063.726

    PSEdition Desktop

    PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}

    BuildVersion 10.0.15063.726

    CLRVersion 4.0.30319.42000

    WSManStackVersion 3.0

    PSRemotingProtocolVersion 2.3

    SerializationVersion 1.1.0.1

    No match was found for the specified search criteria and module names 'Az'.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.