Troubleshooting Guide for Cisco Unity Release 5.x (With Microsoft Exchange)
Failover
Downloads: This chapterpdf (PDF - 211.0KB) The complete bookPDF (PDF - 5.24MB) | Feedback

Failover

Table Of Contents

Failover

The Failover Configuration Wizard Does Not Finish Successfully

The Installation of the Cisco Unity Software

The Permissions for Services That Are Used by Failover

The Network Connection Between the Primary and Secondary Servers

The Failover Requirements

Failover Configuration Wizard

Upgrading or Migrating Cisco Unity with Failover Does Not Finish Successfully

The Tempu or Migration Logs

The Failover Configuration Wizard

The Source of Any Backup Data

SQL Replication

Troubleshooting Failover and Failback Behavior

Event IDs

Integration Configuration

Macro or Micro Traces

MWI Synchronization

Troubleshooting File Replication

Confirm that the Files Should Be Replicated

Confirm that File Replication Is Enabled

Confirm the Permission Used By the Node Manager Service

Troubleshooting SQL Replication

Confirm that the Data Should Be Replicated

Perform a Failover Health Check

Perform a SQL Replication Health Check

Stop and Restore SQL Replication

Determine Whether the SQL Server Has Been Renamed


Failover


This chapter describes methods for troubleshooting Cisco Unity failover.

See the following sections:

The Failover Configuration Wizard Does Not Finish Successfully

Upgrading or Migrating Cisco Unity with Failover Does Not Finish Successfully

Troubleshooting Failover and Failback Behavior

Troubleshooting File Replication

Troubleshooting SQL Replication

The Failover Configuration Wizard Does Not Finish Successfully

To troubleshoot the Configure Cisco Unity Failover wizard (also called the failover configuration wizard), check the following components in the order given.

The Installation of the Cisco Unity Software

The Permissions for Services That Are Used by Failover

The Network Connection Between the Primary and Secondary Servers

The Failover Requirements

Failover Configuration Wizard

The Installation of the Cisco Unity Software

Determine whether any errors occurred during the installation or upgrade of the Cisco Unity software on both the primary and secondary servers by doing the following:

Ask the person who installed or upgraded the Cisco Unity software to recount any errors that occurred during the installation or upgrade process.

Examine the Event log. See the "Event Log" section on page 2-2.

Examine the applicable Tempu log, which provides a history of the installation or upgrade of the Cisco Unity software. The Tempu log is saved in the CommServer\Logs directory. The log has a file name in the format Tempu_<date>_<time>.log.

Test the basic functions of the Cisco Unity system. Refer to the "Testing Cisco Unity Failover" section in Chapter 1, "Configuring Cisco Unity Failover." of the Failover Configuration and Administration Guide for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_feature_guides_list.html.

Take the applicable steps to resolve the installation or upgrade errors.

The Permissions for Services That Are Used by Failover

Confirm that the accounts for the SQL services (MSSQLSERVER and SQLSERVERAGENT) meet the following requirements:

The same on the primary and secondary servers.

A domain account.

The right to log on as a service.

A member of the Local Administrators group.

Also confirm that the Node Manager service (AvCsNodeMgr) meets the following requirements:

The same on the primary and secondary servers.

A domain account.

The right to log on as a service.

Right to act as part of the operating system.

A member of the Local Administrators group.

Take the applicable steps to ensure that the services use the required permissions.

The Network Connection Between the Primary and Secondary Servers

Confirm that primary and secondary servers can connect through the network:

If a firewall separates the primary and secondary server, confirm that the applicable TCP/UDP ports are opened. Refer to Chapter 3, "IP Communications Required by Cisco Unity." of the Security Guide for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_maintenance_guides_list.html.

From the primary server, ping the secondary server from the command prompt by entering C:\Ping <IP address or name of secondary server>, and pressing Enter.

