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 sipfed.online.lync.com as a hosting provider like in this screenshot.
The partner push.lync.com should then be defined as a SIP Federated Domain with no Access Edge service specified. But, if an administrator did accidentally specify sipfed.online.lync.com as the Access Edge service FQDN, like in the screenshot here, it had no negative impact on the configuration.
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 [sipfed.online.lync.com] 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 push.lync.com – 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.