Home » Skype for Business » Skype for Business & The Curious Case of the Meeting Invite

Skype for Business & The Curious Case of the Meeting Invite

While testing out a deployment of Skype for Business Server I came across an interesting but equally frustrating issue with a few users. When one of these problem users dragged and dropped or used the invite participants button to invite a federated partner into either an ad-hoc conference or previously scheduled, the federated partner would receive the following error message “Unable to find the Skype Meeting”. The user who invited the federated partner would then get the message “The Invitation to <partner name> has expired”.

Breaking out CLS and Snooper and tracing the call I was able to see the invitation, and acknowledgement from the partner, but then both the partner and user sent a BYE immediately after the record route was set up.

However, if the federated partner joined the meeting using the meeting join link for the same meeting they could not be invited to they were able to join the meeting as normal. Confusing matters further, if a brand new account was enabled for Skype for Business server, and using the same end device they did not experience this issue at all and were able to drag and drop the same federated user into their conferences.

This eliminated the possibility of a firewall problem or machine configuration, so the problem must be account related. Comparing a problem user with a working user’s AD attributes I could not see a difference and all msRTCSIP- attributes were populated as I would expect. Disabling the problem user, invoking a replication of the databases and then re-enabling did not fix the problem.

Tearing my hair out I reached out to the community and thanks to Luca Vitali, Josh Blalock, Michael Tressler and Jason Wynn for their time and suggestions but together we could not come up with a resolution. Time to phone Microsoft….

While I was waiting for a call from them, I had one more look at the logs and scenario I was attempting to complete. Looking at the record route, I could see the partner was located in Office 365. To eliminate any possibility with federation with Office 365, I decided to drag and drop a federated partner who was not located in Office 365. I was also expecting this to fail, because peer-to-peer I could federated fine with Office 365 partners across all modalities. And then, WTH, a federated partner who has their own server can be invited into the conference with this problem user account.

So this narrowed the problem down to something between Office 365 federation to the on-premises server. But remember I can federate fine with Office 365 partners in peer-to-peer communications. So what exactly is the difference here? I figure it is down to the way the Invite to a conference works, coupled with some Office 365 federation nuance.

I was having a poke around to see what I could find and I found a security group that was name something like “Office365Sync” and thought, DirSync!!, so we must have an Office 365 tenant somewhere that I didn’t know about. Sure enough, there was a tenant that had expired and unused (from a previous trial), but still synchronizing accounts in this group. Even though the users subscriptions had expired they were still enabled for Skype for Business Online. So we have two identical accounts, one enabled on prem, and one enabled (but unlicenced / inactive) in Skype for Business Online. This basically confused Office 365 federation. Even though the account was inactive, when the partner was trying to complete federation in this scenario, it was terminating in Skype for Business Online rather than reaching the corporate edge servers.

This made sense because if the partner joined via URL, it is telling the partner where the meeting is hosted.

To the resolution was simple in the end, stop AADSync, convert the identities to cloud, delete them in Office 365 and remove the domain from Office 365 to decommission the inactive tenant properly. Once this had been done, guess what? Things started to work as normal…

I really wanted this solution to be technical, but in the end it boils down to improper housekeeping. Moral of the story, decommission trial Office 365 tenants properly.


  1. That was a nice find. Were there any errors (error codes) in QoS reports? or just BYE – action initiated by user?

    • No errors customer side, just client initated BYE. But then we wouldn’t get any because the federation traffic never reached the corporate edges as it routed locally to Office 365

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: