Table Of Contents

Cisco Unity Failover Configuration and Administration Guide

Effects on Cisco Unity Web Applications When Failover or Failback Occurs

Using Cisco Unity Failover with Integrations via PIMG Units

The Force Failover Setting Must Be Checked

Preparing for Manual or Scheduled Failback (Integrations via PIMG Units Only)

How Failover Works When Cisco Unity Is Integrated via PIMG Units

Effects of Failover and Failback on Calls in Progress

Intervals for Failover and Failback

Failover Interval

Failback Interval

Causes of Both Servers Becoming Active at the Same Time

Errors

Notifying Subscribers to Update the Server Name in the Media Master

Cisco Unity Failover Configuration and Administration Guide

---

This chapter should be used in conjunction with the Cisco Unity Failover Configuration and Administration Guide (With IBM Lotus Domino), Release 4.0(5) and Later and with the Cisco Unity Failover Configuration and Administration Guide (With Microsoft Exchange), Release 4.x. New features are described in individual sections. Information that has changed in the Cisco Unity Failover Configuration and Administration Guide—either because Cisco Unity functionality changed or because the information is incorrect—is described in the "Errors" section at the end of the chapter.

This chapter contains the following sections:

•Effects on Cisco Unity Web Applications When Failover or Failback Occurs

•Using Cisco Unity Failover with Integrations via PIMG Units

•Errors

Effects on Cisco Unity Web Applications When Failover or Failback Occurs

Subscribers must use the correct URLs to access the Cisco Unity Administrator, Status Monitor, and the Cisco Personal Communications Assistant (PCA) on the active server. When failover or failback occur and subscribers use the URL for the inactive server to browse to a Cisco Unity web application, Cisco Unity does not automatically redirect them to the active server.

Subscribers can continue to access Cisco Unity web applications on the inactive server, but the applications do not work as expected:

•When subscribers access the Cisco Unity Administrator on the inactive server, they are not allowed to save changes.

•When subscribers access the Cisco PCA on the inactive server, any changes they make in the Cisco Unity Assistant can be saved, but the changes are not replicated on the active server and are then overwritten when failover or failback occurs.

In contrast, subscribers who use the phone as a recording or playback device for the Media Master control bar can continue to do so without having to manually update it with the applicable server name. This is because when failover or failback occurs, the Media Master automatically directs the request to place the call to the active server, regardless of the URL that the subscriber used to access the Cisco Unity web application.

Note that depending on the application and how the Cisco Unity server is set up, the server name that is displayed in the Media Master may not be updated, but that does not prevent the correct server from placing the call. For example, the server name displayed in the Media Master that appears in the Cisco Unity Administrator and with Cisco Unity ViewMail for Microsoft Outlook does not change. When failover or failback occur, the name displayed is the one that the subscriber entered when they set up the Media Master to use the phone as a recording or playback device. The same is true for the Cisco PCA when you prevent the Media Master from being set up automatically. (You can use the Advanced Settings Tool to change the default setting for the Unity Inbox and Assistant—Automatically Set Up TRAP in Media Master.) Otherwise, the server name displayed in the Media Master that appears in the Cisco PCA reflects the server that subscribers browsed to when they entered the URL for the Cisco PCA.

Using Cisco Unity Failover with Integrations via PIMG Units

For Cisco Unity 4.1(x) and later, integrations via PIMG units support failover. The following sections provide only the new information about these integrations. Use this information with the information in the Cisco Unity Failover Configuration and Administration Guide to understand failover for integrations via PIMG units.

•The Force Failover Setting Must Be Checked

•Preparing for Manual or Scheduled Failback (Integrations via PIMG Units Only)

•How Failover Works When Cisco Unity Is Integrated via PIMG Units

•Effects of Failover and Failback on Calls in Progress

•Intervals for Failover and Failback

•Causes of Both Servers Becoming Active at the Same Time

The Force Failover Setting Must Be Checked

For integrations via PIMG units, the Force Failover If Call Arrives on Inactive Secondary check box in the Failover Monitor must be checked so that failover can function correctly. If this check box is not checked, failover will not function correctly.

If you customize failover settings in the Failover Monitor, confirm that Force Failover If Call Arrives on Inactive Secondary check box remains checked.

Preparing for Manual or Scheduled Failback (Integrations via PIMG Units Only)

When Cisco Unity is integrated with a circuit-switched phone system via PIMG units and you want failback to occur (the secondary server is currently active), do the following procedure before the secondary server fails back to the primary server.

To Disable Failover Initiation When Calls Are Unanswered on the Primary Server

---

Step 1 On the secondary server, on the Windows Start menu, click Programs > Cisco Unity > Failover Monitor.

Step 2 Click Configure.

Step 3 Uncheck the Force Failover If Call Arrives on Inactive Secondary check box.

Step 4 Click OK.

---

Approximately 10 seconds after the primary server becomes active and failback occurs, do the following procedure.

