Thursday, 1 December 2022

Teams PowerShell Certificate or Token Based Auth WinRM Error

I ran into an issue the other day that was difficult to troubleshoot due to the obscure error that arose. The scenario: I was attempting to use Certificate or Token based Authentication to do an application-based authentication with Azure (instead of the regular interactive password based authentication).

After setting everything up and connecting to Teams PowerShell, there was a persistent error any time a Skype for Business *Cs* command was run. The error referenced the WinRM client not being able to process the request. Here’s the error in question:

PowerShell Error:

PS C:\> Connect-MicrosoftTeams -CertificateThumbprint "897a047bc435843b2a32126544e5a7a8001fee8c" -ApplicationId "216d0455-8988-45b0-b425-222ca02e8ede" -TenantId


Account                              Environment Tenant                               TenantId

-------                              ----------- ------                               --------

219d0455-8988-45b0-b425-222ca01e8ece AzureCloud  6364a50-c3d7-4eee-834c-21a2371df363 6364a50-c3d7-4eee-834c-21a237...

PS C:\> Get-CsOnlineUser

2022-11-22T23:02:46Z [Error] ERROR: Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The authentication mechanism requested by the client is not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.


From the error it seemed like an issue on the client side to do with the method being used to authenticate or communicate with the cloud endpoint on the client side… However, after exhaustively chasing down anything to do with the client side WinRM settings, nothing was working… This was on the latest 4.9.1 Teams PowerShell module which in its release notes listed application authentication as being made GA ( As a result, it’s not likely there was a bug in the module that meant that all *CS* commands just didn’t work...

At this point I looked to the cloud. When configuring application-based authentication for the Teams PowerShell module, you need to set up an App Registration and assign it permissions and RBAC roles to allow it to access Teams. In the deployment I was working on, the following permissions were assigned:


The documentation ( from Microsoft says that the following settings were required:








Note: For the record, you also need to assign the Teams Administrator RBAC role to the Application Service Principal in the Roles and Administrators area (but this wasn’t the issue in this case).

It appears that all of these permissions were included. So it should be fine, right?


What I found out was that the “Skype and Teams Tenant Admin API” permissions that were included here were to blame for the error. After removing and revoking both of the innocuous “Skype and Teams Tenant Admin API” permissions, I was able to connect and run *CS* commands to my heart's desire…

So to anyone who says “you can never have too many permissions” it appears that you actually can... 

Note: There may be other permissions that also cause this to happen, so make sure you haven't assigned more permissions than are required.

The Solution

Remove the offending “Skype and Teams Tenant Admin API” permissions:

Once removed, the permissions get demoted into the "Other permissions granted for <tenant name>" area, where you need to then "Revoke all admin consents" before they will be fully removed:

After this you should have these permissions left:

After this, you shouldn't get the WinRM error anymore when running CS commands! 

Be sure that you have applied the Teams Administrator RBAC role to the App Registration Service Principal as well. Go to: Azure Active Directory > Roles and administrators > Teams Administrator > Add Assignments Button > Search for your App Registration Name and assign it:


The Wrap Up

I hope that helped out a few of you poor people banging your head against the wall about the WinRM error situation. If you want to check out a full walk through of setting up Certificate or Token based Authentication with the Teams PowerShell Module, check out these posts:

Certificate-based Authentication post

Token-based Authentication post

See ya next time!

0 comments to “Teams PowerShell Certificate or Token Based Auth WinRM Error”

Post a Comment

Popular Posts