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
Here's some matching answers in short-form:
- When loading a new PowerShell module, DLLs can be loaded at any point, so the answer it "it depends" on a per module basis. i.e. the module could load DLLs as part of its own initialisation, or it could be deferred until later where a particular command triggers the loading;
- Yes, this is correct - as a general rule. Whichever version is loaded first usually "wins". There are exceptions to this but they're not worth going into in depth as it's just not common enough to talk about. But in this particular scenario, it doesn't matter which module wins since fundamentally, each PowerShell module (Az and Graph) have different expectations from the constructor;
- Generally when the PowerShell module is closed. In much the same spirit as point 2 above, there are exceptions, however, they're not common enough to warrant talking about. It is worth calling though that Remove-Module does not unload DLLs from memory (I've come across that misunderstanding before so figured it was worth a shout-out.)
On the final question, I haven't come across the need to use a normal user account as everything I've done works just fine with a servicePrincipal (aka app registration), and I've only seen certificate-based authentication for the latter - though I've also had no reason to look into if it's possible for a regular user (of type "member" as distinct from "guest") account.
If I can muster up some time, I'll have a look and let you know - or maybe someone else already knows. But for now, from me, the answer for CBA on user accounts is "I don't know" (or in Australian, we simply say "dunno"!).
Cheers,
Lain
Does it mean usually the close and re-open of the console / ISE might work to resolve this issue?
I just ran a quick test and the ISE does indeed get a new environment when I launch it from a PowerShell prompt, meaning closing the ISE and re-opening it should resolve any DLL conflicts.
Cheers,
Lain
Hi, Albert.
I know I've used this a lot in this thread, but the answer to this, too, is still "it depends".
What it depends on is how the ISE was launched, as when a new process is launched, the launching process can specify that the new, child process is to either (there's other options but I'm keeping this simple):
- Inherit the launching process's environment, or;
- Be issued with a new environment.
If the first option is used and if the DLL is loaded into this environment, then closing the ISE and re-launching it will not resolve the issue. Conversely, in the second scenario it will be resolved.
If you launch the ISE from the Start Menu, quick launch, etc. (i.e. the Windows shell environment) then you will get a new process environment and restarting the ISE is a viable option.
I'd have to run a test to see if launching it from within an existing PowerShell session creates a new environment or not, but I can at least conceive that this might lend itself to the first scenario - but I simply don't know as of this minute.
Cheers,
Lain