To Enable Failover Initiation When Calls Are Unanswered on the Primary Server

---

Step 1 On the secondary server, on the Windows Start menu, click Programs > Cisco Unity >Failover Monitor.

Step 2 Click Configure.

Step 3 Check the Force Failover If Call Arrives on Inactive Secondary check box.

Step 4 Click OK.

---

How Failover Works When Cisco Unity Is Integrated via PIMG Units

Figure 2-1 shows a failover configuration for a circuit-switched phone system in an integration via PIMG units.

Figure 2-1 Failover Configuration for a Circuit-Switched Phone System Integrated via PIMG Units

In this integration, the PIMG units control when failover is initiated by sensing that the primary server is not responding. If the primary server is unresponsive, the PIMG units will direct calls to the secondary server, which will become active.

After a failure of the primary server occurs and before the secondary server becomes active, subscribers will hear a ringback tone or will be transferred to an attendant when they dial the internal phone number to log on to Cisco Unity by phone. When the secondary server becomes active, Cisco Unity functions normally.

You can configure the secondary server to initiate failback daily. When failback succeeds, the primary server becomes the active server again. Alternatively, you can configure failover so that the secondary server fails back only when you manually initiate failback by using the Failover Monitor. However, integrations that use PIMG units require temporarily unchecking the Force Failover If Call Arrives on Inactive Secondary check box when failback occurs. For instructions, see the "Preparing for Manual or Scheduled Failback (Integrations via PIMG Units Only)" section.

Effects of Failover and Failback on Calls in Progress

When failover or failback is initiated, calls in progress are maintained or dropped as described in the Cisco Unity Failover Configuration and Administration Guide and in the following section, "Intervals for Failover and Failback."

Intervals for Failover and Failback

Failover Interval

When failover occurs, the time it takes for the secondary server to begin answering calls typically depends on what causes failover as described in Table 2-1.

Table 2-1 Interval for Failover 

Failover Cause	Time
Manual failover	•For integrations via PIMG units, calls are redirected to the extension of an attendant to be answered manually for approximately ten seconds, then the secondary server begins answering calls.
Network outage	•For integrations via PIMG units, calls in progress may be dropped, depending on the nature of the network outage.
Failure of the AvCsMgr service on the primary server	•The secondary server begins answering calls immediately. •Calls in progress on the primary server are dropped.
Failure of the operating system on the primary server	•The secondary server begins answering calls after waiting for the number of keep-alive events set in the Missed Events Before Failover field in the Failover Monitor. The time required depends on the value of the field and on the value of the Interval (ms) field. The default settings for the fields result in a 30-second delay for the secondary server to become active. •Calls in progress on the primary server are dropped.
Inactive secondary server answers a call	•The secondary server begins answering calls immediately. •Calls in progress on the primary server are not dropped but are maintained until the callers hang up.

Failback Interval

When failback occurs, the time it takes for the primary server to begin answering calls typically depends on what causes failback as described in Table 2-2. File replication occurs in the background and does not affect the failback interval.

Table 2-2 Interval for Failback 

Failback Cause	Time
Automatic failback, and the primary server is on but inactive	•For integrations via PIMG units, the primary server begins answering calls as soon as the PIMG units re-establish their connection to the primary server (in approximately ten seconds).
Manual failback, and the primary server is on but inactive	•For integrations via PIMG units, the primary server begins answering calls as soon as the PIMG units re-establish their connection to the primary server (in approximately ten seconds).
Failure of the AvCsMgr service on the secondary server, and the primary server is on but inactive	•For integrations via PIMG units, the primary server begins answering calls as soon as the PIMG units re-establish their connection to the primary server (in approximately ten seconds).
Failure of the operating system on the secondary server, and the primary server is on but inactive	•For integrations via PIMG units, the primary server begins answering calls as soon as the PIMG units re-establish their connection to the primary server (in approximately ten seconds).

Causes of Both Servers Becoming Active at the Same Time

Under some circumstances, both the primary server and secondary server can become active at the same time, as indicated in the Failover Monitor. The condition can occur when the network connection to the primary server is lost, so both servers become active. For integrations via PIMG units, Cisco Unity will receive no calls. However, if the primary server loses its connection to the PIMG units while the secondary server retains its connection, calls can reach the secondary server and initiate failover.

Errors

The following section applies to the Cisco Unity Failover Configuration and Administration Guide (With IBM Lotus Domino), Release 4.0(5) and Later at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/fail/fail401/dom/index.htm and to the Cisco Unity Failover Configuration and Administration Guide (With Microsoft Exchange), Release 4.x at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/fail/fail401/ex/index.htm.

Notifying Subscribers to Update the Server Name in the Media Master

The "Notifying Subscribers to Update the Server Name in the Media Master" section in the "Tasks Required When Failover or Failback Occurs" chapter of the Cisco Unity Failover Configuration and Administration Guide is not applicable to a 4.1 system. Disregard the information.