Lync 2010 Central Site Resilience w/ Backup Registrars, Failovers, and Failbacks – Part 2

Introduction

Welcome to Part 2 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is to wrap all the information out there on how to utilize Central Site Resilience in regards to failovers, fallbacks, how redirects function, how SRV records fit in, etc… We first discussed what the lab setup is going to be using Hyper-V, and then proceeded to take a look at the base topology and configuration.

In this Part, I will go through the sign-in process for each user.  Because the SRV record for sign-in is pointed to A-L14FE1.shudlab.net, the sign-in process will be different for each user logging in.

Part 1

Part 2

Part 3

The Sign-In Process

As shown in Part 1, our SRV record is pointing to A-L14FE1.shudlab.net.  This means when ClientUser1 connects, he will connect directly to his home server.  When ClientUser2 connects, he will connect to A-L14FE1.shudlab.net, will get authenticated, and will receive a 301 redirect to A-L14FE2.shudlab.net.

ClientUser1

This is a completely fresh client.  No Lync 2010 client has signed in and therefore, there is no cached folder with any endpointconfiguration.cache file with a cached server.  The Lync 2010 client will sign in for its first time and do the SRV lookup.

Let’s enable logging on A-Lync14FE1 since that is the server that will be authenticating all Lync 2010 logins.  Essentially, if we had a Director, it would be doing the exact same thing in this situation.  We’ll start logging by going to: Start > All Programs > Microsoft Lync Server 2010 > Lync Server Logging Tool.  Enable the SIPStack option, choose Information, and then choose All Flags.  Then Click Start.

Now that we’re logging, we’ll hop back onto A-Client1, and sign into the Lync 2010 client using the ClientUser1 user account.  We can see that the Lync 2010 Client on A-Client1 signed in successfully and we can see in the Configuration Information (Control + Right-Click on Lync Icon in Notification Area) that we’re connected to A-L14FE1.

Heading back over to- AL14FE1.shudlab.net, let’s take a look at the Lync Logs.  We click Stop and then Analyze to view the logs in Snooper.  Make sure the Lync 2010 Resource Kit tools are installed otherwise Snooper will not launch.  Taking a look at the log, we can see a bunch of incoming Subscribes and a bunch of incoming Service messages.  This Pool has authenticated this user and is now servicing this user.  We see no SIP Redirects and therefore, this ClientUser1 has no idea what its backup registrar is.

Taking a look at the endpointconfiguration.cache file, we can see that this client now has A-L14FE1.shudlab.net cached.  It will no longer try to do an SRV lookup unless it cannot connect to the server specified in this endpointconfiguration.cache file.

ClientUser2

Just like ClientUser1, this is a completely fresh client.  No Lync 2010 client has signed in and therefore, there is no cached folder with any endpointconfiguration.cache file with a cached server.  The Lync 2010 client will sign in for its first time and do the SRV lookup.

Let’s go ahead and start logging again on A-L14FE1.  Refer to the ClientUser1 section on  how to log.  We’re logging on A-L14FE1 instead of A-L14FE2 to see the difference in how A-L14FE1 responds when a user is logging in from a different pool.

Now that we’re logging, we’ll hop back onto A-Client2, and sign into the Lync 2010 client using the ClientUser2 user account.  We can see that the Lync 2010 Client on A-Client2 signed in successfully and we can see in the Configuration Information (Control + Right-Click on Lync Icon in Notification Area) that we’re connected to A-L14FE2.

Heading back over to A-L14FE1.shudlab.net, let’s take a look at the Lync Logs.  We click Stop and then Analyze to view the logs in Snooper.  Make sure the Lync 2010 Resource Kit tools are installed otherwise Snooper will not launch.  Taking a look at the log, we see a ton less data than we did when ClientUser1 logged in.  Again, this is because ClientUser1 was homed on A-L14FE1 whereas ClientUser2 is not homed on A-L14FE1 but is rather homed on A-L14FE2.

Because ClientUser2 is homed on A-L14FE2, when ClientUser2 was initially connecting to A-L14FE2, we can see the authentication occurring, and then A-L14FE2 issues a 301 redirect to ClientUser2.  In the data on the right of the log, we see that in this 301 redirect message, the user is notified what their Primary Registrar is (A-L14FE2.shudlab.net:5061) and their Backup Registrar (A-L14FE1.shudlab.net:5061).  This is why Doug, in his blog article, talked about the benefits of Directors.  A Director will issue 301 redirect for all authenticating users.  This way, clients will know about Primary and Backup Registrar.

But Chris’ article talks about the endpointconfiguration.cache file.  When this ClientUser2 successfully connected, he put ONLY his Primary Registrar into this file.  Because of this, on subsequent attempts, ClientUser2 will connect directly to A-L14FE2.shudlab.net instead of doing an SRV lookup, connecting to A-L14FE1.shudlab.net, and then getting a 301 redirect.  It’s because of this Chris’ article mentions that you should still have multiple SRV records.  They are needed to handle this situation.

Taking a look at the endpointconfiguration.cache file on ClientUser2, we can see that the Backup Registrar is not cached.

Conclusion

Thanks for reading Part 2.  In this Part, I went through the sign-in process for each user.  Because the SRV record for sign-in was pointed to A-L14FE1.shudlab.net, the sign-in process was different for each user logging in.

In Part 3, we’ll then do a failover test and a failback test without a SRV record in place.  We’ll take a look at what happens to ClientUser1 using A-L14FE1 Pool and what happens to ClientUser2 using A-L14FE2 Pool when we take down one of the Pools.  Finally, we’ll take a look at what happens when the Pool that came down comes back online.

To read Part 3 of this article series, click here.