It’s time to explain the logic of a Skype for Business client joining a meeting and a ‘hidden secret’. I will not go throw all the details. Some parts of the process are not include to keep the content less boring and confusing.
Nowadays, with the majority of users in Homeoffice environments, the company networks have ‘extended’ and included different type of secure/VPN remote access. They were also forced to open SfB external access for collaboration with employees and business partners.
This has exposed one particular behavior to the end-user thats your SfB infrastructure has a problem while connecting to meetings.
The SfB Join meeting logic
A typical and formal SfB meeting has the following sequence. Here’s an overview of the process before the detailed explanation:
(1) The presenter creates an Outlook invitation (using the SfB meeting plugin). This generates a meeting link url where participants can click and join. The presenter can also (should) adjust the meetings settings and permissions and then (2) send the email to the participants.
(3) The participants just need to press the link to join the meeting (or dial the phone numbers), right?
Now it all depends on a series of factors from the computer software to the network where the user is. The meeting url is a web link, so 99,5% of the participants will be able to open it. What happens next is ‘SfB sweet magic’
- If you have a SfB client installed it will launch it to join. If not, then the participant can use the web browser to install and launch the ‘Skype Meeting app’ plugin to join the meeting
- If you are using a personal computer at home, or the SfB client on your mobile, the probability to join the meeting is very high
- If you are joining a meeting from a colleague and you have a company computer the probability is also very high
- If you are joining a meeting hosted by another company, then a series of conditions will trigger the SfB client behaviour.
This last situation is the one I want to explain, either if you are a SfB user or system administrator to understand why sometimes you will not be able to join the meetings.
The SfB federation/meeting guest policies define if and how the users can join meeting.
(3a) If both companies SfB are allowed to federate, the participant SfB client will try to reach the SfB servers (throw the Edge server and then to the internal servers hosting the conference)
(3b) one or both companies are not allowing federation with each other, but the the meeting policies allow guest participants, then the SfB client will try to join as a guest. Internally it launches an instance as anonymous so it can bypass server validation. You can see this on the Client logs (at it also appears on the Monitoring reports)
(3c) of course, if neither federation and meetings guest access is allowed, then participants from other companies will be unable to join.
The ‘security and network policies’ factor
As you could read, SfB has a lot of resources to be able to help users to join a meeting. But the scenario 3b presents a new challenge when the user is behind the company network security architecture:
- If you connect to your company network ‘on-demand’ (you can connect/disconnect the VPN) or if you have a split-tunnel VPN in place, the probability to join the meeting from other companies is very good
- But if you inside your company network of if you have a allway-on VPN (you cannot disconnect it and use you home internet connection) with a forced Tunnel (all your computer traffic must go throw the company network firewall), then the probability to join the meeting from other companies is very low
To explain this let’s use the same meeting flow diagrams with the network.
With federation allowed between companies, users will join the conference. The audio and video will go either directly (homeoffice) or throw the SfB Edge servers (VPN and LAN users)
But if federation is not allowed between companies, the SfB client will try to join as a guest. But now the audio/video must go directly to the Presenter Edge server as it cannot use the Participant’s Edge servers (not authenticated).
Why? because the companies network firewalls usually block any desktop client attempts to access directly the internet. Understandable, because the audio and video ports are sometimes dynamic and cannot be properly inspected.
The bad image
As an IT engineer you now know why the client will fail joining meetings.
But for the less informed user, all that he sees is the yellow warning/error information when SfB fails to join a meeting. And since the initial part of the joining is web traffic, the client might actually open and join, but then the audio fails and the meeting ‘dies on the beach‘.
For Sysadmins the SfB is working fine, but for the frustrating Presenters and Participants SfB is just failing: ‘SfB is a *”&*ç%, VIPs escalate incidents,…
Many companies rushed users to homeoffice, asked the network teams for VPN access but forgot to involve the UCC teams on the process, flooding them with tickets and complains
There is no 100% solution for this and the issue is actually related to processes:
- Allow federation between companies
If not using open federation, you need to allow it the domain that is blocking it
- Solve the internal firewall blocking
It’s more a political/security issue than a technical one 🙂
- (or) allow VPN Split tunnel
it might solve not just this, but other issues when trying to join meetings from other 3rd parties
- Sometimes it takes two sides to solve the problem
Ex: you SfB sysadmin might solve the problem of you to join external meeting, but for external parties to join your meetings it requires solution from the SfB/network admins from the other party
- Keep the 1st line of enduser support aware of the new network complexity and how to troubleshoot
They now have not just to check the LAN and VPN, but also any mix of homeoffice internet access, private computers,… 😦
Final note: “Microsoft Teams is better” (?)
By this time and after these and other ‘issues’ every SfB Admin already heard everyone commenting: “MS Teams is better”. “I don’t have these problems with Teams”, “other companies are better with teams… we are stuck with this limited SfB”
Well, this particular “issue” will also happens if you use Teams and if your network is configured the same way.
And it would be even worse: You would not be able to use audio or conferencing!
Why? because the Teams client also uses the same audio/video logic for ports. The firewall will block the same way as is does for SfB.
Because of this, a participant that doesn’t have Teams or SfB will not be able to join any meeting invitation if they are inside their company LAN/VPN.
(There are actually companies that use other UCC solutions other than MS, you know 😉 ?)
But it’s not failing, why?
This is the unfortunately difference between the company SfB engineer and an Official Microsoft consultant.
Microsoft has documented pre-requisites for Office365 and Cloud services. Between them, the requirement to allow audio/video ports access from internal networks to O365 media servers.
No one will block/object this against MS, but the SfB engineer as to struggle internally to get the same results.