Lync Phone Edition Strict Domain Naming
In the January 2013 Cumulative Update for Lync Phone Edition (a.k.a. CU7) Microsoft changed a key element of the client registration process. Any Lync Phone Edition (LPE) firmware version from 4.0.7577.4363 and newer is affected by the behavior described in this article.
Adherence to Strict DNS Naming was introduced into the Lync server discovery process that the devices use which was not present in previous versions. What this means is that if the required Service Locator (SRV) and accompanying Host (A) record for a SIP domain are not configured in the same domain namespace then the phone will not be able to successfully sign-in.
In previous Office Communications Server releases it was not possible to configure the Automatic Configuration records in different domain namespaces as the Office Communicator clients would fail to sign in. Although it was possible to disable Strict DNS Naming doing so would not actually allow the clients to work in this scenario as this capability was limited to supporting domain suffixes. Meaning that if strict naming was disabled for the clients then they would sign-in only if the names were confined to the same root namespace. For example: domain.com and child.domain.com would be acceptable. But mismatched names in entirely different namespaces like contoso.com and nwtraders.com would still not be supported.
Traditionally when the term ‘Strict DNS Naming’ is used in Lync the following configuration would be applicable. Both the SRV and Host records are configured in the same domain namespace. This configuration model has been a best practice for a long time now and was a requirement for OCS.
_sipinternaltls._tcp.mslync.net > sip.mslync.net
But Lync 2010 introduced the flexibility to handle mismatched records in completely different namespaces and the Lync clients would still connect to the server, albeit followed by a prompt asking the user to trust the server or not. Normally this configuration would not be ideal but in service provider scenarios or when certificate Subject Alternative Name space is limited then additional entries for numerous SIP domain names may be undesirable.
_sipinternaltls._tcp.mslync.net > sip.schertz.name
Lync Phone Edition Behavior
As mentioned the mismatched configuration is no longer allowed as of the CU7 releases for the various Lync Phone Edition devices. This limitation not only applies to SIP registration to the Lync server but also impacts Exchange integration. When the phone performs Exchange Server Autodiscovery if the same cross domain name configuration is in place then the devices will be unable to authenticate to the Exchange server and will display the dreaded exclamation mark icon indicating an Exchange integration failure.
This behavior is as-designed and will not be reversed, according to the Lync product team. Lync Phone Edition devices are only supported for on-premises and Office 365 Lync Online deployments; Lync Hosting Pack and other multitenancy environments are not officially supported, hence the requirement to adhere to strict DNS naming practices.
After receiving some conflicting reports about whether or not Microsoft has changed this behavior in later releases some further testing was performed and an additional, interesting behavior was discovered.
Firstly the behavior has not changed since CU7 (4.0.7577.4372) through the latest release of CU12 in April 2014 (4.0.7577.4444). Microsoft has documented this in Knowledge Base Article ID 2933146 and their guidance is the same as above, in terms of ‘fixing’ the SRV/A record pairing to match as is best practice.
But if this is not addressed there is still another method that Lync Phone Edition can use to successfully connect. Simply use one of the Host (A) fall-back records like sip.domain.com or sipinternal.domain.com. Lync Phone Edition will attempt to resolve all DNS SRV and A records and in the event that the provided SRV record does not pass the strict naming check the device will fall-back to using the hardcoded host records. Thus in the example above if the records are left mismatched simply create an additional host record of sip.mslync.net and make sure that this FQDN is included in the Lync Server certificate. This is just yet another reason to continue to include the recommended (but not mandatory) sip.<sipdomain> record in Lync deployments, even if it’s not leveraged directly by the SRV record.