Repository navigation
Import-Module Microsoft.Graph.Authentication 2.34.0 Error GetTokenAsync #3479
Description
Describe the bug
Import-Module Microsoft.Graph.Authentication
Import-Module : Method 'GetTokenAsync' in type
'Microsoft.Graph.PowerShell.Authentication.Core.Utilities.UserProvidedTokenCredential' from assembly
'Microsoft.Graph.Authentication.Core, Version=2.34.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not
have an implementation.
At line:1 char:1
- Import-Module Microsoft.Graph.Authentication
-
+ CategoryInfo : NotSpecified: (:) [Import-Module], TypeLoadException + FullyQualifiedErrorId : System.TypeLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand
Expected behavior
Import-Module Microsoft.Graph.Authentication does not throw an error
How to reproduce
Import-Module Microsoft.Graph.Authentication
SDK Version
2.34.0
Latest version known to work for scenario above?
2.33.0
Known Workarounds
No response
Debug output
Click to expand log
``` Import-Module Microsoft.Graph.Authentication -Debug VERBOSE: Loading module from path 'C:\Users\a.bohren\OneDrive - Icewolf\Dokumente\WindowsPowerShell\Modules\Microsoft.Graph.Authentication\2.34.0\Microsoft.Graph.Authentication.psd1'.Confirm
Continue with this operation?
[Y] Yes [A] Yes to All [H] Halt Command [S] Suspend [?] Help (default is "Y"): A
VERBOSE: Cannot verify the Microsoft .NET Framework version 4.7.2 because it is not included in the list of permitted
versions.
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\a.bohren\OneDrive -
Icewolf\Dokumente\WindowsPowerShell\Modules\Microsoft.Graph.Authentication\2.34.0\Microsoft.Graph.Authentication.format
.ps1xml'.
VERBOSE: Populating RepositorySourceLocation property for module Microsoft.Graph.Authentication.
VERBOSE: Loading module from path 'C:\Users\a.bohren\OneDrive -
Icewolf\Dokumente\WindowsPowerShell\Modules\Microsoft.Graph.Authentication\2.34.0\Microsoft.Graph.Authentication.dll'.
VERBOSE: Importing cmdlet 'Get-ModuleCmdlet'.
VERBOSE: Importing cmdlet 'Get-ScriptCmdlet'.
VERBOSE: Importing cmdlet 'Connect-MgGraph'.
VERBOSE: Importing cmdlet 'Disconnect-MgGraph'.
VERBOSE: Importing cmdlet 'Add-MgEnvironment'.
VERBOSE: Importing cmdlet 'Get-MgEnvironment'.
VERBOSE: Importing cmdlet 'Remove-MgEnvironment'.
VERBOSE: Importing cmdlet 'Set-MgEnvironment'.
VERBOSE: Importing cmdlet 'Get-MgContext'.
VERBOSE: Importing cmdlet 'Get-MgGraphOption'.
VERBOSE: Importing cmdlet 'Invoke-MgGraphRequest'.
VERBOSE: Importing cmdlet 'Set-MgGraphOption'.
VERBOSE: Importing cmdlet 'Get-MgRequestContext'.
VERBOSE: Importing cmdlet 'Set-MgRequestContext'.
VERBOSE: Importing alias 'Connect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Disconnect-Graph'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Importing alias 'Invoke-GraphRequest'.
VERBOSE: Importing alias 'Invoke-MgRestMethod'.
VERBOSE: Loading module from path 'C:\Users\a.bohren\OneDrive -
Icewolf\Dokumente\WindowsPowerShell\Modules\Microsoft.Graph.Authentication\2.34.0\Microsoft.Graph.Authentication.Core.d
ll'.
Import-Module : Method 'GetTokenAsync' in type
'Microsoft.Graph.PowerShell.Authentication.Core.Utilities.UserProvidedTokenCredential' from assembly
'Microsoft.Graph.Authentication.Core, Version=2.34.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not
have an implementation.
At line:1 char:1
- Import-Module Microsoft.Graph.Authentication -Debug
-
+ CategoryInfo : NotSpecified: (:) [Import-Module], TypeLoadException + FullyQualifiedErrorId : System.TypeLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand
</details>
### Configuration
$PSVersionTable
Name Value
---- -----
PSVersion 5.1.26100.7462
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.26100.7462
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Windows 11 25H2
x64
### Other information
_No response_
Activity
KKing299 commentedon Dec 24, 2025
Gavin Barron (@gavinbarron) / Any other MS rep - This needs to be escalated. Please see below -
I have an Azure DevOps pipeline that utilizes Azure PowerShell task. I don't select "Core" and hence my pipeline keeps on failing with the same error - Method 'GetTokenAsync' in type 'Microsoft.Graph.PowerShell.Authentication.Core.Utilities.UserProvidedTokenCredential' from assembly 'Microsoft.Graph.Authentication.Core, Version=2.34.0.0, Culture=neutral, PublicKeyToken=*' does not have an implementation
If I select core then it uses 7.4.13 and has no issues. Please fix this for version - 5.1
Please fix this ASAP!
satishes43 commentedon Dec 24, 2025
I am also facing same error. It's messed up all authentication.
##[error]Failed to import Azure PowerShell modules: Method 'GetTokenAsync' in type 'Microsoft.Graph.PowerShell.Authentication.Core.Utilities.UserProvidedTokenCredential' from assembly 'Microsoft.Graph.Authentication.Core, Version=2.34.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not have an implementation.
BohrenAn commentedon Dec 25, 2025
Gavin Barron (@gavinbarron)
Here are the Result's for the .NET Framework
PowerShell 5.1
.NET Framework Version: 4.8.1 or later
dotnet --list-runtimes
Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
PowerShell 7.5.4
.NET Framework Version: 4.8.1 or later
dotnet --list-runtimes
Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
The Microsoft.Graph PowerShell Modules are listed as PowerShell 5.1 and higher - so it should simply work there.
In Addition PowerShell 5.1 is on any supported Windows Installation available by default. So it's convinient to just use what's already available there.
In more restricted Evironments you're often not allowed to install additional Software or you don't even have Admin Permissions to install PowerShell 7.x.
Kind Regards
Andres
Yashaswini2210 commentedon Dec 31, 2025
Gavin Barron (@gavinbarron)
Im also facing the same issue in an automation runbook using powershell 5.1, need quick help
Import-Module : Method 'GetTokenAsync' in type
'Microsoft.Graph.PowerShell.Authentication.Core.Utilities.UserProvidedTokenCredential' from assembly
'Microsoft.Graph.Authentication.Core, Version=2.34.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not have
an implementation.
nburton-loginvsi commentedon Dec 31, 2025
Same thing here. PowerShell 5.1 - rolling back the module to 2.33 seems to fix it.
torque1 commentedon Jan 2, 2026
I'm see the same issue but only when the AZ.Accounts module is also loaded.
Environment
Windows 11 24H2 26100.7171
DotNet 4.8.1 (533320)
PowerShell: Windows PowerShell: 5.1.26100.7019
Modules:
Az.Accounts 5.3.1
Microsoft.Graph.Authentication 2.34.0
Scenario 1 – Az.Accounts only (works)
Result:
Successfully connects to Azure
Scenario 2 – Microsoft.Graph.Authentication only (works)
Result:
Successfully connects to Microsoft Graph.
Scenario 3 – Graph first, then Az (Az connection fails)
Result:
Connect-AzAccount fails.
Scenario 4 – Az first, then Graph (Graph module fails to load)
Result:
Microsoft.Graph.Authentication fails to load.
FabienTschanz commentedon Jan 2, 2026
Gavin Barron (@gavinbarron) I did some more analyzing. The issue can be reproduced in Windows PowerShell if the
Microsoft.PowerShell.PSResourceGetmodule is imported before loadingMicrosoft.Graph.Authentication. TheAzure.Coreassembly is loaded from the correct place (the module folder whereMicrosoft.Graph.Authenticationis installed), but it still somehow fails to get the overridden implementation fromMicrosoft.Graph.Authentication.Core.I'll try and do some local troubleshooting with cloning the module. Good exercise for debugging.
FabienTschanz commentedon Jan 2, 2026
Further findings. I managed to track down the issue to the
System.Threading.Tasks.Extensions.dll. If I remove this dll from the dependencies folder whereMicrosoft.PowerShell.PSResourceGetis installed, then it will load it from the location whereMicrosoft.Graph.Authenticationis located and it works. If I don't do that and it is loaded from the PSResourceGet folder, then the issue withGetTokenAsyncand its missing implementation appears. If I replace the version that is in the PSResourceGet with the version from the Graph Authentication module, it works as well (just as if you were to delete it).So it's another one of those issues with dlls that are already loaded but have something different. I have no clue whatsoever what is different, but here are the two versions:
And the second one:
The issue might be because there are now two versions of the same assembly loaded. As an addition to "if only one version is present it works", it doesn't matter if any of the two versions is present. It can be either 4.2.0.1 or 4.2.1.0, doesn't matter as long as not BOTH are present.
Edit: This entire thing works in PowerShell 7 because there, the
System.Threading.Tasks.Extensions.dllis already preloaded through the executable itself:Install PS 5.1-compatible Graph SDK version (v2.23.0) to avoid broken…
gavinbarron commentedon Jan 5, 2026
Thank you Fabien Tschanz (@FabienTschanz) for your excellent work on digging into this. I really appreciate coming back from the break to see this.
Assembly loading and binding in PowerShell is frankly a nightmare. It sounds like what we're hitting here is this case: https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.5#conflicting-with-another-modules-dependencies
To everyone else; torque1, Albert van Nijhuis (@albertvannijhuis), Albert van Nijhuis (@albertvannijhuis), Satish Babu Dasari (@satishes43), KKing299, Yashaswini2210, nburton-loginvsi
As this appears to be an assembly load issue which is happening because the lower version of the System.Threading.Tasks.Extensions assembly is loaded first I need all of you to provide a listing of the assemblies that have been loaded when you encounter this error.
torque1 commentedon Jan 6, 2026
Here are the list of assemblies loaded when I get the issue.
FabienTschanz commentedon Jan 6, 2026
Gavin Barron (@gavinbarron) Duplicate dlls from the answer of torque1:
Again the
System.Threading.Tasks.Extension.dllas well as two more. Did a quick check and the two other dlls don't contribute to the issue, it's still only theSystem.Threading.Tasks.Extensions.dllwhich causes the error. If I copy the one from the Az.Accounts module over to the Microsoft Graph module, I can successfully import it, but if two versions of this specific dll are present, then it fails.jenkegels commentedon Jan 6, 2026
I'm having the same issue trying to register devices to Autopilot. Hower my assemblies output is different from the output above.
The error is thrown after executing the command get-windowsautopilotinfo -online - grouptag XXX
gavinbarron commentedon Jan 6, 2026
jenkegels could you also please provide the modules you have loaded?
Get-Moduleneddington commentedon Jan 6, 2026
jenkegels Gavin Barron (@gavinbarron)
If it's helpful I had to troubleshoot an issue that pertains to this particular issue with Autopilot. Mines a little different though since I do all my Autopilot Enrollment in WinPE Automatically and use the module directly instead of the script.
The WindowsAutopilotIntune Module is a dependency of the of the Get-WindowsAutoPilotInfo Script. When you utilize get-windowsautopilotinfo -online it installs the WindowsAutopilotIntune module and its required dependancies which are 'Microsoft.Graph.Intune', 'Microsoft.Graph.Groups', and 'Microsoft.Graph.Authentication' to which it installs latest versions of. It looks like Microsoft.Graph.Groups and Microsoft.Graph.Authentication get released at the same time as both are 2.34.0. Just having the Authentication Module on 2.33.0 didn't work for me and to resolve the issue, after the WindowsAutopilotIntune Module was installed along with its required dependancies I removed the Microsoft.Graph.Groups 2.34.0 and Microsoft.Graph.Authentication 2.34.0 modules and then installed the previous versions of both that aren't currently having issues 2.33.0. After that everything went back to functioning as expected.
jenkegels commentedon Jan 7, 2026
Gavin Barron (@gavinbarron) the modules listed are:
The commands executed in a clean install OOBE screen are: install-script get-windowsautopilotinfo. That runs fine.
After that the command get-windowsautopilotinfo -online - grouptag XXX throws the same error as the first post.
neddington thanks for your feedback. I'll see if I can get around them.
peterboba commentedon Jan 7, 2026
Similarly to #3479 (comment), we're hitting this issue with Az.Accounts 5.3.1 and Microsoft.Graph.Authentication 2.34.0
jenkegels commentedon Jan 7, 2026
neddington I can confirm that installing versions 2.33 of Microsoft.Graph.groups and Microsoft.Graph.Authentication fixed the issue. We are now able to enroll machines back in Intune using the command get-windowsautopilotinfo. Thank you!
KiranMaji commentedon Jan 7, 2026
Yes, I was facing the same issues while Connect-MgGraph. However, the "Set-MgGraphOption -EnableLoginByWAM $true" or "Set-MgGraphOption -EnableLoginByWAM $false" will not gonna work.
The only solution is - Uninstall the 2.34 module:
"Uninstall-Module -Name Microsoft.Graph.Authentication -Force"
And once you back to the 2.33, all will be works well.
gavinbarron commentedon Jan 7, 2026
If you want to use Windows PowerShell 5.1 and Microsoft.Graph v2.34 with Az.Accounts <=5.3.1 or Microsoft.PowerShell.PSResourceGet <=1.1.1 at present the best fix it to ensure that you import Microsoft.Graph.Authentication before importing & using those additional modules.
This is an unfortunate side effect of how assembly loading is handled in PowerShell when there are multiple modules with dependencies of different versions of the same assembly.
FabienTschanz commentedon Jan 7, 2026
Gavin Barron (@gavinbarron) So no fix will be possible outside of making sure that the Graph module is imported first?
gavinbarron commentedon Jan 16, 2026
Fabien Tschanz (@FabienTschanz) unfortunately the Microsoft Graph PowerShell module has the highest dependency version at present, and as such needs to be the first think imported and executed.
PowerShell uses on demand assembly loading so unless an assembly is explicitly loaded during import then PowerShell won't load the assembly until a code path is executed that requires that assembly. Take a look at this article for a deep dive into this problem: https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.5#conflicting-with-another-modules-dependencies
This is the same root cause as #3394
Likely when Az.Accounts next release they'll bump the version of the impacted assembly and the issue will either be resolved or reversed.
I'm reaching out to folks internally to see if we can coordinate a durable fix for the Microsoft owned auth libraries.
FabienTschanz commentedon Jan 17, 2026
Gavin Barron (@gavinbarron) I'm pretty familiar with how the dependencies are load. Not an expert but traced it a couple of times already. If I were a module developer, I'd try to limit the necessary dependencies to a minimum and only use additional libraries if not possible any other way. I'd expect that you're going with this approach already, don't you? If it is possible to strip one of the libraries and the effort to do so justifies it, then it would benefit the people using the modules by preventing possible conflicts.
Because Windows PowerShell is still the default and PowerShell 7 is not, most users will stick to Windows PowerShell and some applications (like the Local Configuration Manager for Desired State Configuration) have a hard dependency on it. From the Microsoft365DSC team, we are running into those dependency conflicts on almost a monthly basis and it's very much painful because at one point, we have no other choice but to drop support for a combination of workloads.
One example here is SPO and Graph, when we're running those two workloads side-by-side, at least one of them will fail because of the assembly conflicts. No way around it except running them separately. But how can we tell this to the users? Switching to PowerShell 7 is not yet possible and takes more time, especially when we have to make sure that everything still works after doing so. We'd be very happy if there will be some coordination inside Microsoft to minimize these disruptions.
Appreciate the effort, looking forward to what's coming next.
peterboba commentedon Jan 28, 2026
This seems to have been mitigated now when using version 5.3.2 of
Az.Accountsalong with 2.34.0 ofMicrosoft.Graph.Authentication.Jolinda1101 commentedon Feb 3, 2026
Hi team,
I've similar issue. I've upgraded Az.Accounts to version 5.3.2 along with 2.34.0 of Microsoft.Graph.Authentication, but still got the same error. Could you help to advice the other mitigation? Thanks.
robinmalik commentedon Feb 12, 2026
We upgraded from
2.28to2.35.1and unfortunately this broke everything Graph related under PowerShell 5.1 as we can't connect with that.2.33is the fix, pending what I assume is updating every possible calling script to forcefully import the modules.cnschindler commentedon Mar 15, 2026
And the issue still exists in version 2.36 of the module...
BohrenAn commentedon Mar 16, 2026
Christian Schindler (@cnschindler)
Can't confirm. The Problem does not exist anymore in the 2.36 Microsoft.Graph PowerShell Module
$maximumfunctioncount = '32768'
Import-Module Microsoft.Graph
Better load only the Modules you really use
Import-Module Microsoft.Graph.Authentication
If you import the ExchangeOnline Module first - then this happens
Import-Module ExchangeOnlineManagement
The other way around works.
$maximumfunctioncount = '32768'
Import-Module Microsoft.Graph
Import-Module ExchangeOnlineManagement
But AZ PowerShell Module has a Problem then
Kind Regards
Andres
saqib-s commentedon Mar 18, 2026
I am also seeing this issue, recently installed 2.36.0 and it has started to occur.
I have tried removing the Graph modules and reinstalling, but still see the same problem. This is using Windows Powershell.
Get-InstalledModule Microsoft.Graph* | Uninstall-Module -AllVersions -ForceNo issues when using PowerShell 7.
Update*
Found that the issue for me presents itself only in the PowerShell Extension terminal in VS Code, others have seen this too and seem to think it's the way the extension is loading the modules, when using the regular PowerShell terminal windows in VS code I do not see the issue repeat itself.
zaaj commentedon Mar 27, 2026
I'm still feeling stuck on Windows Powershell as well - I need to share my scripts with co-workers, and expecting them to install non-default Powershell is a stretch, especially on servers.
My general use case is to open a Windows Terminal powershell window in the morning, and leave it open all day as I work on issues.
That session may need to connect using Az, MicrosoftTeams, ExchangeOnlineManagement, Microsoft.Graph, ActiveDirectory, PowerCLI - thankfully I've somehow escaped needing to do much in Sharepoint.
Trying to keep track of what order the various modules need to be logged into doesn't really work - I try logging in only once I need to do work in a particular service.
Opening up new powershell windows works around the problem, but the session I leave behind may well have variables loaded up with lists of accounts I'm working on, and it's common to need to compare data across modules.
Borgquite commentedon Apr 13, 2026
Same issue here, the usual assembly conflicts whenever any of the modules are updated. Have to use Windows PowerShell 5.1 as am using DSC to manage our hybrid environment, so am dependent on the LCM.
mrkmcnamee commentedon Apr 28, 2026
I ran into this issue as well using PowerShell 5.1. This is the version that is launched by default on Windows 11.
Gavin Barron (@gavinbarron) wrote:
According to the docs: "PowerShell 7 doesn't replace Windows PowerShell 5.1. It installs to a new directory and runs side-by-side with Windows PowerShell 5.1."
So, 7.5 is something that the user has to explicitly install and explicitly launch ("PowerShell 7") to use, which could explain why there are so many 5.1 users experiencing this issue.
Cheers,
Kevin
fardinbarashi commentedon Apr 30, 2026
My problem was solved by :
Uninstall module
1.1. Install-Module Uninstall-Graph
1.2. Uninstall-All
1.3. Closed all powershell terminals ( ISE/ Code etc )
Install module
2.1 Install-Module Microsoft.Graph.Authentication -RequiredVersion 2.33.0 -Repository PSGallery -Force -AllowClobber
2.2 Install-Module Microsoft.Graph -RequiredVersion 2.33.0 -Force -AllowClobber
Using Win11
FashionOu commentedon May 25, 2026
we can also reproduce the issue in 2.37.0
Ar5had07 commentedon Jun 17, 2026
I'm facing this exact issue in VSCode, but not in Terminal (version 2.38.0)
VSCode
Terminal
HorridMutilation commentedon Jul 15, 2026
I am also having the same issue in VSC but not in Terminal...
PerryVerheij commentedon Jul 21, 2026
Version 2.38.1 in PowerShell still has the bug. I had to downgrade to 2.33.0 to be able to connect to MS Graph.
tea-pope commentedon Aug 7, 2026
Can confirm this is still an issue as of the latest release. Still have to stick to 2.33 for all of Microsoft.Graph in order to use base functionality.
haydgsky commentedon Aug 10, 2026
Same issue here when loading the Exchange Module before the Graph module on 2.39 in Powershell 5.1
neilpeel13 commentedon Aug 21, 2026
Same issue in VS Code PS5.1 using Graph module v 2.39.
Seems to connect-mggraph OK when using ISE..
Was OK on previous version 2.34 - but started failing after moving to 2.39.
Module does not seem to import correctly in VS Code..
saqib-s commentedon Sep 18, 2026
Looks like this probably won't be addressed, as Microsoft have announced a twelve-month retirement period to phase out support for Graph SDK modules running on Windows PowerShell 5.1.
Microsoft also announced plans to deliver V3 of the Microsoft Graph PowerShell SDK in Q4 of 2026. SDK V3 is targeted at PowerShell V7 and will not include explicit support for Windows PowerShell 5.1. Organizations that wish to continue running Graph SDK scripts on Windows PowerShell 5.1 must remain on a V2 release because V3 will not support the older runtime.
"If you’re still on Windows PowerShell 5.1, begin planning your move to PowerShell 7.x now. It’s the recommended and only maintained platform going forward, and it delivers the more reliable experience described above."
from MS article linked above