Lync 2013 CU3 and Hosting Providers

One change I've noticed with the Lync 2013 CU3 (October 2013) Edge server update is how it validates trusted FQDNs found in the topology. Specifically, a FQDN can now either be configured a hosting provider or a federated partner's Access Edge address, but not both.

Under normal circumstances this shouldn't pose an issue, but the Lync Control Panel will not prevent an administrator from performing this configuration. And until CU3, the services didn't seem to care either way.

As an example, the proper way to allow Lync Mobile push notifications for Windows Phone clients (and Lync 2010 iOS clients), has always been to define as a hosting provider like in this screenshot.

11-6-2013 9-20-09 PM

The partner should then be defined as a SIP Federated Domain with no Access Edge service specified. But, if an administrator did accidentally specify as the Access Edge service FQDN, like in the screenshot here, it had no negative impact on the configuration. 11-6-2013 9-30-54 PM

Until CU3 this didn't present a problem. But after applying CU3 on an Edge server you'll find the Access Edge service will no longer start. Event 14517 will be logged after it fails:

The server configuration validation mechanism detected some serious problems.

The server at FQDN [] is configured as both type 'allowed partner server' and type 'IM service provider' .

The solution here is to make sure any hosting providers, such as Lync Online, are not also defined as the Access Edge address for a SIP federated domain. This issue isn't unique to - it applies to any Office 365 tenants specified as a SIP federated domain.

Make sure you validate your hosting provider and federated domain configurations prior to deploying CU3 on an Edge server.

Lync 2013 Mobile Client Voicemail

I discovered recently that the Lync 2013 Mobile client needs voicemails to be stored in the MP3 format in order to play them back directly within the application. One of my customers had set the default codec on the Exchange Unified Messaging dial plan to be GSM to provide greater compatibility with mobile devices a few years back, and never updated the setting.

When users attempted to play back their voicemails in the Lync 2013 Mobile client they would see this error:

We can't play this message. Tap Play to receive a call to hear it.


You can work around this issue by modifying the audio codec used by the UM dial plan, which affects all users assigned that particular dial plan:

Set-UmDialPlan -Identity MyDialPlan -AudioCodec MP3

Or, you can set the audio codec on a per user-basis with the Set-UmMailbox cmdlet, which will override the dial plan default:

Set-UmMailbox -Identity tom -CallAnsweringAudioCodec MP3 

In either case, you should be find that any voicemails received after the change can now be played directly within the Lync 2013 Mobile client.

Lync 2013 Mobile Clients and Apache Reverse Proxy

Just a heads up: You may be experiencing issues using the new Lync 2013 mobile apps if your reverse proxy is Apache. I don’t have a solution at this time, but have confirmed replacing Apache with IIS ARR works just fine in the same environment. All other external web services and the old 2010 mobile clients work properly, but we observed the following behavior on the 2013 apps:

  • First client sign-in attempt fails, but second sign-in succeeds.
  • Presence for contacts is very slow to load.
  • Client sign out generates an error that the connection to the server was lost.
  • Voice and video calls will not connect.

There are no clues in the server-side logs, but if you review the mobile client logs you’ll find the following error after Apache sends the mobile client a response:

ERROR TRANSPORT TransportUtilityFunctions.cpp/1749:Accept-types (application/ not found in Content-Type response from server (text/plain).  Not decoding.

Deciphering this, the client is expecting an HTTP header to be returned with the a Content-Type of application/ to be returned with the server response. The mobile client logs also show the HTTP headers in each response, which include the following:

HttpHeader:Content-Type text/plain

Since the UCWA MIME type is not a default registration on Apache the server instead reverts to its default behavior of sending text/plain for any content type it does not understand. The response being returned as text/plain causes the mobile client to error out and disconnect the request.

We attempted to register the MIME type with the following command, but it proved unsuccessful.

AddType application/ .xml

Maybe some other Apache guru can share a fix here, but I wanted to save others the troubleshooting time if you see this issue.