From the secondary server, ping the primary server from the command prompt by entering C:\Ping <IP address or name of primary server>, and pressing Enter.

Take the applicable steps to resolve any problems for the network connections between the primary and secondary servers.

The Failover Requirements

Confirm that the Cisco Unity system meets the requirements for failover. Refer to the "Requirements for Failover" section of the System Requirements for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html.

Take the applicable steps to ensure that the Cisco Unity system meets the requirements for failover.

Failover Configuration Wizard

Check the log for the Configure Cisco Unity Failover wizard (also called the failover configuration wizard). This log is in the CommServer\Logs directory and has the file name in the form of diag_FailoverConfig_<time and date>.txt.

Take the applicable steps to resolve any errors that appear in the log.

Upgrading or Migrating Cisco Unity with Failover Does Not Finish Successfully

To troubleshoot the upgrade or migration process, check the following components in the order given.

The Tempu or Migration Logs

The Failover Configuration Wizard

The Source of Any Backup Data

SQL Replication

The Tempu or Migration Logs

Determine whether any errors were logged during the upgrade or migration process on both the primary and secondary servers by examining the applicable log for errors:

For upgrades, search the applicable Tempu log, which provides a history of the upgrade process. The Tempu log is saved in the CommServer\Logs directory. The log has a file name in the format Tempu_<date>_<time>.log.

For migrations, search the applicable Migration log, which provides a history of the migration process. The Migration log is saved in the CommServer\Logs directory. The log has a file name in the format Migration_<date>_<time>.log.

Take the applicable steps to resolve the upgrade or migration errors.

The Failover Configuration Wizard

Troubleshoot the Configure Cisco Unity Failover wizard (also called the failover configuration wizard) by following the process described in the "The Failover Configuration Wizard Does Not Finish Successfully" section.

The Source of Any Backup Data

If backup data was used to restore either the primary or secondary server during the upgrade or migration process, confirm that data was backed up from the secondary server. When Cisco Unity is configured for failover, we do not recommend backing up data from the primary server. For details, see the online Help for the Cisco Unity Disaster Recovery tools (DiRT).

SQL Replication

If SQL replication is partially disabled (for example, an orphaned subscription is left on the secondary server), do the following procedures to stop and restore SQL replication.

To Stop SQL Replication


Step 1 On the primary server, on the Windows Start menu, click Programs > Microsoft SQL Server > Enterprise Manager. The SQL Server Enterprise Manager window appears.

Step 2 In the left pane of the Console Root window, browse to the Replication node for the primary server. Typically, the node is three levels under the Microsoft SQL Servers node.

Step 3 Right-click the Replication node, and click Disable Publishing. The Disable Publishing and Distribution wizard appears.

Step 4 On the Welcome page, click Next.

Step 5 On the Disable Publishing page, click Yes, then click Next.

Step 6 On the Confirm Dropping of Publications page, click Next.

Step 7 On the Completing page, click Finish.

Step 8 When the process is completed, click OK.

Step 9 Close the Console Root window.

Step 10 Exit Enterprise Manager.


To Restore SQL Replication on the Primary Server


Step 1 On the primary server, in Windows Explorer, browse to the CommServer directory.

Step 2 Double-click FailoverConfig.exe to start the Configure Cisco Unity Failover wizard.

Step 3 On the Welcome page, click Next.

Step 4 On the Specify Server Role page, click Primary Server, and click Next.

Step 5 On the Enter the Name of Your Server page, click Browse, select the name of the secondary server, and click OK. The IP address for the secondary server is filled in automatically.

Step 6 Click Next.

Step 7 On the Enter Failover Account Information page, click Browse, and double-click the name of the message store services account. This is the account that the failover service will log on as.

The account you select must have the right to act as part of the operating system and to log on as a service, and must be a member of the Local Administrators group.


Caution You must specify the same account on both the primary and secondary servers.

Step 8 In the Password field, enter the password for the account that the failover service will log on as, and click Next.

Step 9 On the Begin Configuring Your Server page, click Configure. The wizard verifies settings and configures failover on the primary server.

If the wizard does not finish the configuration successfully, an error message explains why the wizard failed. Exit the wizard, correct the problem, and click Configure again.

Step 10 On the Completing page, click Finish.


To Restore SQL Replication on the Secondary Server


Step 1 On the secondary server, on the Windows taskbar, double-click the system clock. The Date/Time Properties dialog box appears.

Step 2 Set the time to the same hour and minute as shown on the primary server, and click OK.

Step 3 In Windows Explorer, browse to the CommServer directory.

Step 4 Double-click FailoverConfig.exe to start the Configure Cisco Unity Failover wizard.

Step 5 On the Welcome page, click Next.

Step 6 On the Specify Server Role page, click Secondary Server, and click Next.

Step 7 On the Enter the Name of Your Server page, click Browse, select the name of the primary server, and click OK. The IP address for the primary server is filled in automatically.

Step 8 Click Next.

Step 9 On the Enter Failover Account Information page, click Browse, and double-click the name of the message store services account. This is the account that the failover service will log on as.

The account you select must have the right to act as part of the operating system and to log on as a service, and must be a member of the Local Administrators group.


Caution You must specify the same account on both the primary and secondary servers.

Step 10 In the Password field, enter the password for the account that the failover service will log on as, and click Next.

Step 11 On the Begin Configuring Your Server page, click Configure. The wizard verifies settings and configures failover on the secondary server.

If the wizard does not finish the configuration successfully, an error message explains why the wizard failed. Exit the wizard, correct the problem, and click Configure again.

Step 12 On the Completing page, click Finish.


Troubleshooting Failover and Failback Behavior

To troubleshoot failover and failback behavior, check the following components in the order given.

Event IDs

Integration Configuration

Macro or Micro Traces

MWI Synchronization

Event IDs

You can use event IDs, which appear in the Event log, to determine the cause of failover or failback.

To Determine the Cause of Failover or Failback from an Event ID


Step 1 On the primary server, on the Windows Start menu, click Programs > Administrative Tools > Event Viewer.

Step 2 In the Tree pane on the left, click Application Log. The log appears in the right pane.

Step 3 Locate the entries that show CiscoUnity_NodeMgr in the Source column.

Step 4 For the entries, note the event IDs that appear in the Event column.

Step 5 On the secondary server, repeat Step 1 through Step 4.

Step 6 Use Table 3-2, which follows the procedure, to determine the cause of failover or failback.


Table 16-1 Causes of Failover or Failback Based on Event ID 

Server and Event ID
Cause

Primary: 1070 and 1048

Secondary: 1050 and 1047

Manual failover occurred, initiated by the system administrator using the Failover Monitor.

Primary: 1078 and 1048

Secondary: 1050 and 1047

Manual failover occurred, initiated by the Event Monitoring Service (EMS) when a user-specified event occurs.

Secondary: 1068 and 1048

Primary: 1049 and 1047

Manual failback occurred.

Secondary: 1069 and 1048

Primary: 1049 and 1047

Scheduled failback occurred.

Secondary: 1050 and 1047
1010 (possible)
1011 (possible)

The active primary server crashed.

Primary: 1049 and 1047
1010 (possible)
1011 (possible)

The active secondary server crashed.

Primary: 1010 (possible)
1011 (possible)

Secondary: 1050 and 1047
1010 (possible)
1011 (possible)

The active primary server has network connectivity problems.

Secondary: 1010 (possible)
1011 (possible)

Primary: 1049 and 1047
1010 (possible)
1011 (possible)

The active secondary server has network connectivity problems.

Primary: 1048

Secondary: 1050, 1047,
and CiscoUnity_Miu 542

The combination of event IDs will appear for any of the following causes:

The active primary server has a bad port that caused failover to occur.

