The aim of this test is to understand Lync 2013 (Preview) client behavior during an infrastructure failure.
My lab environment consists of Lync 2013 (P) EE Pool with two frontend servers, dedicated SQL backend server and two Lync 2013 (P) clients.
Scenario-1 – Primary Frontend Server went down
Lync 2013 (P) client has been successfully connected to Lync pool (Fig.1).
I took UCCP logs from client machine; primary sip registrar was Lync2013-FE1.fabricam.com. (Fig.2)
I had manually shutdown primary registrar (Lync2013-FE1.fabricam.com) for testing. Configured network trace and UCCP log on the client machine. Lync client was signed out for 10-20 seconds (Fig.3).
Lync client found other Frontend server’s IP address and MAC address via DNS look up(Lync2013-FE2.fabricam.com). It had sent a broadcast and identified the frontend server details. (Fig.4)
Right after the DNS lookup , client had sent another registration request to Lync2013-FE2.fabricam.com and frontend server accepted the message. Client signed back online successfully . Below figure shows registration request to FE2 (Fig.5).
Network trace collected, it was clear that packet failed over from one frontend to another server (Fig.6)
Scenario-2 – Primary Frontend Server back from failure
I had started Lync frontend server (FE1) after few minutes. All Lync services came back as expected. Lync client had sent a registration request to FE1 as soon as it came online. Registration request was quite visible on the UCCP log. Another important point was , Client didn’t signed out during the transition and it was online. (Fig.7)
Scenario-3 – Lync backend SQL database went down
After FE server failover, I had manfully shutdown SQL backend database. My pool and CMS database were hosted on this SQL server.
Once SQL went down, Client had shown limited connectivity warning (Fig.8)
I have captured service unavailable errors on UCCP logs (Fig.9)
Scenario-4 – Lync backend SQL database back from failure
I had started SQL server after few minutes. All database services came back as expected. Lync client had sent deregister and registration request as soon as SQL server came online. It took 8-15 seconds to change the client warning message . Here is the request on UCCP log. Client came online successfully. (Fig.10)
I hope this test results would be helpful to understand Lync client behavior on a infrastrucutre failure.