Microsoft Lync Site Failover for Lync 2013

Microsoft Lync Site FailoverMicrosoft Lync Site Failover

By Romeo Cavestany
Systems Engineer

A client recently brought us in for some disaster recovery testing drills, including doing a complete Microsoft Lync site failover for their Microsoft Lync and Persistent Chat environment from their primary datacenter to their secondary datacenter. The exercise included failing over all of the Lync services—including front-end services, Persistent Chat, SQL and file store—and then failing it back again. The drill went very smoothly, which gave everyone involved peace of mind that in the event of an actual disaster, the disaster recovery plan will work.

Lync 2013’s Pool Pairing simplifies the Microsoft Lync Site failover

One thing that made the failover easier was that our client was running Microsoft Lync 2013. Different than previous versions of Lync, Lync 2013 offers a disaster recovery option called Lync Pool Pairing for all of Lync’s front-end services. With Lync Pool Pairing, services at one datacenter are paired with the same services at the other datacenter, so that failing over is primarily a matter of manually moving the users to the secondary site.

However, Lync Pool Pairing only applies to the Lync front-end services; it does not apply to Persistent Chat. With Microsoft Lync 2013 the failover process for Persistent Chat is still a manual process. The Persistent Chat servers at the two datacenters are connected through a “Stretched pChat Pool,” for which a failover is more complex, and the SQL and file stores are not in “pools” at all. In order for users to get connected to Persistent Chat servers at the secondary datacenter, the “Stretched pChat Pool” database needs to be failed over from the primary datacenter to the secondary datacenter. This allow Lync’s frond-end services to route Persistent Chat connections to the pChat servers at the secondary datacenter.

How to do a complete Microsoft Lync site failover for Lync 2013 & Persistent Chat

Here are the steps that we recommend:

  1. Failover the Microsoft Lync front-end services
    • Use the Lync control panel to manually move the users to the secondary datacenter. To do this, simply select the users from the primary pool and then move them to the secondary pool.
    • Use the following command to failover the Lync Pool Pairing Pool from the primary datacenter to the secondary datacenter:

Invoke-CsPoolFailOver –PoolFqdn “primarydatacenter.domain.com” –DisasterMode2

  1. Prepare the Persistent Chat backup database

    Note: These instructions assume the use of SQL Log Shipping as the database recovery solution.

   This step will prepare the Persistent Chat backup database, copy the transaction logs to the servers at the secondary site, and bring the secondary database online.

  • Remove log shipping from the Persistent Chat Server Backup Log Shipping database.

    To do this, using SQL Server Management Studio, connect to the database instance where the Persistent Chat Server backup database is located. Open a query window to the master database, and then use the following command:

exec sp_delete_log_shipping_secondary_database mgc

 

  • Copy any uncopied backup files from the backup share folder to the copy destination folder of the backup server.
  • Apply any unapplied transaction log backups in sequence to the secondary database. For instructions on how to do this, see “How to: Apply a Transaction LogBackup (Transact-SQL).”
  • Bring the secondary database online. Using the query window that was opened in step 2a, end all connections to this database, if there are any. Use exec sp_who2 to identify connections to the backup database.

   Use kill <spid> to end these connections.

  1. Set the Persistent Chat Pool state as failed over

    After this is completed the backup database will now serve as the primary database.

  Set-CsPersistentChatState -Identity “Service:PersistentChatpool.domain.com” –PoolState FailedOver

 

  Then use the Get-CSPersistentChatState command to verify that the Persistent Chat Pool state is marked as “Failed Over.”

  1. Change the next routing hop of the Persistent Chat pool to the secondary datacenterTo do this, open Topology Builder, load the topology, and expand Persistent Chat pools. Right click the Persistent Chat pool and select edit properties. Change the next hop to point to the secondary datacenter. Click OK, select action, and then publish the topology.
  2. Set the Persistent Chat Active servers in the secondary datacenterAt this point we want to make sure all the Persistent Chat servers in the secondary datacenter are active, and all the Persistent Chat servers in the primary datacenter are inactive. To do this, use the following command:

Set-CsPersistentChatActiveServer –Identity “Service:PersistentChatpool.domain.com” –ActiveServers @{Add=”SecondaryPChatserver.domain.com”}

 