A caller dialed the extension of a voice messaging port in the secondary server and the Force Failover If Call Arrives on Inactive Secondary check box is checked in the Failover Monitor, causing failover to occur.

Integrations through voice cards: For phone systems that use a linear hunt group (the hunt group starts searching always with the same voice messaging port), an unintended failover may have occurred if the Force Failover If Call Arrives on Inactive Secondary check box is checked in the Failover Monitor. With this configuration, when a call to Cisco Unity is terminated either before being answered or within a few seconds after being answered by the primary server, the phone system may route a second call immediately to the same port. This can cause the secondary server to count rings from both calls as a single call, thus triggering failover.

The cause can be eliminated by setting up a guard timer on the phone system. The timer enforces a minimum interval between consecutive calls sent to a given port. Note that the timer may not be available on all phone systems.


Integration Configuration

Confirm that phone system is correctly programmed for the integration with failover. Refer to the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Also confirm that Cisco Unity servers are correctly configured for the integration with failover. Refer to the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Take the applicable steps to ensure that the phone system and the Cisco Unity servers are correctly configured.

Macro or Micro Traces

Set the applicable macro or micro traces for Cisco Unity components and trace levels. See the "Using Diagnostic Utilities for Cisco Unity" section on page 2-1.

MWI Synchronization

Resynchronization of the voice mailboxes (Notifier resynchronization) takes place after failover and failback occur. As a result, MWI changes may not occur until the Notifier resynchronization is completed. When MWIs do not accurately indicate that new messages are waiting shortly after failover or failback occurs, wait until the Event log indicates that the Notifier resynchronization has completed to determine whether MWIs are correctly synchronized.

Troubleshooting File Replication

To troubleshoot Cisco Unity file replication, check the following areas in the order given:

Confirm that the Files Should Be Replicated

Confirm that File Replication Is Enabled

Confirm the Permission Used By the Node Manager Service

Confirm that the Files Should Be Replicated

Confirm that the Cisco Unity files in question should be replicated between the primary and secondary servers. Note the following about file replication:

The frequency of file replication between the primary and secondary servers depends on the value of the File Replication Interval field in the Failover Monitor and how often the Cisco Unity files change.

The Node Manager service monitors and replicates the files in the following directories on the Cisco Unity servers:

Localize\DefaultConfiguration

Localize\Prompts

Snapshot

StreamFiles

Support

UnityMTA (which contains the Unity Messaging Repository, or UMR)

Confirm that File Replication Is Enabled

Confirm that file replication is correctly configured for Cisco Unity failover: Do the following procedure.

To Confirm The File Replication Is Correctly Configured


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

Step 2 Click Advanced.

Step 3 Do one of the following:

Confirm that the Disable Automatic Failover and Failback check box is unchecked.

