About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. 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. The opinions expressed on this blog are mine and mine alone.

2013/04/18

OCS R2 client and Lync 2013 Server

Scenario

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. 

clip_image002

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.”

The Fix

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. 

image

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.

YMMV.

2 comments:

Lisha said...

I am trying to create a comparsion chart between OCS 2007 R2, Lync 2010 and Lync 2013 clients connected to Lync Server 2013.

When you refer to conference working do you mean via the OCS 2007 R2 client or via the Lync 2013 Web App.

Can you have multiple IM conversations going?

tsoorad said...

To get the OCSR2 environment to appear in the Lync environment Topology Builder, you need to install the backcompat.msi from the setup directory on the distro ISO.
And yes, conferencing between R2 pool members and Lync Pool users worked just fine. And yes, multiple IM worked fine also.

test 02 Feb

this is a test it’s only a test this should be a picture