Method Not Found: When Az and Microsoft Graph Share a Session

The fix: ordering, not force

Back to the measurements, which contained the answer all along. The relationship between these two modules is asymmetric:

• Load Graph first, then Az: Az loads cleanly. It side-loads its own Azure.Core 1.57 alongside Graph’s 1.51 and carries on.
• Load Az first, then Graph: Graph fails.

Az tolerates arriving second. Graph does not. So the fix isn’t to fight the loader — it’s to connect Graph before anything touches Az:

Connect-MgGraph -TenantId $TenantId -Scopes $scopes -NoWelcome   # first
$context = Get-AzContext                                         # then Az

In the script this meant moving the Graph connection ahead of the Azure context check, which needed one small change: the tenant has to be known up front rather than read from the Az context. Since the tenant is already a parameter, that was a parameter check rather than a redesign.

Verify it the same way the series verifies everything — make the failing case fail. In a fresh session, deliberately put Az first. This should break:

Get-AzContext
Connect-MgGraph -TenantId $tenant -Scopes 'User.Read.All' -NoWelcome

If that still succeeds on your machine, your two modules happen to agree on Azure.Identity today. They won’t forever.

Failure 3: The Retry Logic From Part 2 Was Half Right

Part 2 described a replication race: a freshly synced user appears in Get-MgUser slightly before the authentication-methods endpoint catches up, and Graph reports that two different ways, resourceNotFound and accessDenied. The fix there was to treat both as transient and retry.

That fix was correct for new accounts and wrong for everything else.

Weeks later, a tech ran a password reset on an employee who’d existed for a month. The script spent a minute retrying, announcing each time that Entra ID hadn’t finished replicating the user, then gave up. The user had been in Entra ID since the previous month. Nothing was replicating.

accessDenied is ambiguous, and the account’s age resolves it:

• On an account created seconds ago, it’s the authorization context still replicating. Retry.
• On an account that already existed, there is nothing left to replicate. It means the caller genuinely lacks the role — almost always a PIM activation that expired, since activations last hours and the technician’s last onboarding was days ago.

Retrying the second case wastes a minute and prints a misleading explanation. So the retry now depends on whether this run created the account:

$notFound = $msg -match 'resourceNotFound|could not be found'
$denied   = $msg -match 'accessDenied|Request Authorization failed'
$transient = $notFound -or ($denied -and $AccountJustCreated)

if ($attempt -lt 5 -and $transient) {
    Start-Sleep -Seconds 15
}
elseif ($denied -and -not $AccountJustCreated) {
    # Nothing was replicating. Say what's actually wrong.
    Write-Warning 'Activate your PIM role, run Disconnect-MgGraph, retry.'
}

The lesson isn’t about TAPs. An error message that’s right 80% of the time is a bug, because the 20% sends someone to investigate a system that was never broken. If you can tell the two cases apart in code, tell them apart in the message.

Failure 4: Modules That Can Evaporate

One more, quieter than the others. While investigating the assembly conflict, the module paths looked like this:

C:\Users\<user>\OneDrive - <org>\Documents\PowerShell\Modules\...

Documents is redirected to OneDrive, so every installed PowerShell module syncs to the cloud. With Files On-Demand, those DLLs are placeholders that can be evicted to free up disk space. A module that loads today can be a stub next month, and an assembly that fails to materialize produces exactly the kind of baffling error we’d just spent a day on.

They happened to be hydrated for me, so this wasn’t the culprit. It’s a trap waiting its turn. Check:

Get-ChildItem "$HOME\Documents\PowerShell\Modules" -Recurse -Filter *.dll |
    Where-Object { $_.Attributes -match 'Offline' } |
    Select-Object -First 10 FullName

Anything returned is cloud-only right now. Pin the tree so OneDrive can’t reclaim it:

attrib +P /S /D "$HOME\Documents\PowerShell\Modules\*"

Re-pin after installing or updating modules; new files arrive unpinned. The better long-term answer is to keep modules out of a synced folder entirely.

While you’re there, look for version sprawl. Four side-by-side Az.Accounts versions and two complete Microsoft.Graph sets is how mismatched pairs end up in the same session:

Get-Module Az.Accounts, Microsoft.Graph.Authentication -ListAvailable |
    Select-Object Name, Version, ModuleBase