Lync 2013 paired standard edition pools - DNS SRV record requirements

  • Article

I have deployed two Lync 2013 standard edition servers in a paired mode. Half of the Lync users are hosted in first standard edition pool called Lync01.green.com (pool1) and rest of them are hosted in second standard edition pool called Lync02.green.com (poo2). I am trying to understand the DNS SRV records requirements and client behaviors.

I have created only one SRV record initially,( _sipinternaltls_tcp.green.com ) pointed to pool1. I have decided to take two Lync test users (testuser01-Client1 and testuser02-client2) and they are hosted in Pool1 and pool2 respectively.

Scenario-1 : Both Lync 2013 standard edition servers are up and running

I could see both users were able to login successfully. Client 2 has been redirected to the home server after the initial hit. Here are the UCCP logs for reference;

Scenario-2 : Pool1 failed and pool2 is up and running

During scenario-1 , both the clients were able to cache the server FQDN in the client profile. I have manually shutdown the first standard edition server (pool1). Here are the test results;

  • Client1 was not able to sign-in
  • Client 2 was able to sign-in due to local cache. (It didn’t look at the SRV record due to local cache)
  • I have deleted the local cache from client2 and it also failed to sign-in. So new users should not be able to sign-in when primary server is down.

Following screenshot may help you for reference.

Scenario-3 : Pool2 failed and Pool1 is up and running

End point cache has been cleared from both client machines. I have manually shutdown the second standard edition server (pool2). Here are the test results;

  • Client1 was able to sign-in. (SRV record is pointed to pool1)
  • Client 2 was not able to sign-in. Pool1 has redirected the client to pool2 (user’s home pool) , but it is down as of now.
  • What if clients had an endpoint cache, client1 should be able to sign-in and client2 was able to sign in with Limited connectivity warning. The reason for this behavior is SRV is pointed to pool1 and CMS database is on pool1.

Scenario-4 : A weighted SRV record has been created for pool2. Pool1 went down and Pool2 is up and running.

I have created an additional weighted SRV record for pool2 as below.

Client network logs shows that , both SRV records have been discovered by client initially. Here is the screenshot for reference;

  • Client1 was able to sign-in with limited connectivity warning.  This didn’t happen on scenario-2 as weighed SRV record wasn’t available.
  • Client 2 was able to sign-in. Below screenshot may help you.

Conclusion

Lync 2013 client doesn’t cache the backup registrar information on client profile.  Client registration has been redirected to backup registrar as and when required.  You should configure weighted SRV records for primary and backup registrar for client connectivity.