Table Of Contents
About Cisco Unity Failover
Terms Used
How Failover Works in Cisco Unity
Requirements for Cisco Unity Failover
The Effects of Failover and Failback on Calls in Progress
Status Monitoring and File Replication
Data That Is Not Replicated
Events When Failover Occurs
Events When Failback Occurs
Automatic and Manual Failback
Interval for Failover
Accessing the Cisco Unity Administrator, Status Monitor, ActiveAssistant, and Cisco Unity Visual Messaging Interface
Using the Phone To Record and Play Messages and Greetings in the Cisco Unity Administrator, ActiveAssistant, Cisco Unity Visual Messaging Interface, and ViewMail
Effects of Shutting Down and Restarting the Primary and Secondary Servers
Replacing One of the Servers with a New Server
Failover Requirement and Limitations with AMIS and the Cisco Unity Bridge
Requirement for Using the Configuration Manager
Limitations
The Order in Which to Start the Servers
Licensing Restrictions on Using a Secondary Server Without a Primary Server
About Cisco Unity Failover
This chapter contains the following sections:
•
Terms Used
•How Failover Works in Cisco Unity
•Requirements for Cisco Unity Failover
•The Effects of Failover and Failback on Calls in Progress
•Status Monitoring and File Replication
•Events When Failover Occurs
•Events When Failback Occurs
•Automatic and Manual Failback
•Interval for Failover
•Accessing the Cisco Unity Administrator, Status Monitor, ActiveAssistant, and Cisco Unity Visual Messaging Interface
•Using the Phone To Record and Play Messages and Greetings in the Cisco Unity Administrator, ActiveAssistant, Cisco Unity Visual Messaging Interface, and ViewMail
•Effects of Shutting Down and Restarting the Primary and Secondary Servers
•Replacing One of the Servers with a New Server
•Failover Requirement and Limitations with AMIS and the Cisco Unity Bridge
•The Order in Which to Start the Servers
•Licensing Restrictions on Using a Secondary Server Without a Primary Server
Terms Used
The following terms are used in the Cisco Unity Failover Guide:
active
|
The state when the Cisco Unity server is handling all voice messaging.
|
analog
connectivity
|
The analog cable connections that carry the voice communications between the Cisco Unity system and a circuit-switched phone system.
|
Cisco Unity
service
|
The executive component of the Cisco Unity system that is represented by the executable AvCsMgr.exe. The primary and secondary servers have their own Cisco Unity services.
|
failback
|
The action of transferring the voice messaging processes from the secondary server to the primary server so that Cisco Unity on the primary server handles all voice messaging.
|
failover
|
The action of transferring the voice messaging processes from the primary server to the secondary server so that Cisco Unity on the secondary server handles all voice messaging.
|
inactive
|
The state when the Cisco Unity server is not handling voice messaging.
|
Node Manager
service
|
The executive component of failover that is represented by the executable AvCsNodeMgr.exe. The primary and secondary servers have their own Node Manager services.
|
primary server
|
The Cisco Unity server that is active in normal operation (when failover has not occurred). The primary server is specified as the primary server on the system key and during the Failover Configuration wizard.
|
secondary server
|
The Cisco Unity that is active after failover has occurred. The secondary server is specified as the secondary server on the system key and during the Failover Configuration wizard.
|
voice messaging
processes
|
The Cisco Unity functions, including answering calls, sending message notification, and turning on and off message waiting indicators (MWIs).
|
How Failover Works in Cisco Unity
Failover is a feature that provides a simple redundancy, allowing voice messaging functions to continue if the Cisco Unity server fails or when you need to perform maintenance. To set up failover, you install and configure Cisco Unity on two servers, a primary server and a secondary server.
Note The failover feature cannot be used for continuing Cisco Unity service (voice messaging) on one server while upgrading the Cisco Unity software on the other server. Both primary and secondary servers must be out of service while the Cisco Unity software is upgraded. The secondary server cannot handle voice messaging while the primary server is being upgraded.
Figure 3-1 shows a failover configuration for an IP (Internet Protocol) phone system. Figure 3-2 shows a failover configuration for a traditional, circuit-switched phone system in a DTMF integration. Figure 3-3 shows one possible failover configuration for a circuit-switched phone system in a serial integration that uses a data splitter on the RS-232 serial cable to provide a data link to both Cisco Unity servers. For information on making the line connections, see Appendix D, "Line Connections Between the Phone System and the Cisco Unity Servers."
Figure 3-1 Failover Configuration for an IP Phone System
Figure 3-2 Failover Configuration for a Circuit-Switched Phone System in a DTMF Integration
Figure 3-3 One Possible Failover Configuration for a Circuit-Switched Phone System in a Serial Integration
Under normal circumstances, the primary server is active—Cisco Unity on this server answers phone calls and takes messages, sends message notifications, and turns message waiting indicators (MWIs) on and off. The secondary server is inactive—Cisco Unity is running, but it does not perform any voice messaging functions.
Table 1 shows behavior of the two servers when the primary server is active.
Table 1 Cisco Unity Behavior When the Primary Server Is Active
Cisco Unity Behavior
|
Primary Server
|
Secondary Server
|
Running
|
Yes
|
Yes1
|
Active (handles voice messaging
processes)
|
Yes
|
No
|
Answers phone calls
|
Yes
|
No
|
Sends message notifications
|
Yes
|
No
|
Turns on and off MWIs
|
Yes
|
No
|
If the primary server fails or if the Cisco Unity service on the primary server stops, the secondary Cisco Unity server automatically becomes active and starts performing standard Cisco Unity operations. This shift from primary to secondary Cisco Unity servers is called failover. If you want to stop the primary Cisco Unity server for maintenance, you can also initiate failover manually.
Table 3-2 shows behavior of the two servers when the secondary server is active.
Table 3-2 Cisco Unity Behavior When the Secondary Server Is Active
Cisco Unity Behavior
|
Primary Server
|
Secondary Server
|
Running
|
Depends1
|
Yes
|
Active (handles voice messaging
processes)
|
No
|
Yes
|
Answers phone calls
|
No
|
Yes
|
Sends message notifications
|
No
|
Yes
|
Turns on and off MWIs
|
No
|
Yes
|
When the secondary server is active, Cisco Unity functions normally, with the following exceptions:
•For a few seconds after a failure occurs and before the secondary server becomes active, subscribers hear a fast-busy tone when they dial the internal phone number to access Cisco Unity.
•Reports can be generated only while the primary server is active.
•The Cisco Unity Administrator and the ActiveAssistant are available on the secondary server, but the URLs for the primary server will not connect to the secondary server because the server names are unique. Web browsers must be manually redirected to the Cisco Unity Administrator and the ActiveAssistant on the secondary server.
•Listening to and recording messages by phone is available, but ActiveAssistant, the Cisco Unity Visual Messaging Interface, and ViewMail for Microsoft Outlook must be manually redirected to the secondary server.
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.
Requirements for Cisco Unity Failover
•The two servers must be qualified for Cisco Unity. Refer to Part 1 of Cisco Unity System Requirements, and Supported Hardware and Software, available on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/sysreq/index.htm.
•For Exchange 2000, both Cisco Unity servers must be in the same routing group. For Exchange 5.5, both servers must be in the same Exchange site.
•The only Exchange software installed on the Cisco Unity servers is the administration software. All other Exchange services (including subscriber mailboxes) are on a computer other than the Cisco Unity servers. Messages must not be stored on the Cisco Unity servers. (This separation allows the availability of messages when either the primary or secondary server is not functioning.)
•SQL Server 2000 must be installed on both Cisco Unity servers.
•One Cisco Unity server is designated the primary server, and the other Cisco Unity server is designated the secondary server.
•For Cisco Unity 3.1(2) and 3.1(3) only, the system clocks on both servers must not vary by more time than the value of the File Replication Interval field in the Failover Monitor. (If the system clocks vary by more than the setting, recently recorded names, greetings, and messages may not be replicated correctly.) For servers with Windows 2000, we recommend that you set up the Time server in Windows to synchronize the system clocks by using the net time command. Refer to Article ID Q216734, "How to Configure an Authoritative Time Server in Windows 2000," on the Microsoft website at http://support.microsoft.com.
•Both Cisco Unity servers must have the same enabled features and configurations.
•For equal performance, both Cisco Unity servers should have the same number of ports.
•Both system keys must be identical except that one key must have a license for a primary server and the other key must have a license for a secondary server. You cannot run Cisco Unity as a primary server while using a license for a secondary server, nor run Cisco Unity as a secondary server while using a license for a primary server.
•Both Cisco Unity servers must be connected to the network and have a reliable connection of 100 Mbps minimum. There is no option for installing failover without a network connection.
•Failover can be used with any supported Cisco Unity configuration except with one that has no network connection.
•Both Cisco Unity servers must have static or reserved IP addresses (for example, DHCP reservation). The IP addresses must not change in uncontrolled fashion. If DHCP is configured with a long lease duration, you can let DHCP assign the IP address. If DHCP is configured with a short lease duration, assign a static IP address, or use DHCP reservations.
•MSSQLSERVER and SQLSERVERAGENT services on both Cisco Unity servers must be configured to use the same domain account. They cannot be configured to run as Local System. SQLSERVERAGENT on the primary server must be able to log on to SQL Server on the secondary server by using Windows NT authentication.
The Effects of Failover and Failback on Calls in Progress
When failover or failback is initiated, calls in progress are maintained or dropped, depending on the status of the Cisco Unity service (AvCsMgr.exe) and of the network.
Table 3-3 Failover and Failback Effects on Calls in Progress
Cisco Unity Service
or Network Status
|
Action
|
The Cisco Unity
service is stopped
or crashes
|
Calls in progress are dropped. When the Cisco Unity service (AvCsMgr.exe) on the primary server becomes inactive, the secondary server becomes active, but the dropped calls cannot be recovered.
|
The Cisco Unity
service is active when
failover occurs
|
Calls in progress are maintained until the callers hang up.
|
Network connections
are lost
|
Calls in progress from traditional, circuit-switched phone systems are maintained until the callers hang up.
Calls in progress from IP phone systems (for example, Cisco CallManager) may be dropped, depending on the nature of the network problem.
|
Status Monitoring and File Replication
When failover is configured and Cisco Unity is functioning normally, monitoring and replication take place as shown in Figure 3-4.
Figure 3-4 Monitoring and Replication Actions
Details of the monitoring and replication actions are described below.
Node Manager Service (AvCsNodeMgr.exe)
•The Node Manager service in the active server sends its status to the inactive server (it "pings" the inactive server) at a frequency the installer configures. The default is 1 second. The TCP packet is 785 bytes in size and uses port 3653, which the installer can change.
•The Node Manager service in the inactive server sends its status to the active server (it "pings" the active server) at a frequency the installer configures. The default is 1 second. The TCP packet is 785 bytes in size and uses port 3653, which the installer can change.
•The Node Manager service monitors the Cisco Unity service (AvCsMgr.exe) on the server.
Cisco Unity Files
•The frequency of replication between the active and inactive servers depends on the value of the File Replication Interval field in the Failover Monitor and how often the Cisco Unity files change.
•In Cisco Unity version 3.1(2), the Node Manager service monitors and replicates the files in the directories IntLib, Localize\DefaultConfiguration, Localize\Prompts, StreamFiles, Support, and UnityMTA (for Unity Messaging Repository, or UMR, voice messages) on the Cisco Unity server.
In version 3.1(3) and later, the Node Manager service monitors and replicates the files in the directories Localize\DefaultConfiguration, Localize\Prompts, StreamFiles, Support, and UnityMTA.
•Changes to the system rules, schedules, and holidays are replicated.
•In Cisco Unity version 3.1(2), changed files in the IntLib directory are replicated to the inactive server.
In version 3.1(3) and later, the Cisco Unity files in the IntLib directory are replicated only if the Copy Switch Files from Primary Server to Secondary Server check box is checked in the failover configuration wizard, and then only when the failover configuration wizard runs.
•If changed files have not been replicated to the secondary server when a catastrophic failover occurs, the changes may be lost. Under such circumstances, the new information is not on the secondary server and may be lost or corrupted on the primary server.
•Replication of changed files is disabled when the Node Manager service is set to manual mode.
SQL Server Database (UnityDb)
•The frequency of replication depends on how often the SQL data changes.
•The database on the primary server is configured as the publisher and distributor.
•The database publication is UnityDbPublication.
•The database on the secondary server is configured as the subscriber.
•Two-way replication between the two servers is enabled to let the primary server receive all changes made during periods it is online and inactive.
•If changed data has not been replicated to the secondary server when a catastrophic failover occurs, the new data may be lost. Under such circumstances, the new data is not on the secondary server and may be lost or corrupted on the primary server.
Voice Messages
•Voice messages are not replicated because failover requires that the Exchange server be on a separate computer from the Cisco Unity server. When voice messages are kept on a separate server, voice messages are available to the subscriber no matter which Cisco Unity server is active.
•Voice messages saved in the Unity Messaging Repository (UMR) when the Exchange server is offline are replicated to the inactive server with other Cisco Unity files. (The UMR is located in the UnityMTA directory.)
Data That Is Not Replicated
Changes to the following settings in the Cisco Unity Administrator are not replicated between the primary and secondary servers. You must manually change values on both servers.
•Registry settings
•Configuration settings
•Recording settings
•Phone language settings
•GUI language settings
•Port settings
•Phone system settings
•IP phone system settings
Caution With Cisco Unity failover, the switch file for the selected phone system is replicated from the primary server to the secondary server only when you run the failover configuration wizard and only if you check the Copy Switch Files from Primary Server to Secondary Server check box when you run the wizard. If you select a different phone system after you run the failover configuration wizard, the new switch file will not be replicated to the secondary server. In addition, changes to phone system settings will not be replicated between the primary and secondary servers. If you change phone system settings after you run the failover configuration wizard, you must manually change values on both servers.
Events When Failover Occurs
1. Status monitoring and file replication occur when the primary server is active:
a. The Node Manager service (AvCsNodeMgr.exe) monitors the Cisco Unity service (AvCsMgr.exe) and other services on the server to determine whether failover should be initiated.
b. The Node Manager services on both the primary and secondary servers send status to each other on a regular basis.
c. Certain Cisco Unity files when changed are replicated from the primary server to the secondary server.
d. Data from the SQL Database (UnityDb) when changed is replicated from the primary server to the secondary server.
e. The primary server answers calls, sends message notification, and turns MWIs on and off. The secondary server is inactive and performs none of these functions.
f. Voice messages are stored on the Exchange server, which is on a separate computer from the primary and secondary servers.
2. Failover occurs when any of the following events take place:
•The Node Manager service (AvCsNodeMgr.exe) on the secondary server does not receive a status update from the primary server within the period specified when configured (for example, when the primary server crashes, the Node Manager service is stopped, or there are network connectivity problems).
•The Cisco Unity service (AvCsMgr.exe) on the primary server is stopped. The Node Manager service on the primary server reports the stoppage to the Node Manager service on the secondary server.
•A port on the secondary server receives a call, which indicates that a port on the primary server is not responding.
3. The Node Manager service (AvCsNodeMgr.exe) on the secondary server assumes that the Cisco Unity service is stopped on the primary server and activates the Cisco Unity service on its server. (In the case of the secondary server receiving a call, the Node Manager service on the secondary server instructs the Node Manger service on the primary server to initiate failover.) The secondary server starts answering calls, sending message notification, and turning MWIs on and off.
4. The Node Manager service (AvCsNodeMgr.exe) on the secondary server writes a warning to the Event log.
Events When Failback Occurs
1. Status monitoring and file replication occur when the secondary server is active and the primary server is running (but inactive):
a. The Node Manager service (AvCsNodeMgr.exe) monitors the Cisco Unity service (AvCsMgr.exe) and other services on the server to determine whether failback should be initiated.
b. The Node Manager services on both the secondary and primary servers send status to each other on a regular basis.
c. Certain Cisco Unity files when changed are replicated from the secondary server to the primary server.
d. Data from the SQL Database (UnityDb) when changed is replicated from the secondary server to the primary server.
e. The secondary server answers calls, sends message notification, and turns MWIs on and off. The primary server is inactive and performs none of these functions.
f. Voice messages are stored on the Exchange server, which is on a separate computer from the secondary and primary servers.
2. Failback occurs when either of the following events takes place:
•If automatic failback is enabled, the time specified for failback arrives, and the Node Manager service (AvCsNodeMgr.exe) on the secondary server notifies the Node Manger service on the primary server that the Cisco Unity service (AvCsMgr.exe) on secondary server is inactive.
•Manual failback is initiated by using the Failover Monitor.
3. The Node Manager service (AvCsNodeMgr.exe) on the primary server assumes that the Cisco Unity service is stopped on the secondary server and activates the Cisco Unity service on its server. (In the case of the primary server receiving a call, the Node Manager service on the primary server instructs the Node Manger service on the secondary server to initiate failback.) The primary server the starts answering calls, sending message notification, and turning MWIs on and off.
4. The Node Manager service on the primary server writes a warning to the Event log.
Automatic and Manual Failback
Failback can occur automatically at a time you specify, or it can occur manually. The Failback Type setting is in the Failover Monitor:
Scheduled
|
Use this option if you want the secondary server to fail back automatically. In the Failover Monitor, enter values for the Scheduled Failback Start and Scheduled Failback End fields to set the time for automatic failback. This type is useful when you want failback to occur, for example, at night. You can initiate failback manually before the scheduled time by using the Failover Monitor.
|
Manual
|
Use this option if you do not want the secondary server to automatically fail back to the primary server when the primary server becomes available. The secondary server fails back to the primary server only when you manually fail back by using the Failover Monitor.
|
For details on customizing the failback type in the Failover Monitor, see the "Customizing Failover and Failback for the Cisco Unity System" section on page 2-2.
Interval for Failover
Typically, the time it takes for failover to occur depends on what causes failover.
Table 3-4 Interval for Failover
Failover Cause
|
Time
|
Manual failover or crash
of Cisco Unity service
(AvCsMgr.exe)
|
•If replication is not needed and is not in progress, failover occurs in about 15 seconds.
•If replication is needed or is in progress, failover occurs after replication is complete.
•Calls in progress are not dropped but are maintained until callers hang up.
|
Network problems
|
•Failover occurs after waiting for the number of pings set in the Missed Pings Before Failover field in the Failover Monitor. The time required depends on the value of the field and on the value of the Ping Interval (ms) field. The default settings for the fields result in a 30-second delay for the secondary server to become active.
•Network problems may result in both primary and secondary servers being active at the same time. When the network problems are resolved, the primary server remains active and the secondary server becomes inactive.
•Calls in progress from a traditional, circuit-switched phone system are not dropped but are maintained until the callers hang up. Calls in progress from an IP phone system (for example, Cisco CallManager) may be dropped, depending on the nature of the network problem.
|
Failure of the computer
or operating system
|
•Failover occurs in about 15 seconds.
•Calls in progress are dropped.
|
Inactive secondary server
answers a call
|
•Failover occurs without delay. The secondary server answers the call and processes it normally.
•Calls in progress are not dropped but are maintained until the callers hang up.
|
Accessing the Cisco Unity Administrator, Status Monitor, ActiveAssistant, and Cisco Unity Visual Messaging Interface
You can access the Cisco Unity Administrator and Status Monitor to enter or change data on the active server, whether it is the primary or the secondary server, by specifying the applicable URL of the active server. Make sure that subscribers have the URL for both servers, so that during failover they can use the ActiveAssistant and the Cisco Unity Visual Messaging Interface (VMI) by specifying the applicable URL.
Note that if you or another subscriber accesses the Cisco Unity Administrator or the ActiveAssistant on the inactive server, you will not be allowed to save changes.
Using the Phone To Record and Play Messages and Greetings in the Cisco Unity Administrator, ActiveAssistant, Cisco Unity Visual Messaging Interface, and ViewMail
When the secondary server is the active server, Cisco Unity subscribers can still use the phone to play and record messages and greetings in the ActiveAssistant, in ViewMail for Outlook, and in the Cisco Unity Visual Messaging Interface (VMI). In addition, you (and other subscribers with the appropriate class of service privileges) can use the phone to play and record greetings in the Cisco Unity Administrator. In order to do so, the name of the server that the Cisco Unity applications access during playback and recording needs to be changed. In addition, when the primary server becomes the active server, the server name must be changed back.
Cisco Unity subscribers change the server name settings in the Media Master control bar Options menu, available from various pages in the Cisco Unity Administrator, ActiveAssistant, and Cisco Unity VMI, and from a new or old message form in ViewMail. The Media Master control bar settings are saved per user, per computer. This means that:
•A subscriber who is logged on to the Cisco Unity Administrator, ActiveAssistant, ViewMail, or Cisco Unity VMI can update the server name from any Media Master control bar Options menu. When the server name is updated in any one of the applications, the update applies to all of the applications, as long as the subscriber accesses the applications from the same computer on which the change was initially made.
•If multiple subscribers share the same computer, the server name needs to be updated for each subscriber who uses the computer.
•If a subscriber has updated the server name from one computer, but also uses the Cisco Unity Administrator, ActiveAssistant, ViewMail, or Cisco Unity VMI to play and record messages or greetings by phone on a different computer (for example, a computer at home), the server name needs to be updated for the second computer as well.
To change the server name for all the Cisco Unity applications that you use to play and record greetings over the phone, do the following procedure. In addition, for the subscribers in your organization, provide the names of both servers, and refer them to instructions in the "To Change Recording and Playback Devices" section of the "Changing Recording and Playback Settings" chapter of the Cisco Unity User Guide, or to the "Options for Playing and Recording Messages" topic in the Cisco Unity VMI online Help. These end-user resources will walk subscribers through the process of updating the server name.
To change the name of the server for recording and playback over the phone
Step 1 Log on to one of the following: Cisco Unity Administrator, ActiveAssistant, ViewMail, or Cisco Unity VMI.
Step 2 Go to a Master Media control bar.
Step 3 On the Media Master control bar Options menu, click Playback Device, and confirm that Phone is selected.
Step 4 Click Options on the Media Master control bar Options menu, and do the following steps:
a. In the dialog box, enter your extension and the name of the applicable server.
b. Click OK.
Step 5 On the Media Master control bar Options menu, click Recording Devices, and confirm that Phone is selected.
Step 6 Repeat Step 4.
Step 7 Repeat Steps 1 through 6 for each computer that you use to access the applications.
Effects of Shutting Down and Restarting the Primary and Secondary Servers
If you shut down or restart either the primary or secondary server, the servers behave in the following ways:
•When both servers are running and the active server is shut down, the inactive server becomes active.
•When neither server is running, the first server started becomes the active server.
•When the secondary server is active and configured for automatic failback, and the primary server is also running, the secondary server attempts failback on the failback schedule.
Replacing One of the Servers with a New Server
It is possible to replace one server that is used for failover with a new server, provided the new server meets the failover requirements. To replace the server, you must completely uninstall the failover components from both servers. Then you must install the new Cisco Unity server, and configure failover on both servers.
Failover Requirement and Limitations with AMIS and the Cisco Unity Bridge
Requirement for Using the Configuration Manager
For AMIS or the Bridge, run the Configuration Manager on the primary server, not the secondary server.
Limitations
When the Cisco Unity server is configured for failover, note the following limitations for AMIS and the Bridge.
Data Is Not Automatically Replicated Between Servers
With primary and secondary servers set up for failover, AMIS restriction table settings are not replicated because they are stored in the registry. As a result, you must manually set the same AMIS restriction table settings on both servers.
The Bridge and Failover
When a Cisco Unity server is configured for failover, the Cisco Unity subscriber directory is not synchronized with the Bridge directory while the secondary server is active. When the primary server becomes active again, synchronization resumes automatically. Failover provides for replication of subscriber data between the primary and secondary servers, so existing directory information will be available to subscribers no matter which server is active.
When the secondary server is active, subscribers on Cisco Unity and the Octel system can still send and receive messages, but changes to Cisco Unity subscriber accounts are not replicated to the Bridge immediately. For example, if you add subscriber accounts on the active secondary server, this information is not replicated to the Bridge until the primary becomes active again.
The Order in Which to Start the Servers
Start the primary server first, then start the secondary server. If you start the secondary server first, it becomes the active server.
Licensing Restrictions on Using a Secondary Server Without a Primary Server
To prevent the secondary server from being used as the primary server in another location, the secondary server stops answering calls:
•Four hours after you restart the secondary Cisco Unity server, if you have never run the Configure Cisco Unity Failover wizard.
•Four hours after you restart the secondary Cisco Unity server, if you have run the Configure Cisco Unity Failover wizard but the secondary server has never been able to contact the primary server.
•60 days after the last time that the secondary server was able to contact the primary server, if the secondary has contacted the primary server at least once. In this case, the only way to make the secondary server start answering calls again is to reconnect the primary server to the network.
There are no licensing restrictions on a primary server, so a primary server will operate without a secondary server. However, without a secondary server, the failover feature cannot work, and an error appears in the Event log whenever you restart the Cisco Unity server. To stop the errors from appearing, disable the Node Manager service (AvCsNodeMgr.exe) in the Services MMC.
Feedback
