Before we start, I highly recommend you first read Scott Stubberfield’s “Anonymous join from Skype for Business and Lync Clients” blog post: https://blogs.technet.microsoft.com/scottstu/2015/04/03/anonymous-join-from-skype-for-business-and-lync-clients/
Now that you understand the anonymous join process, we’ll go into one scenario that I’ve been tracking since Lync Server 2013 RTM (almost 4 years…).
(UPDATE Sept 17,2017) Issue resolved, see: http://realtimeuc.com/2017/09/skype4b-anonymous-join-success-when-meeting-organizer-is-disabled-for-federation/
- Company A has Federation Enabled
- User at Company A has an External Access Policy set to have Federated User Access disabled
- This User schedules a meeting and sends the invite to an external participant
- External participant is running the Lync or Skype for Business client
- External participant tries joining the meeting, but is greeted with “An error occurred during the Skype Meeting”
- External participant is able to join the meeting if forcing connection via Web App in browser (appends ?sl=1 to the end of the meeting URL)
Let’s compare some client logs for the External participant:
- Company A Federation Enabled and Meeting organizer Enabled for Federated User Access (Successful federated join):
- Company A Federation Disabled or External participant’s domain is blocked (Successful anonymous join):
- Company A Federation Enabled and Meeting organizer Disabled for Federated User Access (Failed anonymous join):
So we have the External participant’s client triggering anonymous join when seeing 504 or 404, but not the 403 response that is received when the meeting organizer is disabled for federation.