Forum Discussion
Get-AzAccessToken "Method not found: Void..."
Hi, Steve.
I can't offer any advice on what's causing that issue as I've not seen it before, but I can offer some commentary around the environment and your questions towards the end.
Firstly, on the environment, I only use Windows PowerShell (aka 5.1) as it's the only option out-of-the-box, and is therefore the only option available in practically every customer engagement I've been in. And in most cases, this is on Windows Server 2019, too.
This dovetails into your question of "is it possible that this just won't run on Windows Server?", for which the answer is it most certainly does run on Windows Server under Windows PowerShell.
That said, while I have a few solutions doing as you're doing - which is using Az.Accounts to procure a token for including in subsequent Microsoft.Graph calls (amongst others), there is a point of difference in that I'm using certificate-based authentication rather than old-school username-and-password credentials. Still, that one point aside, the approach you're taking definitely works.
With respect to the error, "method not found" is typically thrown for one of "two" reasons (technically, it's one reason but it's useful to split it):
- The method or constructor really does not exist;
- The method or constructor does exist, but not with a definition that matches the parameters passed in.
One possibility is that different versions of a library are required by different PowerShell modules. And it's noteworthy that the class (contained in Azure.Identity.BrokeredAuthentication.dll) from your error message is used by both the Az.Accounts and Microsoft.Graph.Authentication modules. So, there's a possibility that they are in conflict.
There's a lot of different troubleshooting steps you can pursue here, but in the interest of keeping things simple, I'd wipe out all module versions (using Uninstall-Module) matching the following specifications and re-install those that you need:
- Az.*
- Microsoft.Graph.*
There's a reasonable chance that ensuring that both the Az modules and Microsoft.Graph modules are current that the underpinning SharedTokenCacheCredentialBrokerOptions class issue will also be resolved.
As a side note, you might also want to ensure you're running .NET 4.7.2 or above, as both Az and Graph modules are tagged to this as the minimum version:
Cheers,
Lain
Hi, Steve.
I can't offer any advice on what's causing that issue as I've not seen it before, but I can offer some commentary around the environment and your questions towards the end.
Firstly, on the environment, I only use Windows PowerShell (aka 5.1) as it's the only option out-of-the-box, and is therefore the only option available in practically every customer engagement I've been in. And in most cases, this is on Windows Server 2019, too.
This dovetails into your question of "is it possible that this just won't run on Windows Server?", for which the answer is it most certainly does run on Windows Server under Windows PowerShell.
That said, while I have a few solutions doing as you're doing - which is using Az.Accounts to procure a token for including in subsequent Microsoft.Graph calls (amongst others), there is a point of difference in that I'm using certificate-based authentication rather than old-school username-and-password credentials. Still, that one point aside, the approach you're taking definitely works.
With respect to the error, "method not found" is typically thrown for one of "two" reasons (technically, it's one reason but it's useful to split it):
- The method or constructor really does not exist;
- The method or constructor does exist, but not with a definition that matches the parameters passed in.
One possibility is that different versions of a library are required by different PowerShell modules. And it's noteworthy that the class (contained in Azure.Identity.BrokeredAuthentication.dll) from your error message is used by both the Az.Accounts and Microsoft.Graph.Authentication modules. So, there's a possibility that they are in conflict.
There's a lot of different troubleshooting steps you can pursue here, but in the interest of keeping things simple, I'd wipe out all module versions (using Uninstall-Module) matching the following specifications and re-install those that you need:
- Az.*
- Microsoft.Graph.*
There's a reasonable chance that ensuring that both the Az modules and Microsoft.Graph modules are current that the underpinning SharedTokenCacheCredentialBrokerOptions class issue will also be resolved.
As a side note, you might also want to ensure you're running .NET 4.7.2 or above, as both Az and Graph modules are tagged to this as the minimum version:
Cheers,
Lain
LainRobertson Thank you, Lain, for a detailed and thoughtful response!
I did not understand that both the Az.Accounts and Microsoft.Graph.Authentication modules utilized the same DLL that was mentioned in the error. Once I understood that, I realized that the largest gap in versions was for Graph.Authentication:
Name | Win10 Laptop Version | RPA Server 2019 Version |
Az.Accounts | 2.12.2 | 2.12.5 |
Microsoft.Graph.Authentication | 1.27.0 | 2.3.0 |
I then uninstalled all the Graph modules and reinstalled using the "-requiredversion 1.27" switch. My script now executes successfully on the 2019 server! 
Oh, and after checking the registry, both machines running .NET 4.8.
Some follow-up questions:
- For future reference, how could I determine if a DLL that's mentioned in an error is used by other commands than the one that failed?
- Are the Microsoft Graph v2 commands considered preview? I am hoping that at some point in the future they will include all of the functionality of the v1 commands. I am just concerned that a future PowerShell script will require v2 commands while this script must stay at v1. I am not sure how to handle that scenario other than spinning up an entirely separate server.
Thanks again for your assistance! I opened a Microsoft ticket for this issue but it's still being routed to the correct support group. 