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 Through PIMG Units
The Force Failover Setting Must Be Checked
Preparing for Manual or Scheduled Failback (Integrations Through PIMG Units Only)
How Failover Works When Cisco Unity Is Integrated Through 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 and Changes
Changes That Affect All Cisco Unity Guides
Cross-References to System Requirements Document
Exchange 5.5 No Longer Supported
Windows NT Domain No Longer Supported
Notifying Subscribers to Update the Server Name in the Media Master
Outage Scenarios for Networks of Windows 2000 and IBM Lotus Domino (Cisco Unity with Domino Only)
The Domino Server Is Disconnected from the Network, Then Reconnected
The Domino Server Is Disconnected from the Network, Then the Primary and Secondary Servers Are Restarted
The Domino Server Is Disconnected from the Network, Then the Primary Server Is Disconnected from the Network
The Domino Server and the Primary Server Simultaneously Crash, Then Are Reconnected
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 information was omitted or is incorrect—is described in the "Errors and Changes" section at the end of this chapter.
The Domino version of the guide is available at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/403/failover/guide/dom/dom.html; the Exchange version of the guide is available at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/403/failover/guide/ex/ex.html.
This chapter contains the following sections:
•
Effects on Cisco Unity Web Applications When Failover or Failback Occurs
•Using Cisco Unity Failover with Integrations Through PIMG Units
•Errors and Changes
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 occurs 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 in the Cisco Unity Administrator and with Cisco Unity ViewMail for Microsoft Outlook does not change. When failover or failback occurs, the name displayed is the one that was entered when the subscriber 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 value for the Unity Inbox and Assistant—Automatically Set Up TRAP in Media Master setting.) Otherwise, the server name displayed in the Media Master 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 Through PIMG Units
For Cisco Unity 4.1(x) and later, integrations through 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 through PIMG units.
•The Force Failover Setting Must Be Checked
•Preparing for Manual or Scheduled Failback (Integrations Through PIMG Units Only)
•How Failover Works When Cisco Unity Is Integrated Through 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 through 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 Through PIMG Units Only)
When Cisco Unity is integrated with a circuit-switched phone system through 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 Through PIMG Units
Figure 2-1 shows a failover configuration for a circuit-switched phone system in an integration through PIMG units.
Figure 2-1 Failover Configuration for a Circuit-Switched Phone System Integrated Through 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 Through 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 through 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 through 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 through 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 through 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 through 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 through 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 through 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 and Changes
The following sections apply to the Cisco Unity Failover Configuration and Administration Guide (With IBM Lotus Domino), Release 4.0(5) and Later and to the Cisco Unity Failover Configuration and Administration Guide (With Microsoft Exchange), Release 4.x unless otherwise noted:
•Changes That Affect All Cisco Unity Guides
•Notifying Subscribers to Update the Server Name in the Media Master
•Outage Scenarios for Networks of Windows 2000 and IBM Lotus Domino (Cisco Unity with Domino Only)
Changes That Affect All Cisco Unity Guides
Cross-References to System Requirements Document
In cross-references to Cisco Unity 4.x System Requirements, and Supported Hardware and Software, refer instead to the following documents:
•Cisco Unity 4.2 System Requirements at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/42/requirements/42cusysreq.html.
•Supported Hardware and Software, and Support Policies for Cisco Unity 4.2 and Later at http://www.cisco.com/en/US/docs/voice_ip_comm/unity/42/support/42lsupp.html.
Exchange 5.5 No Longer Supported
Exchange 5.5 is no longer supported as the message store for Cisco Unity messages, for either new installations or upgrades. In Cisco Unity guides and Help, ignore any references to Exchange 5.5 as being supported. (Some Cisco Unity applications may contain Exchange 5.5 references as well.)
With Cisco Unity 4.2, installations and upgrades will fail when Exchange 5.5 is the message store. Before you can upgrade to version 4.2, you must upgrade to Exchange 2003 or Exchange 2000.
Windows NT Domain No Longer Supported
Making a Cisco Unity server a member server in a Windows NT domain is no longer supported. In Cisco Unity guides and Help, ignore any references to a Windows NT domain as being supported. (Some Cisco Unity applications may contain Windows NT domain references as well.)
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 is no longer applicable. Disregard the information. (Links to the Domino version of the chapter and to the Exchange version of the chapter.)
Outage Scenarios for Networks of Windows 2000 and IBM Lotus Domino (Cisco Unity with Domino Only)
The "Outage Scenarios for Networks of Windows 2000 and IBM Lotus Domino" in the "Behavior of Cisco Unity Failover During Outages of Network Components" appendix omitted the following scenarios:
•The Domino Server Is Disconnected from the Network, Then Reconnected
•The Domino Server Is Disconnected from the Network, Then the Primary and Secondary Servers Are Restarted
•The Domino Server Is Disconnected from the Network, Then the Primary Server Is Disconnected from the Network
•The Domino Server and the Primary Server Simultaneously Crash, Then Are Reconnected
The Domino Server Is Disconnected from the Network, Then Reconnected
In testing, this scenario was simulated by disabling the network interface card on the Domino server.
Disconnection Behavior
•All subscribers hear the Unity Messaging Repository (UMR) conversation when they log on to Cisco Unity.
•External callers can leave messages for subscribers. The new messages are stored in the UnityMTA folder on the primary server.
•Subscribers homed on the same Cisco Unity server can leave messages for each other by dialing an extension or logging on to Cisco Unity. The new messages are stored in the UnityMTA folder on the primary server.
•Subscribers can call the Cisco Unity server and listen to their new messages stored in the UnityMTA folder on the primary server. Messages stored on the Domino server before the network outage are not available.
•The primary server handles directory synchronization.
•MWIs, event notification, and message notification are not handled.
Reconnection Behavior
•Subscribers who log on to Cisco Unity no longer hear the UMR conversation, but hear the appropriate conversation.
•Messages stored in the UnityMTA folder on the primary server are delivered to the appropriate subscriber Inboxes.
•The primary server sets MWIs for subscribers who have unheard messages stored on the Domino server.
•External callers and subscribers can leave messages for subscribers. The messages are stored on the Domino server.
•The primary server handles directory synchronization, MWIs, event notification, and message notification.
The Domino Server Is Disconnected from the Network, Then the Primary and Secondary Servers Are Restarted
In testing, this scenario was simulated by disabling the network interface card on the Domino server, then stopping and restarting the primary and secondary servers.
Restarting Behavior for the Primary and Secondary Servers
•The Cisco Unity service (AvCsMgr.exe) on both servers does not start.
•There is no voice messaging functionality. Neither the primary nor secondary server answers calls.
•Subscribers are not able to leave or listen to messages. External callers cannot leave messages for subscribers.
The Domino Server Is Disconnected from the Network, Then the Primary Server Is Disconnected from the Network
In testing, this scenario was simulated by disabling the network interface card on the Domino server, then on the primary server.
Disconnection Behavior (Only the Domino Server Is Disconnected)
•The primary server continues to be active, and the secondary server continues to be inactive.
•The primary server continues answering all calls.
•All subscribers hear the Unity Messaging Repository (UMR) conversation when they log on to Cisco Unity.
•External callers can leave messages for subscribers. The new messages are stored in the UnityMTA folder on the primary server.
•Subscribers homed on the same Cisco Unity server can leave messages for each other by dialing an extension or logging on to Cisco Unity. The new messages are stored in the UnityMTA folder on the primary server.
•Subscribers can call the Cisco Unity server and listen to their new messages stored in the UnityMTA folder on the primary server. Messages stored on the Domino server before the network outage are not available.
•The primary server handles directory synchronization and file replication.
•MWIs, event notification, and message notification are not handled.
Disconnection Behavior (the Primary Server Is Also Disconnected)
•The secondary server answers all calls.
•The Failover Monitor on the primary server shows that the primary server is active. The Failover Monitor on the secondary server shows that the secondary server is active.
•All subscribers hear the UMR conversation when they log on to Cisco Unity.
•External callers can leave messages for subscribers. The new messages are stored in the UnityMTA folder on the secondary server.
•Subscribers homed on the same Cisco Unity server can leave messages for each other by dialing an extension or logging on to Cisco Unity. The new messages are stored in the UnityMTA folder on the secondary server.
•Subscribers can call the Cisco Unity server and listen to their new messages stored in the UnityMTA folder on the secondary server. Messages stored on the Domino server before the network outage are not available.
•MWIs, event notification, and message notification are not handled.
Reconnection Behavior When the Primary Server Is Reconnected and the Domino Server Remains Disconnected
•The primary server becomes active, and the secondary server becomes inactive.
•All voice messaging ports on the primary server register with the Cisco CallManager server.
•The primary server answers all calls.
•The Node Manager services (AvCsNodeMgr) on the primary and secondary servers send status to and receive status from each other.
•The Failover Monitors on the primary and secondary servers show that the primary server is active.
•Changes to the UnityDb database that occurred while the primary server was offline are replicated from the secondary server to the primary server.
•The primary server handles directory synchronization, MWIs, event notification, and message notification.
•Messages, greetings, and other recordings made on the primary server but not replicated to the secondary server before the network outage are replicated to the secondary server.
•Messages, greetings, and other recordings made on the secondary server during the network outage are replicated to the primary server.
Reconnection Behavior After the Primary Server Is Reconnected, Then the Domino Server Is Reconnected
•Subscribers who log on to Cisco Unity no longer hear the UMR conversation, but hear the appropriate conversation.
•Messages stored in the UnityMTA folder on the primary server are delivered to the appropriate subscriber Inboxes.
•The primary server sets MWIs for subscribers who have unheard messages stored on the Domino server.
•External callers and subscribers can leave messages for subscribers. The messages are stored on the Domino server.
•The primary server handles directory synchronization, MWIs, event notification, and message notification.
Reconnection Behavior When the Domino Server Is Reconnected and the Primary Server Remains Disconnected
•Subscribers who log on to Cisco Unity no longer hear the UMR conversation, but hear the appropriate conversation.
•Messages stored in the UnityMTA folder on the secondary server are delivered to the appropriate subscriber Inboxes.
•The secondary server sets MWIs for subscribers who have unheard messages stored on the Domino server.
•External callers and subscribers can leave messages for subscribers. The messages are stored on the Domino server.
•The secondary server handles directory synchronization, MWIs, event notification, and message notification.
Reconnection Behavior After the Domino Server Is Reconnected, Then the Primary Server Is Reconnected
•The primary server becomes active, and the secondary server becomes inactive.
•All voice messaging ports on the primary server register with the Cisco CallManager server.
•The primary server answers all calls.
•Subscribers are able to leave and listen to messages. External callers can leave messages for subscribers
•The Node Manager services (AvCsNodeMgr) on the primary and secondary servers send status to and receive status from each other.
•The Failover Monitors on the primary and secondary servers show that the primary server is active.
•Changes to the UnityDb database that occurred while the primary server was offline are replicated from the secondary server to the primary server.
•The primary server handles directory synchronization, MWIs, event notification, and message notification.
•Messages, greetings, and other recordings made on the primary server but not replicated to the secondary server before the network outage are replicated to the secondary server.
•Messages, greetings, and other recordings made on the secondary server during the network outage are replicated to the primary server.
The Domino Server and the Primary Server Simultaneously Crash, Then Are Reconnected
In testing, this scenario was simulated by turning off power to the Domino server and to the primary server at the same time.
Disconnection Behavior
•The secondary server answers all calls.
•All subscribers hear the Unity Messaging Repository (UMR) conversation when they log on to Cisco Unity.
•External callers can leave messages for subscribers. The new messages are stored in the UnityMTA folder on the secondary server.
•Subscribers homed on a different Cisco Unity server can leave messages for subscribers on another Cisco Unity server by calling the Cisco Unity server. The new messages are stored in the UnityMTA folder on the secondary server.
•Subscribers can call the Cisco Unity server and listen to their new messages stored in the UnityMTA folder on the secondary server. Messages stored on the Domino server before the network outage are not available.
•MWIs, event notification, and message notification are not handled.
Reconnection Behavior When the Domino Server Is Reconnected and the Primary Server Remains Disconnected
•Subscribers who log on to Cisco Unity no longer hear the UMR conversation, but hear the appropriate conversation.
•Messages stored in the UnityMTA folder on the secondary server are delivered to the appropriate subscriber Inboxes.
•The secondary server sets MWIs for subscribers who have unheard messages stored on the Domino server.
•External callers and subscribers can leave messages for subscribers. The messages are stored on the Domino server.
•The secondary server handles directory synchronization, MWIs, event notification, and message notification.
Reconnection Behavior After the Domino Server Is Reconnected, Then the Primary Server Is Reconnected
•The primary server is inactive, and the secondary server remains active.
•When failback is manually initiated or when a scheduled failback occurs, the primary server becomes active and the secondary server becomes inactive.
•When the primary server becomes active, all voice messaging ports on the primary server register with the Cisco CallManager server.
•When the primary server becomes active, it answers all calls. Until then, the secondary server answers all calls.
•Subscribers are able to leave and listen to messages. External callers can leave messages for subscribers.
•The Node Manager services (AvCsNodeMgr) on the primary and secondary servers send status to and receive status from each other.
•When the primary server becomes active, the Failover Monitors on the primary and secondary servers show that the primary server is active.
•Changes to the UnityDb database that occurred while the primary server was offline are replicated from the secondary server to the primary server.
•When the primary server becomes active, it handles directory synchronization, MWIs, event notification, and message notification.
•Messages, greetings, and other recordings made on the primary server but not replicated to the secondary server before the network outage are replicated to the secondary server.
•Messages, greetings, and other recordings made on the secondary server during the network outage are replicated to the primary server.
Reconnection Behavior When the Primary Server Is Reconnected and the Domino Server Remains Disconnected
•The Cisco Unity service (AvCsMgr.exe) on the primary server does not start.
•The secondary server continues to be active.
•The secondary server continues answering all calls.
Reconnection Behavior After the Primary Server Is Reconnected, Then the Domino Server Is Reconnected and the Cisco Unity Service (AvCsMgr.exe) on the Primary Server Is Manually Started
•The primary server is inactive, and the secondary server remains active.
•When failback is manually initiated or when a scheduled failback occurs, the primary server becomes active and the secondary server becomes inactive.
•When the primary server becomes active, all voice messaging ports on the primary server register with the Cisco CallManager server.
•When the primary server becomes active, it answers all calls. Until then, the secondary server answers all calls.
•Subscribers are able to leave and listen to messages. External callers can leave messages for subscribers. The messages are stored on the Domino server.
•Subscribers who log on to Cisco Unity no longer hear the UMR conversation, but hear the appropriate conversation.
•Messages stored in the UnityMTA folder on the secondary server are delivered to the appropriate subscriber Inboxes.
•The primary server sets MWIs for subscribers who have unheard messages stored on the Domino server.
•The Node Manager services (AvCsNodeMgr) on the primary and secondary servers send status to and receive status from each other.
•The Failover Monitors on the primary and secondary servers show that the primary server is active.
•Changes to the UnityDb database that occurred while the primary server was offline are replicated from the secondary server to the primary server.
•The primary server handles directory synchronization, MWIs, event notification, and message notification.
•Messages, greetings, and other recordings made on the primary server but not replicated to the secondary server before the network outage are replicated to the secondary server.
•Messages, greetings, and other recordings made on the secondary server while the primary server was inactive are replicated to the primary server.
Feedback
