Lync Server 2013 Preview introduces new disaster recovery support for the Response Group application. If an outage occurs in your primary pool, two approaches are available to keep your response groups up and running:

  • 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 FQDN, and then import the response groups to the new pool.

This article describes how to use the new import and export Lync Server Management Shell cmdlets to move response groups from one pool to another in a situation like this.

Author: Ellen Zehr

Publication date: Sep 4, 2012

Product version: Lync Server 2013 Preview

When a disaster strikes and you experience an outage, you want to get back in business as quickly as possible. Now you can export your response groups to a backup pool during an outage so that response groups can continue to receive calls while the outage is resolved. This article explains how to import and export response groups to move them to another pool, whether moving them to a backup pool and then back to the primary pool, or to a totally new pool with a different FQDN.

New Features for Recovering Response Groups

Lync Server 2013 Preview introduces new disaster recovery support in the form of Front End pool pairing. When you deploy paired Front End pools and an outage occurs, you can fail over from the pool with the outage (the primary pool) to the paired pool (the backup pool). After the outage is corrected, you can fail back to the primary pool. Response Group disaster recovery capitalizes on these new features. Pool pairing, together with the new Response Group import and export cmdlets, help you keep the Response Group application running throughout an outage.

The new Response Group export cmdlet backs up the current Response Group configuration of agent groups, queues, workflows, and Response Group application-level settings. The new Response Group import cmdlet imports the configuration from the backup to the pool you specify.

Response Groups During Recovery

During disaster recovery, the following phases occur:

1. Outage occurs. A pool loses service.

2. Fail over to backup pool. Service is transitioned from the primary pool to the backup pool.

3. Recover the primary pool. The problem in the primary pool is solved.

4. Outage resolved (or new pool deployed). The primary pool is brought back into service, or a new pool is deployed to become the primary pool.

5. Failback to primary pool. Service is transitioned back to the primary pool.

Disaster recovery for the Response Group application works as follows:

Response Group settings are backed up on a regular basis by using the Export-CsRgsConfiguration cmdlet. An example of the Export-CsRgsConfiguration cmdlet is:

Export-CsRgsConfiguration –Source "service:ApplicationServer:primary_pool.contoso.com" –Filename "C:\RGSExport_primary_pool"

When an outage occurs, and before fail over to the backup pool, the response groups are imported to the backup pool by using the Import-CsRgsConfiguration cmdlet. An example of this cmdlet is:

Import-CsRgsConfiguration –Destination "service:ApplicationServer:backup_pool.contoso.com" –Filename "C:\ RGSExport_primary_pool"

After response groups are imported to the backup pool, failover is initiated. After failover to the backup pool is complete, the backup pool handles calls to the response groups. During this time, response groups, both those imported from the failed pool and those belonging to the backup pool, can be updated as usual.

The concept of response group ownership is integral to understanding disaster recovery of response groups. Response groups are owned by the pool where the Response Group application runs. During normal times, the primary pool that runs the Response Group application is the owner of the response groups. During fail over, the response groups from the primary pool are handled by the backup pool, but the primary pool is still the owner. Therefore, during failover, the backup pool handles calls to response groups that are owned by the primary pool and response groups that are owned by the backup pool.

After the primary pool is restored and failback is complete, the response groups owned by the primary pool are exported from the backup pool using the Export-CsRgsConfiguration cmdlet with the –Owner parameter. The –Owner parameter creates an export file that includes only the response groups from the primary pool. An example of this cmdlet is:

Export-CsRgsConfiguration –Source "service:ApplicationServer:backup_pool.contoso.com" –Owner "service:ApplicationServer:primary_pool.contoso.com" –Filename "C:\RGSExport_ImportedResponseGroups.zip"

The response groups are then imported back to primary pool. If you rebuilt the pool during the recovery (that is, the Response Group database is empty), whether you used the same FQDN or a different FQDN, the –OverwriteOwner parameter is required. If you did not rebuild the pool, you do not need to use the –OverwriteOwner parameter. However, as a rule of thumb, you can always use the –OverwriteOwner parameter when importing response groups back to the primary pool. An example of this cmdlet is:

Import-CsRgsConfiguration –Destination "service:ApplicationServer:primary_pool.contoso.com" –OverwriteOwner –Filename "C:\RGSExport_ImportedResponseGroups.zip"

If the primary pool cannot be salvaged, a new pool can be set up with a new FQDN. When the new pool is up and running, and after failback is complete, the response groups are imported from the backup pool with the Import-CsRgsConfiguration cmdlet. This time, the –OverwriteOwner parameter is included to assign the new pool as the owner of the response groups. Ownership of response groups remains with the original pool until it is explicitly reassigned by using this parameter. An example of this Import-CsRgsConfiguration cmdlet is:

Import-CsRgsConfiguration –Destination "service:ApplicationServer:new_pool.contoso.com" –Filename "C:\RGSExport_ImportedResponseGroups" –OverwriteOwner

When service is back in the primary pool (or the new pool), response groups owned by the primary pool can be removed from the backup pool by using the Export-CsRgsConfiguration cmdlet with the –Owner and the –RemoveExportedConfiguration parameters. An example of this cmdlet is:

Export-CsRgsConfiguration –Source "service:ApplicationServer:backup_pool.contoso.com" –Owner "service:ApplicationServer:primary_pool.contoso.com –Filename "C:\RGSExport_RemoveUnownedResponseGroups" -RemoveExportedConfiguration

In this example, only the response groups owned by the primary pool are exported from the backup pool and then removed from the backup pool.

Managing Response Groups in the Backup Pool

After you have failed back and imported the response groups to the backup pool, you will need to manage the response groups in the backup pool until recovery is complete and the response groups are imported back to the primary pool.

Important: While the response groups are in the backup pool, you need to use the Lync Server Management Shell to manage them. You cannot use Lync Server Control Panel to manage these response groups.

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. Table 1 illustrates this concept:

Response Group Name

Pool

Parent

Owner

Help Desk

primary.contoso.com
(inactive)

service:ApplicationServer:
primary.contoso.com

service:ApplicationServer:
primary.contoso.com

Help Desk

backup.contoso.com
(active)

service:ApplicationServer:
backup.contoso.com

service:ApplicationServer:
primary.contoso.com

Table 1. Response groups during failover.

During failover, Response Group cmdlet results are somewhat different. Table 2 describes cmdlet results when the cmdlet includes the specified parameter. These guidelines apply to the following cmdlets:

  • CsRgsAgentGroup
  • CsRgsQueue
  • CsRgsWorkflow
  • CsRgsHolidaySet
  • CsRgsHoursOfBusiness

Response
Group
Cmdlet

Parameter

Results

Get

-Name
(for example, Help Desk)

All "Help Desk" objects that have matching parent and owner services are returned.

During failover, no response group named "Help Desk" is returned.

Get

-Showall

All objects are returned regardless of whether the parent and owner services are the same or different.

During failover, the objects in the backup pool are returned (both imported and owned by the backup pool).

Get

-Identity
primary.contoso.com

All objects that have matching parent and owner services are returned.

During failover, no objects are returned.

Get

-Identity
backup.contoso.com

All objects that have matching parent and owner services are returned.

During failover, no imported response group objects are returned. Only objects owned by the backup pool are returned. (Adding the –ShowAll or –Owner parameter would return imported objects. See next entry.)

Get

-Identity
backup.contoso.com

-Owner
primary.contoso.com

Because the –Owner parameter is included, all object with the primary pool as owner and the backup pool as parent are returned.

During failover, the imported response group objects are returned.

Get

-Identity
backup.contoso.com

-Owner
primary.contoso.com

-ShowAll

All objects are returned regardless of whether the parent and owner services are the same or different.

During failover, the imported objects are returned. Because the owner is specified, no objects owned by the backup pool are returned.

Set

-Instance

Because instance is usually specified by obtaining the results of a Get cmdlet, the Set cmdlet modifies the object retrieved by the Get cmdlet.

During failover, the imported object retrieved by the Get cmdlet will be modified.

Remove

-Instance

Because instance is usually specified by obtaining the results of a Get cmdlet, the Remove cmdlet modifies the object retrieved by the Get cmdlet.

During failover, the imported object retrieved by the Get cmdlet will be removed.

Table 2. Response Group cmdlet results during failover.

Caveats and Notes

IMPORTANT: Keep a separate backup copy of all the original audio files you use for response groups. These may include recordings and music-on-hold files. The export and import cmdlets do not include custom audio files.

IMPORTANT: The following Response Group settings must have unique names across the deployment: workflows, queues, agent groups, holiday sets, and hours of business. This requirement avoids name conflicts during imports to a backup pool.

NOTE: If the primary pool is failed over to the backup pool but the backend of the primary pool is available, either during the disaster or before the failback to the primary pool is complete, you can see the response groups owned by the primary pool both in the Lync Server Control Panel and with Lync Server Management Shell cmdlets. However, the database for the Response Group application in the primary pool is in read-only mode, and modification to those response groups is not allowed. If you need to modify response groups, you must make the modifications to the response groups that were imported to the backup pool, which is the pool that processes the calls. Alternatively, wait to make modifications until the primary pool is fully restored and failback is complete.

NOTE: The Response Group application has some settings on the application level. These settings include the default music-on-hold audio file, the default music-on-hold configuration, the agent ringback grace period, and the call context configuration. Application-level settings are a special consideration during disaster recovery because there can be only one set per pool. Although you can use the Import-CsRgsConfiguration cmdlet with the –ReplaceExistingSettings parameter to transfer the settings from the primary pool to the backup pool, the settings in the backup pool are then overridden. On the other hand, if you don't transfer the settings to the backup pool and the primary pool can't be recovered, the primary pool settings are lost. A new pool will use the default settings, and you need to configure the new pool for your customizations, including the music-on-hold file.

NOTE: How response group calls are handled during an outage depends on the phase you are in. For details about how users experience an outage through all the phases, see Response Group Experience During Pool Failure.

NOTE: Agents homed in a pool that is not functioning are not reachable by the Response Group application until failover is complete.

Summary

The new Export-CsRgsConfiguration and Import-CsRgsConfiguration cmdlets provide a way to transfer response groups from a failed primary pool to a backup pool during disaster recovery. Then after recovery, the response groups can be transferred back to the original pool or to a new, replacement pool. Response groups have an owner pool, which needs to be reset with the Import-CsRgsConfiguration cmdlet if the response groups are permanently moved to a different pool.

Additional Information

To learn more, check out the following articles:

Lync Server Resources

We Want to Hear from You

Keywords: response groups, disaster recovery