I have a coexistence issue: I need to have a boatload of R2 clients connect to a new Lync 2013 environment. Backwards compatibility has been installed, the R2 environment has been imported with Topology Builder, and users can be moved between the R2 pool and the new 2013 pools. We can chat back and forth, send files, use A/V and even participate in the same conferences. External, remote, and Federation scenarios work just fine.
So what is the issue? Today, the _sipinternaltls._tcp.domain.com SRV record points to the FQDN of the R2 pool. Which works just fine. When the 2013 pilot group cranked up, they found the lyncdiscoverinternal.domain.com record, hit the 2013 pool as expected, and logged in. Perfect. The issue in front of us today is moving the target of the _sipinternaltls._tcp.domain.com from ocspool1.domain.com to sip.domain.com - we want to decommission the R2 pool at the end of this project.
Our plan is to simply set the SRV record TTL and the associated A record TTL to something very short, and then after waiting for that propogate, change the SRV target to sip.domain.com. To test this, we went to an R2 client and set the manual configuration as shown.
However, this failed with “server not available.” We also noted that on the initial setting of “manual” the TLS option was greyed out and the initial connection attempt failed. Checking the manual settings again revealed the TCP setting selected, but now we could change to TLS as the settings were no longer greyed out. Odd. Strange. And totally consistent from machine to machine. Can’t explain it. After the initial failure, the TLS setting would hold, but still we had “server not available.”
After running around the settings several times, and checking the Client Version policy at least twice, and making sure that the workstations in question could resolve sip.domain.com properly, we turned to the Client Version Policy again. It turns out that this is the default setting for the Lync 2013 Client Version Policy. Note that it says OC 3.5.6907.233 and OLDER should be blocked.
A cursory check of the clients tested showed versions of 3.5.6907.261 and 253. Newer right? Apparently not! Setting this policy element to ALLOW fixed the issue and now the mix of R2 clients can login just fine using sip.domain.com as the “director.” which points to the new 2013 pool. Because the SIP domain and the AD domain names match, there are no certificate issues.