MicrosoftTeams PowerShell module v2.0.0 Get-CsOnlineUser Error
With the MicrosoftTeams PowerShell module v2.0.0, New-CsOnlineSession is now deprecated and replaced by Connect-MicrosoftTeams. After a successful Connect-MicrosoftTeams using certificate authentication, Get-CsOnlineUser returns the following error:
Exception calling "GetSteppablePipeline" with "1" argument(s): "Exception calling "GetRemoteNewCsOnlineSession" with "1" argument(s): "Tenant Domain is empty"" At C:\Program Files\WindowsPowerShell\Modules\MicrosoftTeams\2.0.0\net472\SfBORemotePowershellModule.psm1:9474 char:13
+ $steppablePipeline = $scriptCmd.GetSteppablePipeline($myI ...
+ CategoryInfo : NotSpecified: (:) , ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CmdletInvocationException
Get-CsOnlineUser works properly after Connect-MicrosoftTeams with credential authentication. Thanks for looking into this.
Still grasping for straws on this issue, I happened upon the recommendations for the Azure AD Powershell module ( https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-6.1.0 ) and noticed that MS recommends version 7.x or later. I checked the version that I am using and it is 5.1. Since Az commands were used to create the local cert, I am wondering if I should be completely redo this using the latest version of Powershell?
Same thing with 2.4 preview
I am getting the same results as you folks are when attempting to pull Teams data using a connection via cert-based Service Principal. I have tried using MicrosoftTeams version 1.1.6, 2.3.1, and the preview version of 2.3.2 without success. I've also attempted using the domain name in place of the tenant id and receive an error of "The WinRM client
cannot process the request". Which is different from the "Get-CsOnlineSession : Tenant Domain is empty" error that I have been getting.
I started digging a little deeper into the SfBORemotePowershellModule.psm1 file that is referenced as part of the error, but admittedly, the contents of this file stretches my already limited knowledge of Powershell. I can say that the referenced error points to the line:
-Session (Get-PSImplicitRemotingSession -CommandName 'Get-CsOnlineUser') `
Again, I am no PowerShell expert by any means, but I do know that in version (2.3.2), Get-PSImplicitRemotingSession is not recognized.
Jeffry A. Spain commented
Agree with @E. Same error with MicrosoftTeams v2.3.2-preview and Get-CsOnlineUser.
Just tested the 2.3.2 preview. Same issue.
However I have two machines for Teams administration. Now it gets weird.
I can run get-csonlineuser on the first one but not on the second.
I can run get-team on the second one but not on the first.
Still trying to figure this out
Jeffry A. Spain commented
@Venkata Rallapalli @Andy Chapman This is still a problem with MicrosoftTeams module v2.3.1. The error message with Get-CsOnlineUser is a little different (see below). The only workarounds I have found are either to stay with MicrosoftTeams v1.1.6 or not use certificate authentication. Frustrating. I wish the developers would fix this.
Get-CsOnlineSession : Tenant Domain is empty
At C:\Program Files\WindowsPowerShell\Modules\MicrosoftTeams\2.3.1\net472\SfBORemotePowershellModule.psm1:63 char:22
+ $remoteSession = & (Get-CsOnlineSessionCommand)
+ CategoryInfo : NotSpecified: (:) [Get-CsOnlineSession], ArgumentException
+ FullyQualifiedErrorId : ArgumentException,Microsoft.Teams.ConfigApi.Cmdlets.GetCsOnlineSession
Invoke-Command : Cannot validate argument on parameter 'Session'. The argument is null or empty. Provide an argument
that is not null or empty, and then try the command again.
At C:\Program Files\WindowsPowerShell\Modules\MicrosoftTeams\2.3.1\net472\SfBORemotePowershellModule.psm1:9490 char:38
+ ... -Session (Get-PSImplicitRemotingSession -CommandName 'Get-CsOnline ...
+ CategoryInfo : InvalidData: (:) [Invoke-Command], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.InvokeCommandCommand
Venkata Rallapalli commented
@Andy Chapman - have you found any solution for the issue you were facing?
Andy Chapman commented
Some people have reported success by using the domain name rather then the tenant ID.
However I get a different error when doing that:
Get-CsOnlineSession : Connecting to remote server api.interfaces.records.teams.microsoft.com 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.
Venkata Rallapalli commented
This issue is still prevalent in 2.3.0. @Microsoft, Can you address this issue before you pull your plugs on the Skype For Business Online Connector?
James Rowan commented
Fix this bug. Still present in 2.2 preview
I had my VAR submit a request on my behalf to have Microsoft address this "bug" and this is the response I received:
"As per MS, the Cs Commands are not yet available in Teams PowerShell using a service principal and certificate-based authentication. They do not have an ETA and the confirmation when this will be available in the future.
MS advised that you could raise a user voice on the below link regarding this request."
Looks like they deprecated the Skype PowerShell module and merged certain use cases in the Teams PowerShell module without accounting for using a service principal and certificate-based authentication for the Cs commands. Interestingly, the Teams commands, including logging in, all work using a service principal and certificate-based authentication.
If Microsoft can address this, I can fix the automation that broke to securely allow me to use cert-based auth with a service principal account.
Dave R commented
Having the exactly same issue when trying to use runasaccounts in Azure Automation or authentication remotely with a cert as an application:
Exception calling "GetSteppablePipeline" with "1" argument(s): "Exception calling "GetRemoteNewCsOnlineSession" with "1" argument(s): "Tenant Domain is empty"" (Exception calling "GetRemoteNewCsOnlineSession" with "1" argument(s): "Tenant Domain is empty" (Exception calling "GetRemoteNewCsOnlineSession" with "1" argument(s): "Tenant Domain is empty" (Tenant Domain is empty)))