Skip to content

Microsoft.Graph.Authentication fails in Azure Automation Account due to a dependency on System.Runtime 8.0.0.0 #3151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
erobillard opened this issue Feb 20, 2025 · 34 comments

Comments

@erobillard
Copy link

Describe the bug

The following 2 lines fail in an Azure Automation Account Runbook (7.2 runtime environment):
Connect-AzAccount -Identity
Connect-MgGraph -Identity

With the error:
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

This was working with the following assemblies all on 2.25.0:
Microsoft.Graph
Microsoft.Graph.Authentication
Microsoft.Graph.Teams

Today the same lines fail with a tenant running these 3 DLLs on version 2.26.0

Expected behavior

The code should authenticate to Graph. All other Runbooks in this same Azure Automation Account succeed when authenticating with a client secret to retrieve a token, i.e.:

$response = Invoke-RestMethod -Method Post -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -ContentType "application/x-www-form-urlencoded" -Body $body

As soon as the Connect-MgGraph is required (in this case to add a member to a Shared channel in MS-Teams), authentication fails with the error as described.

How to reproduce

  1. Create and configure an Azure Automation Account to authenticate as a managed identity. Configure as Powershell, 7.2 runtime environment.
  2. Install these modules:
    Microsoft.Graph
    Microsoft.Graph.Authentication
    Microsoft.Graph.Teams
  3. Confirm the installed version is 2.26.0
  4. Create and execute a runbook with the lines:
    Connect-AzAccount -Identity
    Connect-MgGraph -Identity
  5. Watch it fail.

SDK Version

2.26.0

Latest version known to work for scenario above?

2.25.0

Known Workarounds

None I can find.

Debug output