(If the Disable Automatic Failover and Failback check box is checked, confirm that the Enable File Replication check box is checked.


Note The Enable File Replication check box does not appear if ES1 is not installed on the Cisco Unity servers.


Step 4 If you changed a setting, click OK.

Step 5 Click Configure.

Step 6 Confirm that the File Replication Interval field is set to the amount of time that elapses before the active server replicates to the inactive server. The default is 10 minutes.


Note Increasing the file replication interval causes the active server to replicate files to the inactive server less often.


Step 7 If you changed a setting, click OK.

Step 8 Exit the Failover Monitor.


Confirm the Permission Used By the Node Manager Service

Confirm that the Node Manager service (AvCsNodeMgr) meets the following requirements:

The same on the primary and secondary servers.

A domain account.

The right to log on as a service.

Right to act as part of the operating system.

A member of the Local Administrators group.

Take the applicable steps to ensure that the Node Manager service has the required permission.

Troubleshooting SQL Replication

To troubleshoot the SQL replication, check the following areas in the order given:

Confirm that the Data Should Be Replicated

Perform a Failover Health Check

Perform a SQL Replication Health Check

Stop and Restore SQL Replication

Determine Whether the SQL Server Has Been Renamed

Confirm that the Data Should Be Replicated

Confirm that the data should be replicated between the primary and secondary servers. Note the following about SQL replication:

Replication occurs every minute if there are 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 the AvCsMgr service is stopped or the Cisco Unity server crashes, 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.

Changes to the following Cisco Unity settings are not replicated between the primary and secondary servers. You must manually change values on both servers.

Registry settings

Recording settings

Phone language settings

GUI language settings

Port settings

Integration settings

Conversation scripts

Key mapping scripts

Media Master server name settings

The message store, when installed on the secondary server

Perform a Failover Health Check

Check for the general health of failover by doing the following procedures.

To Add a Test Subscriber with a Recorded Name


Step 1 In Cisco Unity Administrator on the primary server, go to the Subscribers > Subscribers > Profile page.

Step 2 Click the Add icon.

Step 3 Click New Exchange Subscriber.

Step 4 Enter the applicable information on the Add Subscriber page.

Step 5 Click Add.

Step 6 Record the subscriber name by using the Media Master control bar.

Step 7 On the subscriber record, customize settings as applicable, then click the Save icon.


To Confirm That the Data Replication to the Secondary Server Occurred


Step 1 In Cisco Unity Administrator on the secondary server, go to the Subscribers > Subscribers > Profile page for the test subscriber. Seeing the test subscriber on the secondary server indicates that failover replicates the UnityDb SQL database.

Step 2 Confirm that the Media Master control bar shows that a recorded name exists (the length of the recording is greater than 0). Seeing the recorded name indicates that failover replicates recordings.


To Make the Secondary Server Active


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

Step 2 Click Failover.

Step 3 Click OK to confirm that you want to initiate failover to the secondary server.


To Set Up the Integration Test for the Secondary Server


Step 1 Set up two test extensions (Phone 1 and Phone 2) on the same phone system that the Cisco Unity servers are integrated with.

Step 2 Set Phone 1 to forward calls to the Cisco Unity pilot number when calls are not answered.

Step 3 In Cisco Unity Administrator, go to the Subscribers > Subscribers > Profile page for the test subscriber that you created in the "To Add a Test Subscriber with a Recorded Name" procedure.

Step 4 In the Extension field, enter the extension of Phone 1.

Step 5 In the Active Schedule field, click All Hours - All Days.

Step 6 Click the Save icon.

Step 7 In the navigation bar, click Call Transfer to go to the Subscribers > Subscribers > Call Transfer page for the test subscriber.

Step 8 Under Transfer Incoming Calls, click Yes, Ring Subscriber's Extension, and confirm that the extension is for Phone 1.

Step 9 Under Transfer Type, click Release to Switch.

Step 10 Click the Save icon.

Step 11 In the navigation bar, click Messages to go to the Subscribers > Subscribers > Messages page for the test subscriber.

Step 12 Under Message Waiting Indicators (MWIs), check the Use MWI for Message Notification check box.

Step 13 In the Extension field, enter x.

Step 14 Click the Save icon.


To Test Recording a Message and Activating the MWI


Step 1 From Phone 2, dial the extension for Phone 1.

Step 2 Confirm that Phone 1 rings and that you hear a ringback tone on Phone 2. Do not answer Phone 1.

Step 3 Confirm that after the number of rings that the phone system is set to wait, the call is forwarded to Cisco Unity and that you hear the greeting for the test subscriber. Hearing the greeting means that the phone system forwarded the unanswered call and the call-forward information to Cisco Unity, which correctly interpreted the information.

Step 4 Leave a message for the test subscriber, and hang up Phone 2.

Step 5 Confirm that the MWI on Phone 1 is activated. The activated MWI means that the phone system and the secondary server are successfully integrated for activating MWIs.


To Test Listening to a Message and Deactivating the MWI


Step 1 From Phone 1, dial the internal pilot number for Cisco Unity.

Step 2 When asked for your password, enter the password for the test subscriber. Hearing the request for your password means that the phone system sent the necessary call information to Cisco Unity, which correctly interpreted the information.

Step 3 Confirm that you hear the recorded name for the test subscriber (if you did not record a name for the test subscriber, you will hear the extension for Phone 1). Hearing the recorded name means that Cisco Unity correctly identified the subscriber by the extension.

Step 4 When asked whether you want to listen to your messages, press 1.

Step 5 After listening to the message, press 3 to delete the message.

Step 6 Confirm that the MWI on Phone 1 is deactivated. The deactivated MWI means that the phone system and Cisco Unity are successfully integrated for deactivating MWIs.

Step 7 Hang up Phone 1.


To Delete the Test Subscriber


Step 1 In Cisco Unity Administrator, go to the Subscribers > Subscribers > Profile page.

If the name of the test subscriber is not displayed, click the Find icon (the magnifying glass) in the title bar, then click Find, and click the name of the test subscriber in the list that appears.

Step 2 In the title bar, click the Delete Subscriber icon (the X).

Step 3 Click Delete.


Take the applicable steps to resolve any problems that were exposed by the health check.

Perform a SQL Replication Health Check

To Check the Health of SQL Replication


Step 1 On the primary server, on the Windows Start menu, click Programs > Microsoft SQL Server > Enterprise Manager. The SQL Server Enterprise Manager window appears.

Step 2 In the left pane of the Console Root window, browse to the Replication node for the primary server. Typically, the node is three levels under the Microsoft SQL Servers node.

Step 3 Click the Replication node.

Step 4 Confirm that the following agents have the status "Idle" or "Succeeded":

Snapshot

Log Reader

Distribution

Queue Reader

Step 5 Close the Console Root window.

Step 6 Exit Enterprise Manager.

Step 7 Repeat Step 1 through Step 6 on the secondary server.


If the any of the SQL agents have the status "Failed," continue to the next section.

Stop and Restore SQL Replication

If SQL replication is broken, stop SQL replication and restore it by doing the following procedures.

To Stop SQL Replication


Step 1 On the primary server, on the Windows Start menu, click Programs > Microsoft SQL Server > Enterprise Manager. The SQL Server Enterprise Manager window appears.

Step 2 In the left pane of the Console Root window, browse to the Replication node for the primary server. Typically, the node is three levels under the Microsoft SQL Servers node.

Step 3 Right-click the Replication node, and click Disable Publishing. The Disable Publishing and Distribution wizard appears.

Step 4 On the Welcome page, click Next.

Step 5 On the Disable Publishing page, click Yes, then click Next.

Step 6 On the Confirm Dropping of Publications page, click Next.

Step 7 On the Completing page, click Finish.

Step 8 When the process is completed, click OK.

Step 9 Close the Console Root window.

Step 10 Exit Enterprise Manager.


To Restore SQL Replication on the Primary Server


Step 1 On the primary server, in Windows Explorer, browse to the CommServer directory.

Step 2 Double-click FailoverConfig.exe to start the Configure Cisco Unity Failover wizard.

Step 3 On the Welcome page, click Next.

Step 4 On the Specify Server Role page, click Primary Server, and click Next.

Step 5 On the Enter the Name of Your Server page, click Browse, select the name of the secondary server, and click OK. The IP address for the secondary server is filled in automatically.

Step 6 Click Next.

Step 7 On the Enter Failover Account Information page, click Browse, and double-click the name of the message store services account. This is the account that the failover service will log on as.

The account you select must have the right to act as part of the operating system and to log on as a service, and must be a member of the Local Administrators group.


Caution You must specify the same account on both the primary and secondary servers.

Step 8 In the Password field, enter the password for the account that the failover service will log on as, and click Next.

Step 9 On the Begin Configuring Your Server page, click Configure. The wizard verifies settings and configures failover on the primary server.

If the wizard does not finish the configuration successfully, an error message explains why the wizard failed. Exit the wizard, correct the problem, and click Configure again.

Step 10 On the Completing page, click Finish.


To Restore SQL Replication on the Secondary Server


Step 1 On the secondary server, on the Windows taskbar, double-click the system clock. The Date/Time Properties dialog box appears.

Step 2 Set the time to the same hour and minute as shown on the primary server, and click OK.

Step 3 In Windows Explorer, browse to the CommServer directory.

Step 4 Double-click FailoverConfig.exe to start the Configure Cisco Unity Failover wizard.

Step 5 On the Welcome page, click Next.

Step 6 On the Specify Server Role page, click Secondary Server, and click Next.

Step 7 On the Enter the Name of Your Server page, click Browse, select the name of the primary server, and click OK. The IP address for the primary server is filled in automatically.

Step 8 Click Next.

Step 9 On the Enter Failover Account Information page, click Browse, and double-click the name of the message store services account. This is the account that the failover service will log on as.

The account you select must have the right to act as part of the operating system and to log on as a service, and must be a member of the Local Administrators group.


Caution You must specify the same account on both the primary and secondary servers.

Step 10 In the Password field, enter the password for the account that the failover service will log on as, and click Next.

Step 11 On the Begin Configuring Your Server page, click Configure. The wizard verifies settings and configures failover on the secondary server.

If the wizard does not finish the configuration successfully, an error message explains why the wizard failed. Exit the wizard, correct the problem, and click Configure again.

Step 12 On the Completing page, click Finish.


If the failover configuration wizard fails, follow the steps in the "The Failover Configuration Wizard Does Not Finish Successfully" section.

Determine Whether the SQL Server Has Been Renamed

While running the failover configuration wizard, the following error may appear:

Configure Cisco Unity Failover Wizard - [0x80044833]
[Microsoft][ODBC SQL Server Driver][Sql Server]Could not connect to server
"<new_server_name>" because `distributor_admin' is not defined as a remote login
at the server.

This error occurs when the SQL Server was renamed after it was originally installed, and therefore the SQL Server name (old server name) does not match the machine name (new server name). To change the SQL Server name (old) to match the machine name (new), do the following "To Change the SQL Server Name" procedure.


Note Before doing this procedure, you must log on to the server with sufficient permission to change the database.


To Change the SQL Server Name


Step 1 On the Windows Start menu, click Programs > Microsoft SQL Server > Query Analyzer.

Step 2 In the Connect to SQL Server dialog box, enter the following settings:

a. In the SQL Server field, enter the name of the Cisco Unity server.

b. Under Connect Using, click Windows Authentication.

Then click OK.

Step 3 In the SQL Query Analyzer window, enter select @@servername, press Enter, and click the Execute Query button. The lower pane of the window displays the old server name, which you will enter in Step 4.

Step 4 Enter exec sp_dropserver '<Old_server_name>', where <Old_server_name> is the name you found in Step 3, and press Enter. Note that you must use single quotation marks as shown.

Step 5 Enter exec sp_addserver '<new_server_name>', 'local', and press Enter. Note that you must use single quotation marks as shown.

Step 6 Click the Execute Query button.

Step 7 In the system tray, right-click the MSSQLServer icon, and click MSSQLServer - Stop.

Step 8 When prompted to confirm stopping the MSSQLServer service, click Yes.

Step 9 When prompted to confirm stopping all dependent services, click Yes.

Step 10 In the AvCsTrayStatus dialog box, click OK.

Step 11 When the MSSQLServer icon indicates that the SQL Server has restarted, in the Query window, select the line select @@servername, and click the Execute Query button to verify the new server name.

Step 12 Close the SLQ Query Analyzer window.

Step 13 In the system tray, right-click the Cisco Unity icon, and click Start Unity.