Dangling SfBO sessions with Microsoft Teams Module 2.x
Or… PSSession is still lurking in the “shadows”
Microsoft recently released version 2.x of the MicrosoftTeams PowerShell Module. One of the big changes for Teams administrators is that the cmdlets provided by the now deprecated Skype For Business Online Connector module have been included in a way that it’s not anymore necessary to create your own remote PSSession in order to use them. Or… isn’t it?
In my day to day work we heavily rely on the MicrosoftTeams module and its ability to assign Direct Routing phone numbers with Set-CsUser -Identity $identity -OnPremLineUri $lineUri and read user information with Get-CsOnlineUser. Those are the “old” SfBo cmdlets.
I got curious about how they were implemented, mainly because it has been reported that they do not seem to work when using Connect-Teams with anything else but user credentials.
I started looking into the files installed on the hard drive in (typically) C:\Program Files\WindowsPowerShell\Modules\MicrosoftTeams\2.3.1.
Opening the net472 folder we can see something interesting, there is a file called: SfBORemotePowershellModule.psm1.
Looking into it you can discover that the “old” SfBO cmdlets are defined into this file.
Digging into their implementation you can see that each of them is implemented using the following pattern:
You can see that there is still a PS Session involved, it’s only hidden from the user.
Digging a bit more you can see that this session in managed by the Microsoft.Teams.ConfigAPI.Cmdlets.private assembly’s own Get-CSOnlineSession method. In short this method will check that Connect-Teams has been called and then use the passed credential to create a new PSSession or re-use an existing one.
At the end of the day the new TeamsModule still creates a PowerShell remoting session in order to use the SfBO cmdlets.
This remote session gets created the first time you use an SfBO cmdlet and it is managed transparently by the module.
Now, in v2.3.1 and in the recently released v2.3.2-preview, I found a problem: although the PSSession is completely managed for you and you do not even need to know about it (and actually you do not), calling Disconnect-Teams does not close it, leaving it active and dangling.
Note that even if the session is still active, you cannot use it, because if you try to call an SfBO cmdlet after calling Disconnect-Teams, it will complain that you need first to call Connect-Teams.
It is easy to verify that such a connection is there. Try the following:
The output from Get-PSSession will be something like:
Now, as an experiment, open 4 PowerShell instances and call Connect-MicrosoftTeams in all of them.
Then call a SfBO cmdlet like Get-CSOnlineUser in 3 of the shells. Everything should work.
Call Disconnect-MicrosoftTeams in one or more of the 3 shells and then go to the 4th and run Get-CSOnlineUser and you will get the error message:
WS-Management service cannot process the request. The maximum number of concurrent shells for this user has been exceeded. Close existing
shells or raise the quota for this user. For more information, see the about_Remote_Troubleshooting Help topic.
You can go to one of the previous instances of PowerShell and type:
Get-PSSession | Remove-PSSession
At this point you can try again to call an SfBO cmdlet in your 4th PowerShell session and everything will work.
In other words, while the TeamsModule manages the PSSession for you, it does “forget” to dispose of it when calling Disconnect-MicrosoftTeams, leaving the task to you or just waiting that the session expires.
Hope that Microsoft fixes this soon.
P.S. Thanks to Fabrizio Volpe for his help in reviewing the article and pushing me to share.