Click to expand log ```
</details>


### Configuration

Azure Powershell 7.2 Runbook

### Other information

Someone compiled this with a dependency on System.Runtime 8.0 rather than the latest available to an Azure  Automation Account, and there's no way to force the version (i.e., set a -RequiredVersion parameter). 
@erobillard erobillard added status:waiting-for-triage An issue that is yet to be reviewed or assigned type:bug A broken experience labels Feb 20, 2025
@erobillard
Copy link
Author

Related issue: #3147
In that case it appears that updating PowerShell resolved the issue, I don't believe this is an option with Azure Automation (7.2 it is).

@timayabi2020
Copy link
Contributor

Hi @erobillard apologies for that experience. There is an existing issue here azureautomation/runbooks#112, requesting that team to provide an option for 7.4. Meanwhile, you can downgrade to v2.25.0 or use Azure functions.

@timayabi2020 timayabi2020 self-assigned this Feb 21, 2025
@timayabi2020 timayabi2020 added Azure Automation and removed status:waiting-for-triage An issue that is yet to be reviewed or assigned labels Feb 21, 2025
@erobillard
Copy link
Author

Thanks @timayabi2020, a downgrade to 2.25.0 did resolve the issue as a workaround.

@svrooij
Copy link

svrooij commented Feb 21, 2025

Azure Automation is capped at PowerShell 7.2 which is built upon dotnet 6 which is officially out of support since Nov 12th 2024 🤔

I cannot believe they still don't provide PowerShell 7.4 (dotnet8) for Azure Automation....

@alpixdotro
Copy link

Workaround:

  1. Save-Module -Name Microsoft.Graph.Authentication -Path C:\temp\Modules -Repository PSGallery -MaximumVersion 2.25.0
  2. ZIP it
  3. Upload to Azure Automation, select runtime 7.2, and wait for import. It will overwrite 2.26.0 version and functionality will be restored.

@erobillard
Copy link
Author

You can also download modules from https://www.powershellgallery.com/packages/Microsoft.Graph/2.25.0

Rename the nupkg file to, for example Microsoft.Graph.zip, or remember to change the name as you upload it to Modules in the Azure Automation Account. Version 2.25.0 worked for me, you shouldn't need to go any earlier.

I also find things to be more stable when version numbers match within a namespace like Microsoft.Graph.*

@alexandair
Copy link
Contributor

A workaround is to enable Runtime environment experience (in public preview) and create a custom Runtime environment.

  1. Select Overview and then select Try Runtime environment experience.
  2. Under Process Automation, you will get the Runtime Environments (Preview)
  3. Create a new RE. Pick PowerShell 7.4 as runtime version and add needed Microsoft Graph PowerShell v2.26 modules as packages.
  4. Assign newly created custom Runtime environment to your runbooks that stopped working after you updated to Microsoft Graph PowerShell 2.26.

@svrooij
Copy link

svrooij commented Feb 24, 2025

A workaround is to enable Runtime environment experience (in public preview) and create a custom Runtime environment.

@alexandair let me understand correctly that Microsoft is suggesting everybody to use a public preview feature? Can't you speedup the GA process for Azure Automation?

Personally I don't care about rather or not using preview features, but there're a lot of companies that have policies against using preview features in production.

It has been an eyesore that Azure Automation (without any preview feature) only supports a 4 year old PowerShell version, which is End of life since 12th of November 2024

@alexandair
Copy link
Contributor

@svrooij I don't know what Microsoft suggests. I've mentioned that workaround for people who could use it.

When Microsoft fixes the problem, releases 7.4 runtime as GA, people can revert to that Runtime environment.

We live in a constant "public preview" world even when they call it GA. Microsoft Graph PowerShell 2.26 is another example of that. It's a GA release with quality lower than public preview releases. The idea to release a minor release introducing a breaking change based on the requirement of major .NET version is beyond belief.

@svrooij
Copy link

svrooij commented Feb 24, 2025

@alexandair sorry I saw a "contributor" badge on top of your reaction so I assumed incorrectly that you were a Microsoft employee, and that you might be able to reach the folks at Azure Automation to clear things up

@alexandair
Copy link
Contributor

@svrooij Just a fellow MVP.
I've contacted the Azure Automation team. Hopefully, they will respond soon.

@joshjwlvn
Copy link

Is there an update on this issue. I've tried downgrading the Microsoft.graph modules to v2.25.0 and also tried using Powershell Runtime Environments (Preview) v7.4 in the Azure Automation Account. But the commands are not getting executed.

@alexandair
Copy link
Contributor

@joshjwlvn Have you also added Microsoft Graph PowerShell modules to your Runtime environment?
You need Microsoft.Graph.Authentication and any other module that contains your Microsoft Graph commands.

@erobillard
Copy link
Author

Agree, we need a supported solution for PRD services. Azure Automation is an otherwise excellent service but the test cases don't catch this sort of thing before updates are deployed, the underlying version of .NET is unsupported, and workarounds are unsupported, then it's effectively dead to every company that operates in a professional manner. Does the Azure Automation team still exist in any meaningful way and do they have budget to bring the service up to a supported state?

@12Knocksinna
Copy link

FWIW, to raise visibility.

Microsoft Graph PowerShell SDK Runs into Choppy Waters

A bunch of problems with V2.26 of the Microsoft Graph PowerShell SDK V2.26 make the software unusable. Not only did Microsoft do a horrible job of testing the new release before making it available to customers, but they also failed to communicate the level of change in the new SDK and how it could impact Azure Automation runbooks.

https://office365itpros.com/2025/02/25/graph-sdk-v2-26-issues/

@timayabi2020
Copy link
Contributor

Upgrade to version 2.26.1 which is compatible with the 7.2 run time environment in Azure runbooks.

@timayabi2020 timayabi2020 added the status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close label Feb 26, 2025
@12Knocksinna
Copy link

12Knocksinna commented Feb 26, 2025

I upgraded to V2.26.1 and a very simple 7.2 runbook failed because of an invalid JWT token.

I removed the V2.26 modules (Authentication and Users) from the automation account. I imported Authentication and Users with V2.26.1

Image

But when I run the code that's basically

Connect-MgGraph -Identity
Get-MgUser | ft DisplayName

I see:

Image

Application permission for User.Read.All has been assigned to the service principal for the automation account.

Managed identities are enabled for the automation account

Image

I can't see anything that could be a problem with such an uncomplicated runbook. Any ideas?

@timayabi2020
Copy link
Contributor

Something is definitely wrong with 7.2 environment on AARB because I've tested with a much older version which I know was working (2.24.0) and getting "Invalid JWT access token" result.

Image Image

Is there anyone getting a different result?

@12Knocksinna
Copy link

I tested with a different automation account (same Azure account) using V2.25 and PowerShell 7.2 and all worked properly.

@JakeMoe
Copy link

JakeMoe commented Feb 28, 2025

I'm having the same issue. Created a new automation account which imported v2.26.1 and Connect-MgGraph -Identity returns "Invalid JWT access token". Tested in an existing automation account which still had v2.24, and it worked fine. Upgraded existing automation account to v2.26.1 and it now gets the same error "Invalid JWT access token".

@o-l-a-v
Copy link

o-l-a-v commented Mar 4, 2025

Edit: Never mind, I did not CTRL+F before posting. 🤦🏻‍♂️

Have anyone tried using PowerShell v7.4? It's available if you create a custom runtime environment.

It's not announced or documented anywhere, only official mentions I know of are found in previous community calls.

I've asked for more info on a GA in next community call:

@erobillard
Copy link
Author

A supported solution remains unavailable though a Preview runtime environment (7.4) is now available to resolve the problem of the issue happening with new deployments.

@JakeMoe
Copy link

JakeMoe commented Mar 5, 2025

I've asked for more info on a GA in next community call:

FWIW, I remember when the v7.1 preview was released to Automation Accounts, and I contacted support to get a GA timeframe. They told me within a few months. It ended up being 3 or 4 years when they finally announced that 7.1 was going from preview straight to EOL. Don't rely too much on what they tell you.

This is why I'm reluctant to use the runtime experience and 7.4 now; I don't want to wind up in that sort of unsupported state again for such an extended period.

Also, why is this bug still tagged "no-recent-activity"? We're still actively talking about it, and hoping someone official will reply with some sort of timeline or other info about what's going on with this.

@halukpn
Copy link

halukpn commented Mar 7, 2025

We are updating our runbook scripts from Azure AD to Graph, only to find we can't use the latest versions of PowerShell and Graph available in the runbook. This is not a good experience.

@plmcgrn
Copy link

plmcgrn commented Mar 10, 2025

Same issue here. Recently upgraded our runbooks from 5.1 to 7.2. A couple weeks after that, we started getting the Invalid JWT access token error when calling Connect-MGGraph -Identity -ClientId xxxx.

I'm not willing to move to the new preview environment feature because I'd have to manage our entirely by hand due to them preventing the upload of our own PowerShell modules, thus causing us to have to re-tool our CI/CD pipelines because they also STILL don't support Source Control sync of PowerShell 7.2 runbooks. Our CI/CD is a workaround for that lack of modern version support.

So in lieu of a fix or non-preview workaround, I guess we're moving runbooks that need Graph back to PowerShell 5.1...

This is all on microsoft.graph.authentication 2.26.1

EDIT: Workaround

  1. Download version 2.25.0 of each Graph module you need from powershellgallery.com
  2. Rename the .nupkg files to .zip
  3. Upload them to Azure Automation. Note, you need to rename the module before submitting or it'll append the version number to the name, and fail to replace the existing (broken) 2.26.x modules.
  4. Runbooks should work again

@halukpn
Copy link

halukpn commented Mar 11, 2025

Same issue here. Recently upgraded our runbooks from 5.1 to 7.2. A couple weeks after that, we started getting the Invalid JWT access token error when calling Connect-MGGraph -Identity -ClientId xxxx.

I'm not willing to move to the new preview environment feature because I'd have to manage our entirely by hand due to them preventing the upload of our own PowerShell modules, thus causing us to have to re-tool our CI/CD pipelines because they also STILL don't support Source Control sync of PowerShell 7.2 runbooks. Our CI/CD is a workaround for that lack of modern version support.

So in lieu of a fix or non-preview workaround, I guess we're moving runbooks that need Graph back to PowerShell 5.1...

This is all on microsoft.graph.authentication 2.26.1

EDIT: Workaround

  1. Download version 2.25.0 of each Graph module you need from powershellgallery.com
  2. Rename the .nupkg files to .zip
  3. Upload them to Azure Automation. Note, you need to rename the module before submitting or it'll append the version number to the name, and fail to replace the existing (broken) 2.26.x modules.
  4. Runbooks should work again

For what it's worth, we moved to preview environment which was very easy, has solved all the issues and it remains stable, but totally understand why you may not want to do that.

@JakeMoe
Copy link

JakeMoe commented Mar 11, 2025

@halukpn Did you do anything other than what you listed? I've downloaded 2.25 of the 4 modules I need, renamed as zip, uploaded as 7.2 modules and renamed them without the version number, but my 7.2 runbooks can't find the modules. I get an error like "no modules found with that name in any directory" when I try to import them, and Get-Modules -ListAvailable doesn't show them. I've even extracted the nupkg files, removed the Nuget packaging specific files so they're just the module files, re-zipped manually and re-uploaded, with the same error.

And FWIW, I was one of those early adopters of the 7.1 Preview (because I needed PS Core for some of the modules), which instead of quickly being tested and released, was stuck in an unsupported Preview state for years. Every time I'd have a problem, I'd get resistance from MS support, telling me it's not supported, even though they didn't have supported solutions to modules that needed PS Core. So no, I'm not keen to jump back into an unsupported preview. 😜

@plmcgrn
Copy link

plmcgrn commented Mar 11, 2025

@JakeMoe are the runbooks set to 7.1 or 7.2? That needs to match what you set when uploading the module.

@halukpn
Copy link

halukpn commented Mar 11, 2025

@halukpn Did you do anything other than what you listed? I've downloaded 2.25 of the 4 modules I need, renamed as zip, uploaded as 7.2 modules and renamed them without the version number, but my 7.2 runbooks can't find the modules. I get an error like "no modules found with that name in any directory" when I try to import them, and Get-Modules -ListAvailable doesn't show them. I've even extracted the nupkg files, removed the Nuget packaging specific files so they're just the module files, re-zipped manually and re-uploaded, with the same error.

And FWIW, I was one of those early adopters of the 7.1 Preview (because I needed PS Core for some of the modules), which instead of quickly being tested and released, was stuck in an unsupported Preview state for years. Every time I'd have a problem, I'd get resistance from MS support, telling me it's not supported, even though they didn't have supported solutions to modules that needed PS Core. So no, I'm not keen to jump back into an unsupported preview. 😜

I a Runtime environment using PowerShell 7.4, then added the latest Graph modules from the gallery (2.26.1). Then update the runbook to use the 7.4 runtime environment. Everything works.

@JakeMoe
Copy link

JakeMoe commented Mar 11, 2025

@plmcgrn Yeah, I've moved all but a couple of test runbooks off 7.1 at this point, they're all on the supported 7.2 environment now. And yeah, I presumed the version set during upload had to match the environment, so they'd be available to that environment. Might have a look again today, maybe it was just "the cloud" needing me to wait a little longer...

@halukpn Ah, I thought you said you got it working with the old 2.25 modules on the 7.2 environment. I'm not moving to another preview at this time. And looking back, I see the comment I was actually replying to was plmcgrn, who replied already. ;-) Sorry, my bad.

I don't suppose anyone from the actual team that are working on this issue can chime in? The "fix" for 2.26 to 2.26.1 came out fairly quickly; any idea how long until the next "fix" is released? Would be good to know if it's likely to be sorted out soon, or if I need to make some longer-term workarounds.

@erobillard
Copy link
Author

Can anyone confirm whether the default behaviour in a new Automation Account will now result in working code, or whether the default runtime and module versions still produce issues? While the original and underlying issue appears unresolved, I'd consider this closed if someone can come in, choose a supported environment, add modules from the built-in list, and these steps produce a working solution.

@cmicck
Copy link

cmicck commented Mar 20, 2025

Same issue here. Recently upgraded our runbooks from 5.1 to 7.2. A couple weeks after that, we started getting the Invalid JWT access token error when calling Connect-MGGraph -Identity -ClientId xxxx.

I'm not willing to move to the new preview environment feature because I'd have to manage our entirely by hand due to them preventing the upload of our own PowerShell modules, thus causing us to have to re-tool our CI/CD pipelines because they also STILL don't support Source Control sync of PowerShell 7.2 runbooks. Our CI/CD is a workaround for that lack of modern version support.

So in lieu of a fix or non-preview workaround, I guess we're moving runbooks that need Graph back to PowerShell 5.1...

This is all on microsoft.graph.authentication 2.26.1

EDIT: Workaround

  1. Download version 2.25.0 of each Graph module you need from powershellgallery.com
  2. Rename the .nupkg files to .zip
  3. Upload them to Azure Automation. Note, you need to rename the module before submitting or it'll append the version number to the name, and fail to replace the existing (broken) 2.26.x modules.
  4. Runbooks should work again

You can revert to a previous versions with powershell instead of having to download it :

$moduleName = 'Microsoft.Graph.Authentication'
$moduleVersion = '2.25.0'
New-AzAutomationModule -AutomationAccountName 'AUTOMATIONACCOUNT' -ResourceGroupName 'RGNAME' -Name $moduleName -ContentLinkUri "https://www.powershellgallery.com/api/v2/package/$moduleName/$moduleVersion" -RuntimeVersion '7.2'

@JakeMoe
Copy link

JakeMoe commented Mar 31, 2025

$moduleName = 'Microsoft.Graph.Authentication'
$moduleVersion = '2.25.0'
New-AzAutomationModule -AutomationAccountName 'AUTOMATIONACCOUNT' -ResourceGroupName 'RGNAME' -Name $moduleName -ContentLinkUri "https://www.powershellgallery.com/api/v2/package/$moduleName/$moduleVersion" -RuntimeVersion '7.2'

@cmicck Love your work, this finally worked for me. My test account can use Graph once again.

Would love to hear an update from the product team; is this being worked on, is there any further info about it, any guesstimate on when we can have a working Microsoft Graph module in Automation Accounts again? The REAL fix would be for Microsoft to finally update the runtime engines to match the latest PowerShell, but who knows if / when that'll happen.

@plmcgrn
Copy link

plmcgrn commented May 15, 2025

Just chiming in to confirm that this is still an issue in module version 2.28.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests