This document explains some of the error messages that can appear during Cisco Unity failover and provides the recommended workarounds.
Ensure that failover is configured on the Cisco Unity primary and secondary servers. Refer to Configuring Failover on the Primary and Secondary Servers for more information. Also, refer to Cisco Unity installation fails when running MSCW with the Failed getting container for new users for domain [our domain]. error message.
The information in this document is based on Cisco Unity version 4.0(3).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Failover is a feature that provides a simple redundancy, which allows voice messaging functions to continue if the Cisco Unity server fails or when you need to perform maintenance. In order to set up failover, you need to install and configure Cisco Unity on two different servers: a primary server and a secondary server.
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 to perform standard Cisco Unity operations. This shift from primary to secondary Cisco Unity servers is called failover.
When a failover occurs, the changes made to the data in the SQL Database (UnityDb) are replicated from the primary server to the secondary server. However, there might be instances when these changes are not replicated from the primary server to the secondary server.
When you run the Failover configuration wizard, this SQL Replication error message might appear:
ODBC Error:Could not change the Publisher because the subscription has been dropped. Use sp_subscription_cleanup to clean up the triggers
This error occurs when the SQL Server was renamed after it was originally installed. Therefore, the SQL Server name (old server name) does not match the new machine name (new server name). Complete these steps in order to confirm this:
On the Windows Start menu, click Programs > Microsoft SQL Server > Query Analyzer.
In the Connect to SQL Server dialog box, enter these settings:
In the SQL Server field, enter the name of the Cisco Unity server.
Under Connect Using, choose Windows Authentication.
In the SQL Query Analyzer window, enter select @@servername, then press Enter and click the Execute Query button.
The lower pane of the window displays the old or incorrect server name.
Note: You can also run select @@servername from the command line, as shown here:
Complete these steps in order to correct the discrepancy in the server names:
Enter exec sp_dropserver '<Old_server_name>',, where <Old_server_name> is the name you found in step 4 under the Problem Description section. Then, press Enter.
Note: You must use single quotation marks as shown.
Enter exec sp_addserver '<new_server_name>', 'local', and press Enter.
Note: You must use single quotation marks as shown.
Click the Execute Query button.
In the system tray, right-click the MSSQLServer icon, then click MSSQLServer -Stop.
When prompted to confirm stopping the MSSQLServer service, click Yes.
When prompted to confirm stopping all dependent services, click Yes.
In the AvCsTrayStatus dialog box, click OK.
When the MSSQLServer icon indicates that the SQL Server has restarted, select the select @@servername line in the Query window, then click the Execute Query button in order to verify the new server name.
Close the SQL Query Analyzer window.
In the system tray, right-click the Cisco Unity icon, and choose Start Unity.
Create a test subscriber and record a subscriber name to test replication.
If the recorded name still does not replicate across to the secondary server, check both the primary and the secondary server's shares that are normally used for replication, such as the Stream Files directory, UnityMTA directory, Support Directory, etc.
These should be share enabled. Ensure that the permissions are correct.
You can manually enable sharing for those directories and confirm if the recorded name of the dummy subscriber has replicated.
The Unity 4.x server in failover might periodically see an error message similar to this in the application event log:
Event Type: Warning Event Source: CiscoUnity_NodeMgr Event Category: Run Event ID: 1033 Date: 03/30/2007 Time: 1:41:56 PM User: N/A Computer: <computer name> Description: AvCsNodeMgr unable to connect to SQL Server on LocalHost. Error 0x80044818.
The Cisco Unity Node Manager service periodically checks the status of the local and remote database, and in particular the status of replication. A public Microsoft COM interface is used directly by the Node Manager, so the error code reported is a Microsoft SQL (COM) error on the attempt to connect.
The Node Manager Micro Traces Initialization (11) and Replication (17) attempt to provide further information by trying to report the Microsoft error message for the error code. The interval at which this check is performed is held in the registry, in the SQLReplicationCheckIntervalSec under HKLM\Software\Active Voice\AvCsNodeMgr\1.0 key. The default is 15 minutes (900 seconds). Further information on the error code or error message comes from Microsoft.
This error does not affect any services.
In order to make sure Unity works correctly, verify the SQL connectivity by using enterprise manager on each Unity server to see if it can talk to the local and remote SQL databases, and that the Node Manager service runs with the same domain administrator account on the two Unity servers.
This error message appears in the application event log of the failover server:
Event Type: Warning Event Source: CiscoUnity_NodeMgr Event Category: Run Event ID: 1059 Date: 10/13/2003 Time: 4:31:40 PM User: N/A Computer: UNITY1 Description: GetFileAttributes for \\UNITY2\Snapshot\PDS1.txt failed with error 0x80070035. For more information, click: http://www.CiscoUnitySupport.com/find.php
This typically means that the account the AvCsNodeMgr service logs in as (Programs > Administrative Tools > Services) does not have permission to retrieve the information it needs from the secondary server.
In order to fix this, check the permissions of the failover account as described in the Cisco Unity Failover Configuration and Administration Guide (With Microsoft Exchange), Release 4.x. The account you choose must have the right to act as part of the operating system and to log on as a service. Also, the account must be a member of the Local Administrators group. The account must be the same for both the primary and secondary servers.
If this solution did not resolve the issue, complete these steps:
Explore the \commserver\snapshot directory, right-click the Snapshot folder, and choose Sharing.
Click the Permissions button to make sure that the svcunitymsgstore account has the full control permission.
In order to check the file level permissions, right-click the Snapshot folder and choose the Security tab. Make sure the users have the required permission.
Cisco Unity voice mail port(s) fail to answer inbound calls until port(s) are reset from the Cisco CallManager voice mail port configuration screen. The port(s) state is listed as "idle" when viewed from the Unity Status Monitor. The following errors display on the primary failover server in a Cisco Unity failover cluster.
Event Type: Error Event Source: CiscoUnity_Miu Event Category: Error Event ID: 549 Date: 7/8/2003 Time: 8:41:39 AM User: N/A Computer: UnityServer Description: Cisco Unity's telephony component has encountered a serious error. EXPLANATION: No reponse was received on port 5 while waiting for an incoming call to be answered. This is a serious failure, and most likely parties involved in the call will be disconnected. In some cases, further calls on this port will not be handled correctly. TECHNICAL DETAILS: Thread 0x00001218 had a Failure on Port 5 in Method CAvMiuLine::Answer()
Event Type: Error Event Source: CiscoUnity_Miu Event Category: Error Event ID: 559 Date: 7/8/2003 Time: 8:42:09 AM User: N/A Computer: UnityTest Description: Cisco Unity's telephony component has encountered a serious error. EXPLANATION: A serious failure has occurred on port 5 while dropping a call. In some cases, further calls on this port will not be handled correctly. TECHNICAL DETAILS: Thread 0x00001218 had a Failure on Port 5 in Method CAvMiuLine::Drop()
CiscoUnity_Miu, Event ID: 549 and 559: This error can occur when an IP phone device places a call into Cisco Unity, and, for some reason, it is not able to send its keepalives to the Cisco CallManager. As a result, the CallManager declares the phone unreachable (temporary failure).
If Unity is in the setup phase of the call, receipt of this 'temporary failure' message causes the Unity port to generate this error message, but it does not send an on-hook message back to the CallManager. Because of this, the CallManager thinks that the port is still in use, while Unity thinks that the port is free. The result is that no calls can be placed to that Unity port.
Make sure that the ports are set up correctly in accordance with the Cisco CallManager- Cisco Unity Integration Guide.
Reboot the Unity server and check if the error messages still appear.
Open the Cisco Unity Status Monitor and check the Port Status for any occurrence of port lockups. If so, reset the port from the Cisco Unity Status Monitor. For more information, refer to Troubleshooting Port Lockups in Cisco Unity.
Reset the port from the Cisco CallManager voice mail port configuration page.
Check if there are any high CPU issues since this can also trigger this error.
With Cisco Unity 7.0(2.0), when the Failover Configuration Wizard (FCW) is run, you might not be able to see the name of the partner server when you need to choose the primary or secondary server. This will not allow you to complete setting up failover.
Perform this workaround:
On the server where you cannot see the other server name, you need to edit this registry key:
Create a new string value named Partner Server Name with a value of the other server name in the failover cluster.
Create a string value Partner Server IP with a value of the IP address of the other server.
Once you do this, re-run the failover configuration wizard.
You should now be able to get past the point of selecting the server name in the application and complete running the wizard.
- Synchronize the Unity Failover Database between the Primary and Secondary Unity Servers Configuration Example
- The Cisco Unity Failover Wizard Configuration
- Voice Technology Support
- Voice and Unified Communications Product Support
- Troubleshooting Cisco IP Telephony
- Technical Support & Documentation - Cisco Systems
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.