-
Notifications
You must be signed in to change notification settings - Fork 192
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
Comments
Related issue: #3147 |
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. |
Thanks @timayabi2020, a downgrade to 2.25.0 did resolve the issue as a workaround. |
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.... |
Workaround:
|
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.* |
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 |
@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. |
@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 |
@svrooij Just a fellow MVP. |
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. |
@joshjwlvn Have you also added Microsoft Graph PowerShell modules to your Runtime environment? |
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? |
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/ |
Upgrade to version 2.26.1 which is compatible with the 7.2 run time environment in Azure runbooks. |
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 But when I run the code that's basically Connect-MgGraph -Identity I see: 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 I can't see anything that could be a problem with such an uncomplicated runbook. Any ideas? |
I tested with a different automation account (same Azure account) using V2.25 and PowerShell 7.2 and all worked properly. |
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". |
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: |
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. |
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. |
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. |
Same issue here. Recently upgraded our runbooks from 5.1 to 7.2. A couple weeks after that, we started getting the 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 EDIT: Workaround
|
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. |
@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. 😜 |
@JakeMoe are the runbooks set to 7.1 or 7.2? That needs to match what you set when uploading the module. |
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. |
@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. |
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. |
You can revert to a previous versions with powershell instead of having to download it :
|
@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. |
Just chiming in to confirm that this is still an issue in module version |
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
Microsoft.Graph
Microsoft.Graph.Authentication
Microsoft.Graph.Teams
Connect-AzAccount -Identity
Connect-MgGraph -Identity
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
```The text was updated successfully, but these errors were encountered: