Planning for response group disaster recovery in Lync Server 2013

 

Topic Last Modified: 2012-11-01

This section describes some ways to prepare response groups for disaster recovery and provides an overview of the disaster recovery process.

Preparing for Response Group Disaster Recovery

Keep the following in mind when you prepare for and carry out disaster recovery procedures.

Note

In a coexistence environment, only the Lync Server 2013 response groups are supported for the disaster recovery procedures described in this document.

• Plan for disaster recovery when you do your capacity planning. For disaster recovery capacity, each pool in a paired pool should be able to handle the workloads of all the response groups in both pools. For details about Response Group capacity planning, see Capacity planning for Response Group in Lync Server 2013.

• Take regular backup copies of all the response group configurations in all the Front End pools where you deployed the Response Group application by using the export procedure described in this document. For details, see Response group disaster recovery procedures in Lync Server 2013. Keep the backup copies in a safe location.

• Keep a separate backup copy of all the original audio files you used for the Response Group application, including any recordings and music-on-hold files. Keep the backup files in a safe location.

• For Lync Server 2013 disaster recovery, all Response Group settings must have unique names across your deployment. This requirement applies to workflows, queues, agent groups, holiday sets, and hours of business. You should verify that this requirement is met when the primary and backup pools are still active, and before you need to initiate any failover procedure. If you encounter name conflicts while importing response group data to the backup pool, the import fails. To complete the import and failover procedure, you need to resolve the name conflicts by renaming the response group object in the backup pool or by using the Import-CsRgsConfiguration cmdlet with the –ResolveNameConflicts parameter to automatically resolve the conflict by appending a unique identifying number to the response group object.

• In general, we recommend that you perform daily backups, but if you have a high volume of changes, you might want to schedule more frequent backups. The amount of information you can lose in the event of a disaster depends on the frequency of your backups, as well as the frequency and volume of changes.

• It is possible to import response groups to a backup pool before a disaster or failover operation occurs. Importing response groups in advance reduces downtime, because the Lync Server Response Group service can be restored in the backup pool as soon as calls are routed to the backup pool.

  Note

  The Response Group application cannot reach any agents homed in an inactive pool until failover is complete. During this time, the Response Group application processes calls as if those agents are unavailable.

Response Group Disaster Recovery Process

In the event of a disaster, you can recover response groups by using either of the following recovery approaches:

• Fail over to a backup pool and then fail back to the original pool.

• Fail over to a backup pool, create a new pool with a different fully qualified domain name (FQDN), and then import the response groups to the new pool.

During the failover phase of disaster recovery, the response groups reside in multiple pools: in the primary pool (which is unavailable) and in the backup pool. The response groups in both pools have the same name and the same owner (the primary pool), but they have different parents.

When you recover by creating a new pool with a different FQDN, you need to assign the new pool as the owner of the response groups when you import them. Ownership of response groups remains with the original pool unless or until you explicitly reassign ownership by using the –OverwriteOwner parameter with the Import-CsRgsConfiguration cmdlet.

Note

You also need to use the –OverwriteOwner parameter if you rebuilt the pool during the recovery (that is, the Response Group database is empty), whether or not you use the same FQDN. You do not need to use the –OverwriteOwner parameter if you did not rebuild the pool, but it is permissible to use this parameter whenever you import response groups back to the primary pool.

You can define only one set of application-level Response Group configuration settings per pool. These settings include the default music-on-hold configuration, the default music-on-hold audio file, the agent ringback grace period, and the call context configuration. To view these configuration settings, run the Get-CsRgsConfiguration cmdlet. For details about the Get-CsRgsConfiguration cmdlet, see Get-CsRgsConfiguration.

You can transfer these application-level settings from one pool to another by using the Import-CsRgsConfiguration cmdlet with the –ReplaceExistingSettings parameter, but doing so overrides the settings in the destination pool.

Important

This constraint about transferring settings to another pool is true only for the application-level settings and the default music-on-hold audio file. It does not apply to agent groups, queues, workflows, business hours, and holiday sets.

If you don't want to replace the application-level settings in the backup pool during a disaster and the primary pool can't be recovered, the application-level settings from the primary pool will be lost. If you need to create a new pool to replace the primary pool during recovery, either with the same FQDN or with a different FQDN, you can't recover the original application-level settings. In this case, you need to configure the new pool with these settings and include the music-on-hold audio file.

If you decide to use the Import-CsRgsConfiguration cmdlet to transfer application-level settings from the primary pool to the backup pool during a disaster, you can then transfer the settings from the backup pool to the new pool during recovery in the same way that you transferred them from the primary pool to the backup pool.

The following table is an overview of the steps involved in recovering response groups.

For details about performing these steps, see Response group disaster recovery procedures in Lync Server 2013.

Response Group Disaster Recovery Steps

Phase	Steps	Required groups and roles
Before outage	On a routine basis, run the Export-CsRgsConfiguration cmdlet to create backups of all Response Group configurations in all Front End pools where Response Group application is deployed.	RTCUniversalServerAdmins CsResponseGroupAdministrator
During outage	Run the Import-CsRgsConfiguration cmdlet to import the backed up Lync Server Response Group service configuration from the primary pool to the backup pool. Note Use the –ReplaceExistingSettings parameter if you want to replace application-level Response Group settings in the backup pool with the settings from the primary pool. If you do not transfer the application-level settings from the primary pool to the backup pool, and the primary pool can't be recovered, you will lose the settings from the primary pool.	RTCUniversalServerAdmins CsResponseGroupAdministrator
After importing	Run Response Group cmdlets with either the –ShowAll parameter (to display all response groups) or the –Owner parameter (to display only imported response groups) to verify that all response group configurations were imported to the backup pool. Important If you do not use either the –ShowAll parameter or the –Owner parameter, the response groups that you imported to the backup pool will not be listed in the results returned by the cmdlets. Run the following cmdlets: Get-CsRgsWorkflow Get-CsRgsQueue Get-CsRgsAgentGroup Get-CsRgsHoursOfBusiness Get-CsRgsHolidaySet	RTCUniversalServerAdmins CsResponseGroupAdministrator
After failover	Place a test call to a response group that was imported to the backup pool and verify that the call is handled correctly. All formal agents must sign in again to their formal groups on backup pool. Manage configuration changes: Response groups in the backup pool, whether imported to the backup pool or owned by the backup pool, can be modified as usual during the outage. Important You must use Lync Server Management Shell to manage the response groups that you imported to the backup pool. You cannot use Lync Server Control Panel to manage these response groups while they are in the backup pool.	N/A
After recovery, before failback	Run the Export-CsRgsConfiguration cmdlet specifying the -Source parameter as the backup pool and the –Owner parameter as the primary pool to export the response groups owned by the primary pool from the backup pool.	RTCUniversalServerAdmins CsResponseGroupAdministrator
After failback	Run the Import-CsRgsConfiguration cmdlet to import the response groups back to the primary pool. Note If the primary pool can't be recovered and you deploy a new pool to replace it, use the –ReplaceExistingSettings parameter to transfer the application-level settings from the backup pool to the new pool. If you do not transfer the settings from the backup pool, the new pool will use the default settings. Run the following cmdlets with either the –ShowAll parameter (to display all response groups) or the –Owner parameter (to display only imported response groups) to verify that all response group configurations were successfully imported back to the primary pool: Get-CsRgsWorkflow Get-CsRgsQueue Get-CsRgsAgentGroup Get-CsRgsHoursOfBusiness Get-CsRgsHolidaySet Place a test call to a response group that was imported back to the primary pool and verify that the call is handled correctly. Optionally, run the Export-CsRgsConfiguration cmdlet on the backup pool with the –RemoveExportedConfiguration parameter to remove the response groups owned by the primary pool from the backup pool.	RTCUniversalServerAdmins CsResponseGroupAdministrator