Set-CsPersistentChatActiveServer –Identity “Service:PersistentChatpool.domain.com” –ActiveServers @{Remove=”PrimaryPChatserver.domain.com”}

 

  Once the failover is complete users can reconnect, and all Persistent Chat functionality will be restored using services from the secondary (paired) datacenter.

How to do a complete site failback for Microsoft Lync 2013 & Persistent Chat

Once your primary datacenter comes back online, you’ll need to do a complete site failback. After all, your secondary datacenter is just meant for short-term disaster recovery purposes.

Here are the steps that we recommend you follow:

  1. Failback the front-end services
    • Use the Lync control panel to manually move the users back to the primary datacenter. To do this, simply select the users from the secondary pool and then move them to the primary pool.
    • Use the following command to failback the Lync Pool Pairing Pool from the secondary datacenter to the primary datacenter:

Invoke-CsPoolFailback -PoolFqdn “primarydatacenter.domain.com”

  1. Clear all servers from the Persistent Chat Server Active Server list

    Use the following command to do this:Set-CsPersistentChatActiveServer (no switches)
  2. Back up the secondary database so that it can be restored to the primary database
    1. Using SQL Server Management Studio, connect to the backup database.
    2. Right-click the database, point to Tasks, and then click Back Up. The Back Up Database dialog box will appear.
    3. In Backup type, select Full.
    4. For Backup component, click Database.
    5. Either accept the default backup set name suggested in Name, or enter a different name for the backup set.
    6. <Optional> In Description, enter a description of the backup set.
    7. Remove the default backup location from the destination list.
    8. Add a file location to the destination list by using the path to the share location that you established for log shipping. This path is available to both the primary database and to the backup database.
    9. Click OK to close the dialog box and begin the backup process.
  3. Restore the primary database by using the backup database created in step 3

    1. Using SQL Server Management Studio, connect to the primary database.
    2. Right-click the database, point to Tasks, point to Restore, and then click Database. The Restore Database dialog box will appear.
    3. Select From Device.
    4. Click the browse button, which will open the Specify Backup dialog box. In Backup media, select File. Click Add, select the backup file that you created in step 3, and then click OK.
    5. In Select the backup sets to restore, select the backup.
    6. Click Options in the Select a page
    7. In Restore options, select Overwrite the existing database.
    8. In Recovery State, select Leave the database ready to use.
    9. Click OK to begin the restoration process.
  4. Set Persistent Chat Pool state as Normal

   To restore the Persistent Chat Pool to its normal state, run the following Lync Server Management Shell command:

   Set-CsPersistentChatState -Identity “Service:PersistentChatpool.domain.com” -PoolState Normal


   For more information, see the help topic for the Set-CsPersistentChatState cmdlet.

Then use the Get-CSPersistentChatState command to verify that the Persistent Chat Pool state is marked as “Normal.”

  1. Set the active Persistent Chat servers to the primary servers

    To do this, open a Lync Management Shell and list the active servers:

  Get-CsService –PersistentChatServer | fl *activeservers

 

  Add the Persistent Chat servers if they are not in the list of already active servers:

   Set-CsPersistentChatActiveServer –Identity “Service:PersistentChatpool.domain.com” –ActiveServers @{Add=” PrimaryPChatserver.domain.com “,”SeconardyPChatserver.domain.com}

 

    Then run Get-CsService again to verify the list of active servers.

 

  1. Change the next routing hop of the Persistent Chat pool back to the primary datacenter

    To do this, open Topology Builder, load the topology, and expand Persistent Chat pools. Right click the Persistent Chat pool and select edit properties. Change the next hop to point to the primary datacenter. Click OK, select action, and then publish the topology.
  2. Open a Microsoft Lync client and test Lync services to see if it works.

 

Conclusion: You need to test your disaster recovery plans

As I mentioned in my previous article on “Creating & Testing a Disaster Recovery Plan for Lync Persistent Chat Server,” it’s not enough to have a plan in place. You also need to test it to see if it works! Hopefully this article about Microsofty Lync Site Failover can help you with that.

Want to put a team of experts in charge of managing and monitoring your environment – including handling disaster recovery if something goes wrong? Give us a call. This is what our Remote Monitoring and Management service is all about.