I'm working on some Azure Functions written in PowerShell, designed to provide APIs for managing Teams Phone. I want to create a new function that connects to Microsoft.Graph to check if a user ID is licensed for Teams Enterprise Voice. Everything runs smoothly on my local machine using PowerShell 7, but once I deploy it to Azure, I hit a snag. The function throws an error stating that it can't find the assembly 'Microsoft.Identity.Client' version 4.67.2.0.
To avoid dealing with the complexities of Graph due to its size, I've uploaded version 2.28.0 of the Microsoft.Graph module to my Modules folder, and I also tried version 2.29.1. It seems to recognize Microsoft.Graph.Authentication, which is needed by my command.
Here's the specific command I'm running that triggers the error:
> Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All" -TenantId
And the error message I get is:
> ERROR: Could not load file or assembly 'Microsoft.Identity.Client, Version=4.67.2.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'.
I've also attempted to add Microsoft.Identity.Client to my requirements file, but that didn't resolve the issue. Any insights would be greatly appreciated!
3 Answers
You might want to try rolling back to version 2.25.0 of the Microsoft.Graph module. Also, just a heads up that the loading order of the modules can cause those DLL errors. What worked for me was connecting to Azure first, then to Graph afterward.
Have you thought about calling the Graph API directly with PowerShell? Instead of relying on modules—which often get deprecated—this might simplify your approach. Could save you some hassle!
I've experienced similar issues with Azure automations and PowerShell modules. Sometimes, you'll need to remove a bunch of modules and reinstall them in order until things finally work. It's a bit tedious, but it might help!
That's a good point! It honestly didn't cross my mind to try that. I'll look into it, but I also need to find out who in my organization can approve the app permissions for this.