Lync Secondary Registrar Discovery

How a Lync client finds its secondary registrar is a very important topic. After some research and reading an excellent blog by Doug Deitterick on Technet about the process there are some very clear best practices that standout to me. The reason I bring it up here is that my opinion around using a Director for secondary registrar discovery is slightly different to Doug’s. There is a more critical component than the Director for this function. Let me explain.

Let’s take a quick recap at how the process works. The diagram below give’s a good outline of how this works when you have a Director pool in place.

The most important functions related to our discussion are the prioritized DNS SRV responses and the SIP 301 redirect message that is sent back to the client. The DNS SRV records point to the Director as the primary logon and authentication pool with a alternate pool as a backup. The 301 message contains the Primary and secondary registrar. Both of these items are very important to the logon process. Firstly should the Director pool (or any pool related to the DNS SRV record) be unavailable you have an alternative to actually logon and secondly once you have authenticated you can learn where your primary and secondary registrar is located for failover.

It is best practice that you have prioritized DNS SRV records regardless of a Director.  Every registrar in your deployment has the ability to use the 301 redirect message process including the SBA. The only time you do not receive your backup registrar information via a 301 is when you log directly onto your primary registrar. Once you have successfully logged onto your primary registrar and it is cached by the client (using the EndpointConfiguration.cache  file) unless there are issues, you are very unlikely to receive a 301 message. As Doug points out EndpointConfiguration.cache  doesn’t cache your secondary registrar. So in other words the Director is little help after you successfully logon for the first time.

I did a small experiment in my home lab. I started up my Lync client and as it had a cached primary registrar it did not perform the DNS SRV record lookup and it logged on using cached information. I then stopped the frontend service on my Lync Server. The Lync client then preformed the DNS SRV lookup to find an alternate location to logon. Once it received the alternate SRV records it was been able to locate an alternate place to logon. It then received a SIP 301 redirect. Had I actually had a real alternate SE running in my environment it would have logged in there as its secondary registrar after referring to the SIP 301 redirect secondary information.

So how would you create your DNS SRV records ? There two options:

1. Deploy a Director with prioritized DNS SRV records that point to the Director(s) as the first choice and a pool (whether it be a SE or EE pool) in another datacenter as your second choice.

2. With no Director(s) point your prioritized DNS SRV records at the pools that make sense but are most likely located in different datacenters.

Doug’s blog post does make a great point that you will not always get backup registrar information every time you logon but its regardless of whether you are using a Director or not because of the cached primary registrar. This is why it is important to ensure your DNS SRV records are correctly configured when using data center voice resiliency features, so don’t leave home without them.

Comments welcomed.

VoIPNorm