MS Teams connectivity issue in Azure function

Occasional Contributor

I tried to use MS Teams commandlets in Azure runbook and got the below error. Any thoughts would be appreciated.


Connect-MicrosoftTeams : One or more errors occurred.: Unable to find an entry point named 'GetPerAdapterInfo' in DLL 


At line:14 char:1

+ Connect-MicrosoftTeams -AccountId ""


MS Teams Module version used: 0.9.6


4 Replies

How are you passing the credential ? Looks like you are just suppying a username?


I show how to create a runbook to use Teams PowerShell here ->




@Steven Collier  your post outlines how use connect-microsoftteams using a configured credential  correctly but I believe the issue the OP is posting about is due to trying to us a runas account or some other connection + certificate service principal account.   I get exactly the same error and have seen other reports about this not working - really seems like you cannot use service principal to connect. Have you ever had success trying to do this?


@PhilRiceUoS I haven't looked in to using Teams PowerShell using a Service Principal, I would doubt it's possible. For provisioning I now typically register an application and then use a Client Secret to authenticate then call the Graph APIs I need directly. Lee Ford describes this well at


There are lots of Teams capabilities currently only available through the beta api, for example templates. 





@Steven Collier 

Hi Steven , strangely it is good to hear that you doubt it is possible as I have come to that conclusion myself after lots of testing without success. Graph Api wont work in my particular use case as Im using Automation to apply Teams App Permission policies and Graph Api doesnt yet have the ability to deal with Teams Policies yet from what Ive seen.

The Teams powershell module does seem to be getting new features to help with this though and Ive used the New-CsGroupPolicyAssignment cmdlet for assigning Custom App Setup policy to a security group , but it doesn work for Custom App Permissions policies yet. When it does then I wont need to script this anymore but for now, another new cmdlet New-CsBatchPolicyAssignmentOperation works nicely  for that.

As the runas approach doesnt work Im taking a different approach to secure things and am now going to setup a workflow script that other scripts will call to request to create an account, set password and assign a role and then call again to delete the account once the script has completed. That way can use a random account name and password running with a custom role that is basically using Just in Time Access , probably even more secure than having a runas account.