About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Lync 2013 Mobile call failure

Isiah Hudson, CDW UC Consultant, reports the following:

Failures of IM and calling to Lync 2013 mobile clients in two very specific scenarios. The findings are listed below:



When an IM is sent from an internal user (using any Lync client) to a user on the Internet using the Lync mobile 2013 client. The Internal user would get an error message saying the IM failed immediately after the Lync 2013 mobile user accepts the IM.


When a call (audio or video) is initiated from an internal user to a Lync 2013 mobile user on the Internet the call results in a failure.

This issue only impacted Lync 2013 mobile clients. The Lync 2010 mobile client worked fine in all IM and call scenarios.


Tell-Tale Signs

After the IM or call is accepted by the Lync 2013 mobile client the following a SIP/2.0 403 Forbidden message is generated by an FE server with the following information in it:

ms-diagnostics: 24118;Component="RTCC/";Reason="Application accepts invitations via static registration only.";Source="whatevertheFEservernameis.ad.local"



A ticket was opened with MSFT and after a couple of months of working on it the problem was the public certificate on the reverse proxy for the Lync external web services had SAN names in them that were not resolvable by public DNS. I am told by MSFT support that the Lync 2013 mobile client will try and resolve all SAN entries of the public certificate presented to it at sign-in. If it cannot resolve any SAN entry on the certificate you may experience the problems outlined in the Issue section above.


Take Away

Make sure all SAN entries on the public certificate you put on your reverse proxy for Lync can be resolved to an IP address or you will have a bad time.

And there you go.  Nice work Isiah!



Unknown said...

Thank you.
Also, push notifications doesn't work with wildcards in the certificate and error will be the same.

John Crouch said...

FYI - I opened a MS case for that same error Diagnostic ID 24118; Reason="Application accepts invitations via static registration only." under different circumstances. This is the answer I got:
Diagnostic ID 24118; Reason="Application accepts invitations via static registration only."

Since we don't have the information on what exact issue had occurred when this error message was captured and we are solely relying on the information mentioned in the ticket - IM Message sent from internal Lync client to Lync Mobile client, below is the possible scenario where this error can occur and its possible causes.

Scenario# When an IM message is sent from an internal Lync Client to a Lync Mobility client, then the Internal user might get an error message saying the IM was not sent even though the Lync Mobility client has received the IM message.

Reviewing the logs, we will notice 403 Forbidden with the error message - "Application accepts invitations via static registration only"

Possible Cause 1# On the Front-End server and the Reverse proxy if there is a Certificate with multiple Subject Alternative Names (SAN) and in case one of the URL mentioned in the SAN entries is not reachable then you would see this error in the logs.

Possible Cause 2# We have also seen this kind of error in the logs when SSCH (Server Side Conversation History) is not enabled then Auto Accept of IM messages on the Mobility clients might not work when the user is inactive on the device and this would lead to the error message.

Official SfB 2015 Server Disable TLS 1.0 and 1.1 part 3 guidance

As you may be aware, we have covered the upcoming 31 October 2018 TLS 1.0/1.1 support being removed from O365.  You can find that guidance h...