Cisco Unity Bridge Networking Guide, Release 3.0 (With IBM Lotus Domino) - Monitoring and Maintaining Bridge Networking [Cisco Unity]

Table Of Contents

Monitoring and Maintaining Bridge Networking

Controlling the Number of Ports Used for Outgoing Messages

Determining Optimal Values for Queued Call Threshold and Max Ports Per Node

Bridge Analog Network and Node Analyzer (BANANA)

Getting Started Using the BANANA admin to Monitor Analog Activity

Bridge Traffic Analyzer

Backing Up and Restoring a Bridge Server

Backing Up the Bridge Server

Replacing a Bridge Server and Restoring Data

Changing the Interop Gateway Foreign Domain Name

Moving the Interop Gateway Mail File

Moving the UOmni Mail File

Monitoring Recommendations

Monitoring and Maintaining Bridge Networking

This chapter provides information on monitoring and maintaining Bridge Networking. See the following sections for more information:

•Controlling the Number of Ports Used for Outgoing Messages

•Bridge Analog Network and Node Analyzer (BANANA)

•Bridge Traffic Analyzer

•Backing Up and Restoring a Bridge Server

•Changing the Interop Gateway Foreign Domain Name

•Moving the Interop Gateway Mail File

•Moving the UOmni Mail File

•Monitoring Recommendations

Controlling the Number of Ports Used for Outgoing Messages

Outgoing messages from the Bridge to an Octel node are placed in queues. The Bridge maintains three queues for each node—one queue each for normal and urgent messages, and a third for administrative tasks. Queued messages are processed in first-in-first-out (FIFO) order.

The Bridge can simultaneously use more than one port on the analog voice-fax card(s) in the Bridge server to send messages to a particular Octel node. For example, assume that there are several messages in the normal message queue for a specific node, and that the Bridge is using one port to transmit the messages. If an administrative or urgent message is then sent to that same node during the time that the normal message traffic is being transmitted, the Bridge will use another port to dial out to send the administrative or urgent message.

Two parameters on the System Settings page in the Bridge Administrator allow you to control the number of ports used for outgoing messages to a specific node: Queued Call Threshold and Max Ports Per Node. These values are applied to the normal and urgent outgoing message queues for each node. (Note that these values are not applied to administrative queues. Only one port at a time will ever be used for administrative calls to a particular node).

The value in Queued Call Threshold specifies the threshold number of messages that must be in the outgoing message queue of a specific node for an additional port to be used for message delivery. As the number of messages in the queue increases, an additional port is added when the number of messages in the queue reaches a multiple of this parameter.

For example, if the value of Queued Call Threshold is set to 10 (the default value), one port will be used for message delivery if there are fewer than 10 messages in the queue. For 10-19 messages, two ports will be used. For 20-29 messages, three ports will be used, and so on. The total number of ports used is limited by the Max Ports Per Node parameter.

Queued Call Threshold is also used to determine when to disconnect a port used for outgoing messages to a specific node. As the number of messages in the queue decreases, a port is disconnected when the number of messages in the queue is below the next lower multiple of this parameter. When only two ports are in use, as the number of messages in the queue drops below half of this parameter, the second port is disconnected.

For example, if the value of the Queued Call Threshold is set to 10, three ports will be used for message delivery if there are 20-29 messages in the queue. As the number of messages in the queue decreases, the third port is not disconnected until the number of messages in the queue drops to 10 or fewer. When the number of messages drops to 5 or fewer messages, the second port is disconnected, so only one port is used to transmit the remaining messages.

The Max Ports Per Node parameter allows you to specify the maximum number of ports that can be used simultaneously to deliver messages to a particular node. Again, this value is applied to each message queue. For example, if Max Ports Per Node is set to 4 (the default value), it is possible that 9 ports could be used simultaneously to send normal, urgent, and administrative messages to a specific node. In this example, up to 4 ports could be used for normal messages; up to 4 ports could be used for urgent messages; and 1 port would be used for administrative messages. (Outbound administrative calls to the same node are not placed simultaneously. Only one port at a time will ever be used for administrative calls to a particular node.)

Determining Optimal Values for Queued Call Threshold and Max Ports Per Node

The optimal values for Queued Call Threshold and Max Ports Per Node depend on the number of ports, the number of nodes, and on message traffic patterns. Start with the default values for these parameters, and use the Bridge Traffic Analyzer to observe message traffic patterns to see whether you need to adjust the settings. See the "Bridge Traffic Analyzer" section for more information.

The default values should be appropriate for light message traffic because with light traffic, the thresholds for the parameters are never reached. The default values should also be sufficient for installations with medium traffic and a small to medium number of Octel nodes. However, installations with medium traffic and ten or more Octel nodes, or with high traffic, should carefully watch the reports generated by the Bridge Traffic Analyzer, and adjust the values for the parameters as necessary.

If you decide to adjust the values for Queued Call Threshold and Max Ports Per Node, keep in mind that the Bridge ports are used for both outgoing messages to Octel nodes and incoming messages to the Bridge. If message traffic is heavy enough, it is possible to adjust the values such that all the ports will be used for outgoing messages, leaving no ports available for incoming messages. If this is a concern, you may want to designate one or more ports to be used only for incoming calls. The Line Status page in the Bridge Administrator allows you to specify whether each line is to be used for both incoming and outgoing calls or only for incoming calls.

Bridge Analog Network and Node Analyzer (BANANA)

BANANA is a stand-alone application that runs on the Bridge server. It is designed to assist with monitoring and troubleshooting analog communication between the Bridge and the Octel nodes in the analog network. It also provides detail and summary information of call activity.

BANANA contains an administration application called the BANANA admin that allows you to control how BANANA:

•Generates test calls to the Octel systems that are networked with the Bridge server.

•Extracts information from the call traces on the Bridge server and presents different views of the data.

•Monitors the call traces for error conditions, and logs warnings or errors to the Windows Event Viewer.

With the BANANA admin, you can also install and configure the BANANA service to do the tasks listed above at configurable intervals.

If you have already installed BANANA, skip to the "Getting Started Using the BANANA admin to Monitor Analog Activity" section.

To Install BANANA

Step 1 Disable virus scanning services and the Cisco Security Agent service, if applicable.

Step 2 Insert the Cisco Unity Bridge compact disc in the CD-ROM drive, and browse to the BANANA directory.

Step 3 Double-click setup.exe.

Step 4 Click OK at the welcome screen.

Step 5 If applicable, change the directory where BANANA will be installed.

Step 6 Click the Installation button.

Step 7 If applicable, change the program group where BANANA will appear.

Step 8 Click Continue.

Step 9 If a Version Conflict message box is displayed warning that a file being copied is not newer than the file on your system, click Yes to keep the existing file.

Step 10 When the installation is done, click OK.

Step 11 Enable virus-scanning and the Cisco Security Agent services, if applicable

Note The most up-to-date version of BANANA is available at http://www.CiscoUnityTools.com. When you start BANANA, it checks the Cisco Unity Tools website to see if a newer version is available, and if so, prompts you about upgrading.

Getting Started Using the BANANA admin to Monitor Analog Activity

If the Bridge server sends and receives many messages, it is likely that when you view the call traces in BANANA admin, you will see some errors. Do not be alarmed; due to the nature of analog transmissions, some errors are to be expected. In order to send and receive messages between the Bridge and an Octel node, DTMF tones are exchanged in accordance with the Octel analog protocol. It is not uncommon for line noise to interfere with the transmission or reception of DTMF tones, particularly when the tones are transmitted over the PSTN. In an environment with Cisco CallManager and Cisco gateways, the circuit-switched calls are encoded and repackaged into IP packets. The transcoding must be precise. The DTMF duration and interdigit timing on the Cisco gateways or Cisco CallManager must be set to a value between 80 and 100 milliseconds. Incorrect settings will cause transmission problems.

When you first set up Bridge Networking, we recommend that you use the BANANA admin to frequently monitor the analog activity (at least daily, though more frequently if necessary) to find and fix problems. By monitoring the analog activity, you will become familiar with the message traffic patterns and learn what ratio of errors is within a "normal" range.

The following procedure will get you started using the BANANA admin. Refer to the BANANA Help file for details about how to do each task.

To Get Started Using the BANANA admin

Step 1 On the Windows Start menu on the Bridge server, click Programs > BANANA > BANANA admin.

Step 2 If you have not already done so, configure the log and output folder locations.

Step 3 Optionally, adjust the Hours of Data to Retain in Database setting.

You may want to increase the setting if there is sufficient disk space on the Bridge server. Be careful if you decrease the setting from the default because only the most recent call data will be retained after the call data is subsequently processed, and you could lose data that you need for troubleshooting a problem.

Step 4 Click Process Call Data.

BANANA processes the call traces and then displays information about incoming and outgoing calls in the Calls grid. Calls that resulted in errors are displayed in the Errors grid.

Step 5 Click View Node Totals to display the Totals per Octel Node dialog box.

This view of the data is useful for identifying communication problems with a particular Octel node. For example, if the ratio of errors to calls for a particular Octel node is significantly higher than for the other nodes, you can investigate the problem further by doing the following sub-steps:

a. Make note of the serial number of the Octel node with a high number of errors.

b. Click the main BANANA admin window, and then click the octelserialnumber column header in the Calls grid to sort the calls by Octel serial number.

c. In the Calls grid, click a row with the problematic serial number that has an exitcode other than OK. The corresponding record in the Errors grid is highlighted. This record provides specific details regarding the condition under which the call was terminated, including the state of the protocol that was in process, and the reason why the call could not be completed.

d. Click View Call Detail for Selected Call. This view of the data displays the mailboxes that were involved in the call, which is useful if someone notifies you that they received an NDR, or if you are tracking down a directory update problem that was logged in the Windows Event Viewer. You can also use this view of the data to verify that the message (or other action) involved in the failed call was repeated later in a successful call.

Step 6 Configure BANANA to monitor the call traces for error conditions, and to log warnings or errors to the Windows Event Viewer. As needed, you can adjust the notification settings.

Bridge Traffic Analyzer

The Bridge Traffic Analyzer is a report-generation utility that reads the call traces on the Bridge server, and generates a graph and a summary table that can be saved as a comma-separated value (CSV) file. The Bridge Traffic Analyzer is available for download at http://www.CiscoUnityTools.com.

The Bridge Traffic Analyzer generates reports by using the data in the call traces in the \Starfish\Log directory on the Bridge server. The Call Log Retention parameter on the System Settings page in the Bridge Administrator allows you to specify the number of days of call history to retain. For more information about the Call Log Retention setting, see the "System Settings" section on page 8-1.

In the reports, the direction of the queues is from the perspective of Cisco Unity:

•The inbound queue contains messages from Octel nodes that the Bridge sends to Cisco Unity. Messages in the inbound queue are sent to Cisco Unity by using SMTP. Therefore, unless Cisco Unity or Domino is down, messages move very quickly through the inbound queue.

•The outbound queue contains messages from Cisco Unity that the Bridge sends to the appropriate Octel nodes. Messages in the outbound queue are sent through the ports on the analog voice-fax card(s) on the Bridge server to the Octel nodes. Because the number of ports is a fixed resource, and because analog transmissions are slow in comparison to SMTP, it is possible that messages will back up in the outbound queue.

The Bridge Traffic Analyzer provides the following reports:

•Port Availability—Shows the availability of ports on the analog voice-fax card(s) on the Bridge server. You can choose to show how many ports were available to take calls from Octel nodes, how many ports were busy, or both. The summary CSV file presents a table with the maximum and minimum number of available ports for each hour during the day.

•Message Queue Activity—Shows how many messages and how much data is passing through the inbound and outbound message queues on the Bridge server. You can choose to show the number of messages, the message queue size in megabytes, or both. The summary CSV file presents a table with the maximum number of messages in the inbound and outbound queues, and the maximum message size of the inbound and outbound queues for each hour during the day.

•Message Latency—Shows the length of time that messages stayed in the outbound queue before being delivered to the Octel nodes. You can select a time range for the report (the default is 24 hours), and you can choose which Octel nodes to see in the report (by default, all nodes are shown). The Message Latency report shows only the outbound queue. Messages arrive quickly from Cisco Unity, but are delivered by analog lines to their target Octel node; therefore, it is possible for messages to back up in the queue waiting for an available port.

•Node Message Traffic—Shows how many messages and how much data is passing between different Cisco Unity and Octel nodes. For example, you can use this report to determine which Octel nodes a specific Cisco Unity server is messaging with most heavily. You can select one or more Cisco Unity nodes, one or more Octel nodes, and a time range for the report.

Refer to the Help file that comes with the Bridge Traffic Analyzer for more information about these reports.

Backing Up and Restoring a Bridge Server

This section explains how to backup data on the Bridge server, and how to restore that data to another Bridge server. See the following sections:

•Backing Up the Bridge Server

•Replacing a Bridge Server and Restoring Data

Backing Up the Bridge Server

Both offline and online backups are supported for the Cisco Unity Bridge server. When backing up the Bridge server, you need to back up only the configuration and data files; you do not need to back up the Bridge software because it is easy to reinstall the Bridge software on another server. The files that you back up on the Bridge server include:

•WAV files of voice names for Octel and Unity node directory entries

•A database that contains configuration data and information about Octel and Unity node directory entries

•Configuration files

For a list of backup and restore software supported for the Bridge server, refer to the "Supported Backup Software" section of Cisco Unity Bridge 3.0 System Requirements, and Supported Hardware and Software, available at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/bridge30/sysreq/30bsysrq.htm.

No unique software agents are required. We recommend that you do the backup during off-peak hours.

See the following procedures for step-by-step instructions:

•To Do an Online Backup of the Bridge Server by Using Third-Party Backup and Restore Software

•To Do an Offline Backup of the Bridge Server

To Do an Online Backup of the Bridge Server by Using Third-Party Backup and Restore Software

Step 1 Back up the following files and directories:

•SN (include all files and subdirectories)

•Starfish\Db\StarFish.mdb

•VPIM\Vpim.cfg

•VPIM\Propagation (include all files and subdirectories)

Note The paths above are relative to the drive and directory in which the Bridge software is installed. The default is D:\Bridge.

For detailed instructions, refer to the manufacturer documentation or Help.

To Do an Offline Backup of the Bridge Server

Step 1 On the Bridge server, on the Windows Start menu, click Programs > Administrative Tools > Services, and stop the following services:

•Digital Networking

•Unity Bridge

Any calls that are in progress are allowed to finish before the services are stopped.

Step 2 Back up the following directories:

•SN (include all files and subdirectories)

•Starfish\Db\StarFish.mdb

•VPIM\Vpim.cfg

•VPIM\Propagation (include all files and subdirectories)

Note The paths above are relative to the drive and directory in which the Bridge software is installed. The default is D:\Bridge.

Step 3 On the Windows Start menu, click Programs > Administrative Tools > Services, and start the following services:

•Digital Networking

•Unity Bridge

Step 4 Close the Services window.

Replacing a Bridge Server and Restoring Data

When replacing a Bridge server, you install the Bridge software and then restore the configuration and data files.

To Replace a Bridge Server and Restore Data

We recommend that you replace the Bridge server during off-peak hours. Note that the paths below are relative to the drive and directory in which the Bridge software is installed. The default is D:\Bridge.

Step 1 Install the new Bridge server according to the instructions in the "Overview of Mandatory Tasks for Installing the Cisco Unity Bridge" chapter of Cisco Unity Bridge Installation Guide, Release 3.0. The guide is available at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/bridge30/big/dom/index.htm.

Step 2 After the post-installation restart of the new Bridge server, on the Windows Start menu, click Programs > Administrative Tools > Services, and stop the following services:

•Digital Networking

•Unity Bridge

Step 3 On the Cisco Unity server on which the Interop Gateway service is running, click Programs > Administrative Tools > Services, right-click CsDomInteropGty, and select Stop. Messages from Cisco Unity subscribers and from the Bridge will be held in the Interop Gateway mail file until you restart the service.

Step 4 If the old Bridge server has failed or is already offline, skip to Step 10. Otherwise, confirm that there are no more messages queued in the following directories on the Bridge server:

•VPIM\Xcode\Inbound

•VPIM\VM\In

•IN

Messages pass through these directories quickly, in the order listed, before reaching the analog queues.

Step 5 In the Bridge Administrator, click Queue Status to see if there are outgoing messages in the analog queues. Wait for all messages in the queues to be sent before proceeding. You can view call progress on the Line Status page to determine when the outbound calls have finished.

Step 6 On the Bridge server, on the Windows Start menu, click Programs > Administrative Tools > Services, right-click Unity Bridge, and select Stop. Any incoming calls that are in progress are allowed to finish before the service is stopped. When the Unity Bridge service has been stopped, the Bridge is unable to accept calls from the Octels.

Step 7 Confirm that there are no more messages queued in the following directories on the Bridge server:

•Starfish\Out

•Out

•VPIM\Xcode\Outbound

•VPIM\Internet\Out

Messages pass through these directories quickly, in the order listed, before being sent via SMTP to Domino.

Step 8 If you have a recent backup, skip to Step 9. Otherwise, back up the following directories:

•SN (include all files and subdirectories)

•Starfish\Db\StarFish.mdb

•VPIM\Vpim.cfg

•VPIM\Propagation (include all files and subdirectories)

Step 9 Shut down the old Bridge server.

Step 10 Restore the following directories from the backup medium to the new Bridge server:

•SN (include all files and subdirectories)

•Starfish\Db\StarFish.mdb

•VPIM\Vpim.cfg

•VPIM\Propagation (include all files and subdirectories)

Step 11 If the fully qualified domain name (FQDN) of the new Bridge server is the same as the old Bridge server, skip to Step 12. Otherwise, change the FQDN in the following places:

•In the Bridge delivery location(s) on the Cisco Unity bridgehead server.

If there are only a few delivery locations, use the Cisco Unity Administrator to change the FQDN on each delivery location.

If there are many delivery locations, modify the delivery locations by using the Cisco Unity Bulk Import wizard. Refer to the section "Modifying Existing Delivery Locations" in the Cisco Unity Bulk Import wizard Help for details on preparing a CSV file and running the wizard.

•If you are using host files for name resolution with the Bridge, change the FQDN in the host file on the applicable Domino or SMTP relay server.

•If you are using DNS for name resolution with the Bridge, change the FQDN in the MX and A records on the DNS server.

Step 12 On the Windows Start menu, click Programs > Administrative Tools > Services, and start the following services:

•Digital Networking

•Unity Bridge

Step 13 Close the Services window on the Bridge server.

Step 14 On the Cisco Unity server on which the Interop Gateway service is running, click Programs > Administrative Tools > Services, right-click CsDomInteropGty, and select Start.

Step 15 Close the Services window.

Changing the Interop Gateway Foreign Domain Name

The following task list provides an overview of how to change the name of the Foreign domain used by the Interop Gateway. We recommend that you change the Foreign domain name after normal business hours when message traffic is light, because messages to AMIS recipients may be sent back as undeliverable until the Foreign domain name has been changed in every place that it is stored.

1. On the Cisco Unity server on which the Interop Gateway service—CsDomInteropGty—is running, rerun the Interop Gateway Configuration wizard and change the Foreign domain name. This updates settings stored in SQL and in the registry. (The settings in SQL will replicate to all other Cisco Unity servers in your installation, but the registry change must be made on each Cisco Unity server, as described in the next step.)

2. If your installation consists of multiple Cisco Unity servers (either Digitally Networked servers and/or secondary failover servers), you must change the Foreign domain name stored in the registry. Open the Advanced Settings Tool in Tools Depot to change the Foreign Domain name in the setting Networking - Change Interop Gateway Foreign Domain Name (Domino Only).

3. Restart Cisco Unity.

4. In Domino Designer, copy the agent from the CommServer\Utilities\Domino\Agents\UpdateRemoteSubscribers directory of a Cisco Unity server, and paste it in names.nsf on a "hub" Domino server that pushes out directory changes.

5. In the Domino Administrator, run the agent to change the Foreign domain name in the Forwarding Address field of each Person document that corresponds to an AMIS, Bridge, or VPIM subscriber.

The following procedure provides detailed steps.

To Change the Interop Gateway Foreign Domain Name

Step 1 On the Cisco Unity server on which the Interop Gateway service—CsDomInteropGty—is running, browse to the directory in which Cisco Unity is installed (the default location is C:\CommServer).

Step 2 Double-click UnityDominoInterOpSetup.exe to run the Interop Gateway Configuration wizard.

Step 3 On the Welcome screen, click Next.

Step 4 On the Configure the Interop Gateway screen, click either Use a New Foreign Domain or Use an Existing Foreign Domain.

•If you choose to use a new Foreign domain, in the text box, enter the domain name that will be used to route AMIS messages to the Interop Gateway mail file. The Interop Gateway Configuration wizard creates a new Foreign domain document with the specified name.

•If you choose to use an existing Foreign domain, click the Foreign domain name on the list.

Step 5 Click Next to go to the Foreign Domain Mail Information screen. If you chose to use an existing Foreign domain, the mail file name and the Domino server on which the mail file resides are displayed. Verify the information, and skip to Step 6.

If you chose to create a new Foreign domain:

a. Click the down button for the Domino Server list and wait for the list to be populated with all of the Domino server names in your network. Choose the server on which the Interop Gateway mail file will be created. Although you can type in the server name, you must enter the server name by using the hierarchical naming format (for example "ServerName/Org").

b. In the Mail File Name field, enter the name of the mail file to be monitored by the Interop Gateway (for example, interop.nsf). The Interop Gateway Configuration wizard will create the mail file, so enter a file name that does not already exist.

Step 6 Click Next. Choose the Windows account that the Interop Gateway service will log on with. We recommend that you choose Local System. However, if you choose an existing Windows account, you will need to ensure that it has the same level of permissions as were set by the Permissions wizard during Cisco Unity setup for the directory and messaging services account.

Step 7 Click Next and review the summary information to verify that it is correct.

Step 8 Click Finish and the wizard configures and starts the Interop Gateway service on the Cisco Unity server. When the wizard finishes, a message box displays to let you know whether the configuration was successful.

Step 9 If your installation consists of only one Cisco Unity server, skip to Step 23.

Otherwise, log on to another Cisco Unity server (either a Digitally Networked server or a secondary failover server), and on the Cisco Unity server desktop, double-click the Cisco Unity Tools Depot icon.

Step 10 In the left pane of the Tools Depot window, expand Administration Tools, and double click Advanced Settings Tool.

Step 11 In the Unity Settings list, click Networking - Change Interop Gateway Foreign Domain Name (Domino Only).

Step 12 Enter the new Foreign domain name in the New Value field, and click Set.

Step 13 Restart Cisco Unity.

Step 14 Repeat Step 9 through Step 13 on each Cisco Unity server.

Step 15 Optionally, copy the contents of the CommServer\Utilities\Domino\Agents\UpdateRemoteSubscriber directory on the Cisco Unity server to the Domino server where you will run Domino Designer. If you can browse to the Cisco Unity server from Domino Designer to open the agent, you can skip this step. Note that the UpdateRemoteSubscriber directory contains the files:

•Agent code to update interop foreign domain.txt

•UUIsFA.nsf

The following steps describe how to copy and run the agent UUIsFa.nsf. If you are familiar with working with Domino agents, you may prefer to create a new agent by using the code in the .txt file instead. Also note that the following steps are specific to Domino R6.5. Adjust them as needed for other Domino versions. Refer to your Domino documentation for additional information.

Step 16 Open Domino Designer, and click Open an Existing Database.

Step 17 Browse to UUIsFA.nsf, and click Open.

Step 18 Click View > Go To > Agents.

Step 19 In the right pane, right-click the agent, and click Copy.

Step 20 Click File > Database > Open, and open names.nsf on a hub Domino server that pushes out directory changes.

Step 21 Click View > Go To > Agents.

Step 22 Click Edit > Paste to add the agent to names.nsf.

Step 23 In the right pane, double-click Update Unity Interop Subscriber Forwarding Address to open the agent.

Step 24 Click the Save icon, close the agent dialog box, close the agent window, and exit Domino Designer.

Step 25 Open the Domino Administrator, click File > Database > Open, and open names.nsf on the hub Domino server.

Step 26 Click Actions > Update Unity Interop Subscriber Forwarding Address to run the agent. (The agent may be located on the Actions > Other menu.)

Step 27 In the Old Foreign Domain dialog box, enter the old Foreign domain name and click OK.

Step 28 In the New Foreign Domain dialog box, enter the new Foreign domain name and click OK.

The agent searches the Person documents that corresponds to AMIS, Bridge, and VPIM subscribers looking for the old Foreign domain name in the Forwarding Address field. When it finds a match, the agent changes the domain name portion of the Forwarding Address field to the new Foreign domain name.

Moving the Interop Gateway Mail File

To move the Interop Gateway mail file to another Domino server:

1. Move the mail file.

2. Update the Foreign domain document with the new Domino server name.

3. Rerun the Interop Gateway Configuration wizard, and use the existing Foreign domain.

The following procedure provides detailed steps.

To Move the Interop Gateway Mail File

Step 1 In the Domino Administrator, click the Files tab.

Step 2 In the list in the right pane, right-click the Interop Gateway mail file, and click Move.

Step 3 In the Move Database dialog box, specify the destination Domino server, and click OK.

Step 4 Click the Configuration tab.

Step 5 In the left pane, expand Messaging > Domain.

Step 6 In the right pane, click the Foreign domain document used by the Interop Gateway, and click Edit Domain.

Step 7 In the Foreign domain document, click the Mail Information tab.

Step 8 In the Gateway Server Name field, enter the Domino server name where the Interop Gateway mail file was moved to.

Step 9 Click Save and Close.

Step 10 On the Cisco Unity server on which the Interop Gateway service is running, browse to the directory in which Cisco Unity is installed (the default location is C:\CommServer).

Step 11 Double-click UnityDominoInterOpSetup.exe to run the Interop Gateway Configuration wizard.

Step 12 On the Welcome screen, click Next.

Step 13 On the Configure the Interop Gateway screen, click Use an Existing Foreign Domain, and click Next.

Step 14 On the Domain screen, confirm that the new Domino server is listed in the Domino Server field, and click Next.

Step 15 On the Interop Gateway Log On Properties Screen, we recommend that you click Log On as Local System Account.

Step 16 Click Next to review the Foreign Domain settings, and then click Finish. When the wizard finishes, a message box displays to let you know whether the configuration was successful.

Moving the UOmni Mail File

For information on moving the UOmni mail file, refer to the "UOmni Mail File" section in the "Cisco Unity Data and Log Files" chapter in the Cisco Unity Maintenance Guide, available at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity40/maint/maint405/dom/index.htm.)

Monitoring Recommendations

Refer to the Unity and Bridge Monitoring Recommendations spreadsheet, available on http://www.ciscounitytools.com/Documents.htm. This Excel spreadsheet contains tabs that include events, performance monitor counters, and services that we recommend for monitoring Cisco Unity and Bridge deployments.

	Cisco Unity Bridge Networking Guide, Release 3.0 (With IBM Lotus Domino)
	Monitoring and Maintaining Bridge Networking
Cisco Unity Bridge Networking Guide, Release 3.0 (With IBM Lotus Domino) Index Preface About Bridge Networking Setting Up Cisco Unity and the Bridge for Networking Monitoring and Maintaining Bridge Networking Troubleshooting Bridge Networking Advanced Troubleshooting Topics Uninstalling Bridge Networking Components Reference: Bridge Settings on the Cisco Unity Server Reference: Settings on the Bridge Server Primary Location Settings Glossary	Download this chapter Monitoring and Maintaining Bridge Networking Download the complete book PDF Version of the Entire Book (PDF - 5 MB) Feedback Table Of Contents Monitoring and Maintaining Bridge Networking Controlling the Number of Ports Used for Outgoing Messages Determining Optimal Values for Queued Call Threshold and Max Ports Per Node Bridge Analog Network and Node Analyzer (BANANA) Getting Started Using the BANANA admin to Monitor Analog Activity Bridge Traffic Analyzer Backing Up and Restoring a Bridge Server Backing Up the Bridge Server Replacing a Bridge Server and Restoring Data Changing the Interop Gateway Foreign Domain Name Moving the Interop Gateway Mail File Moving the UOmni Mail File Monitoring Recommendations Monitoring and Maintaining Bridge Networking This chapter provides information on monitoring and maintaining Bridge Networking. See the following sections for more information: •Controlling the Number of Ports Used for Outgoing Messages •Bridge Analog Network and Node Analyzer (BANANA) •Bridge Traffic Analyzer •Backing Up and Restoring a Bridge Server •Changing the Interop Gateway Foreign Domain Name •Moving the Interop Gateway Mail File •Moving the UOmni Mail File •Monitoring Recommendations Controlling the Number of Ports Used for Outgoing Messages Outgoing messages from the Bridge to an Octel node are placed in queues. The Bridge maintains three queues for each node—one queue each for normal and urgent messages, and a third for administrative tasks. Queued messages are processed in first-in-first-out (FIFO) order. The Bridge can simultaneously use more than one port on the analog voice-fax card(s) in the Bridge server to send messages to a particular Octel node. For example, assume that there are several messages in the normal message queue for a specific node, and that the Bridge is using one port to transmit the messages. If an administrative or urgent message is then sent to that same node during the time that the normal message traffic is being transmitted, the Bridge will use another port to dial out to send the administrative or urgent message. Two parameters on the System Settings page in the Bridge Administrator allow you to control the number of ports used for outgoing messages to a specific node: Queued Call Threshold and Max Ports Per Node. These values are applied to the normal and urgent outgoing message queues for each node. (Note that these values are not applied to administrative queues. Only one port at a time will ever be used for administrative calls to a particular node). The value in Queued Call Threshold specifies the threshold number of messages that must be in the outgoing message queue of a specific node for an additional port to be used for message delivery. As the number of messages in the queue increases, an additional port is added when the number of messages in the queue reaches a multiple of this parameter. For example, if the value of Queued Call Threshold is set to 10 (the default value), one port will be used for message delivery if there are fewer than 10 messages in the queue. For 10-19 messages, two ports will be used. For 20-29 messages, three ports will be used, and so on. The total number of ports used is limited by the Max Ports Per Node parameter. Queued Call Threshold is also used to determine when to disconnect a port used for outgoing messages to a specific node. As the number of messages in the queue decreases, a port is disconnected when the number of messages in the queue is below the next lower multiple of this parameter. When only two ports are in use, as the number of messages in the queue drops below half of this parameter, the second port is disconnected. For example, if the value of the Queued Call Threshold is set to 10, three ports will be used for message delivery if there are 20-29 messages in the queue. As the number of messages in the queue decreases, the third port is not disconnected until the number of messages in the queue drops to 10 or fewer. When the number of messages drops to 5 or fewer messages, the second port is disconnected, so only one port is used to transmit the remaining messages. The Max Ports Per Node parameter allows you to specify the maximum number of ports that can be used simultaneously to deliver messages to a particular node. Again, this value is applied to each message queue. For example, if Max Ports Per Node is set to 4 (the default value), it is possible that 9 ports could be used simultaneously to send normal, urgent, and administrative messages to a specific node. In this example, up to 4 ports could be used for normal messages; up to 4 ports could be used for urgent messages; and 1 port would be used for administrative messages. (Outbound administrative calls to the same node are not placed simultaneously. Only one port at a time will ever be used for administrative calls to a particular node.) Determining Optimal Values for Queued Call Threshold and Max Ports Per Node The optimal values for Queued Call Threshold and Max Ports Per Node depend on the number of ports, the number of nodes, and on message traffic patterns. Start with the default values for these parameters, and use the Bridge Traffic Analyzer to observe message traffic patterns to see whether you need to adjust the settings. See the "Bridge Traffic Analyzer" section for more information. The default values should be appropriate for light message traffic because with light traffic, the thresholds for the parameters are never reached. The default values should also be sufficient for installations with medium traffic and a small to medium number of Octel nodes. However, installations with medium traffic and ten or more Octel nodes, or with high traffic, should carefully watch the reports generated by the Bridge Traffic Analyzer, and adjust the values for the parameters as necessary. If you decide to adjust the values for Queued Call Threshold and Max Ports Per Node, keep in mind that the Bridge ports are used for both outgoing messages to Octel nodes and incoming messages to the Bridge. If message traffic is heavy enough, it is possible to adjust the values such that all the ports will be used for outgoing messages, leaving no ports available for incoming messages. If this is a concern, you may want to designate one or more ports to be used only for incoming calls. The Line Status page in the Bridge Administrator allows you to specify whether each line is to be used for both incoming and outgoing calls or only for incoming calls. Bridge Analog Network and Node Analyzer (BANANA) BANANA is a stand-alone application that runs on the Bridge server. It is designed to assist with monitoring and troubleshooting analog communication between the Bridge and the Octel nodes in the analog network. It also provides detail and summary information of call activity. BANANA contains an administration application called the BANANA admin that allows you to control how BANANA: •Generates test calls to the Octel systems that are networked with the Bridge server. •Extracts information from the call traces on the Bridge server and presents different views of the data. •Monitors the call traces for error conditions, and logs warnings or errors to the Windows Event Viewer. With the BANANA admin, you can also install and configure the BANANA service to do the tasks listed above at configurable intervals. If you have already installed BANANA, skip to the "Getting Started Using the BANANA admin to Monitor Analog Activity" section. To Install BANANA Step 1 Disable virus scanning services and the Cisco Security Agent service, if applicable. Step 2 Insert the Cisco Unity Bridge compact disc in the CD-ROM drive, and browse to the BANANA directory. Step 3 Double-click setup.exe. Step 4 Click OK at the welcome screen. Step 5 If applicable, change the directory where BANANA will be installed. Step 6 Click the Installation button. Step 7 If applicable, change the program group where BANANA will appear. Step 8 Click Continue. Step 9 If a Version Conflict message box is displayed warning that a file being copied is not newer than the file on your system, click Yes to keep the existing file. Step 10 When the installation is done, click OK. Step 11 Enable virus-scanning and the Cisco Security Agent services, if applicable Note The most up-to-date version of BANANA is available at http://www.CiscoUnityTools.com. When you start BANANA, it checks the Cisco Unity Tools website to see if a newer version is available, and if so, prompts you about upgrading. Getting Started Using the BANANA admin to Monitor Analog Activity If the Bridge server sends and receives many messages, it is likely that when you view the call traces in BANANA admin, you will see some errors. Do not be alarmed; due to the nature of analog transmissions, some errors are to be expected. In order to send and receive messages between the Bridge and an Octel node, DTMF tones are exchanged in accordance with the Octel analog protocol. It is not uncommon for line noise to interfere with the transmission or reception of DTMF tones, particularly when the tones are transmitted over the PSTN. In an environment with Cisco CallManager and Cisco gateways, the circuit-switched calls are encoded and repackaged into IP packets. The transcoding must be precise. The DTMF duration and interdigit timing on the Cisco gateways or Cisco CallManager must be set to a value between 80 and 100 milliseconds. Incorrect settings will cause transmission problems. When you first set up Bridge Networking, we recommend that you use the BANANA admin to frequently monitor the analog activity (at least daily, though more frequently if necessary) to find and fix problems. By monitoring the analog activity, you will become familiar with the message traffic patterns and learn what ratio of errors is within a "normal" range. The following procedure will get you started using the BANANA admin. Refer to the BANANA Help file for details about how to do each task. To Get Started Using the BANANA admin Step 1 On the Windows Start menu on the Bridge server, click Programs > BANANA > BANANA admin. Step 2 If you have not already done so, configure the log and output folder locations. Step 3 Optionally, adjust the Hours of Data to Retain in Database setting. You may want to increase the setting if there is sufficient disk space on the Bridge server. Be careful if you decrease the setting from the default because only the most recent call data will be retained after the call data is subsequently processed, and you could lose data that you need for troubleshooting a problem. Step 4 Click Process Call Data. BANANA processes the call traces and then displays information about incoming and outgoing calls in the Calls grid. Calls that resulted in errors are displayed in the Errors grid. Step 5 Click View Node Totals to display the Totals per Octel Node dialog box. This view of the data is useful for identifying communication problems with a particular Octel node. For example, if the ratio of errors to calls for a particular Octel node is significantly higher than for the other nodes, you can investigate the problem further by doing the following sub-steps: a. Make note of the serial number of the Octel node with a high number of errors. b. Click the main BANANA admin window, and then click the octelserialnumber column header in the Calls grid to sort the calls by Octel serial number. c. In the Calls grid, click a row with the problematic serial number that has an exitcode other than OK. The corresponding record in the Errors grid is highlighted. This record provides specific details regarding the condition under which the call was terminated, including the state of the protocol that was in process, and the reason why the call could not be completed. d. Click View Call Detail for Selected Call. This view of the data displays the mailboxes that were involved in the call, which is useful if someone notifies you that they received an NDR, or if you are tracking down a directory update problem that was logged in the Windows Event Viewer. You can also use this view of the data to verify that the message (or other action) involved in the failed call was repeated later in a successful call. Step 6 Configure BANANA to monitor the call traces for error conditions, and to log warnings or errors to the Windows Event Viewer. As needed, you can adjust the notification settings. Bridge Traffic Analyzer The Bridge Traffic Analyzer is a report-generation utility that reads the call traces on the Bridge server, and generates a graph and a summary table that can be saved as a comma-separated value (CSV) file. The Bridge Traffic Analyzer is available for download at http://www.CiscoUnityTools.com. The Bridge Traffic Analyzer generates reports by using the data in the call traces in the \Starfish\Log directory on the Bridge server. The Call Log Retention parameter on the System Settings page in the Bridge Administrator allows you to specify the number of days of call history to retain. For more information about the Call Log Retention setting, see the "System Settings" section on page 8-1. In the reports, the direction of the queues is from the perspective of Cisco Unity: •The inbound queue contains messages from Octel nodes that the Bridge sends to Cisco Unity. Messages in the inbound queue are sent to Cisco Unity by using SMTP. Therefore, unless Cisco Unity or Domino is down, messages move very quickly through the inbound queue. •The outbound queue contains messages from Cisco Unity that the Bridge sends to the appropriate Octel nodes. Messages in the outbound queue are sent through the ports on the analog voice-fax card(s) on the Bridge server to the Octel nodes. Because the number of ports is a fixed resource, and because analog transmissions are slow in comparison to SMTP, it is possible that messages will back up in the outbound queue. The Bridge Traffic Analyzer provides the following reports: •Port Availability—Shows the availability of ports on the analog voice-fax card(s) on the Bridge server. You can choose to show how many ports were available to take calls from Octel nodes, how many ports were busy, or both. The summary CSV file presents a table with the maximum and minimum number of available ports for each hour during the day. •Message Queue Activity—Shows how many messages and how much data is passing through the inbound and outbound message queues on the Bridge server. You can choose to show the number of messages, the message queue size in megabytes, or both. The summary CSV file presents a table with the maximum number of messages in the inbound and outbound queues, and the maximum message size of the inbound and outbound queues for each hour during the day. •Message Latency—Shows the length of time that messages stayed in the outbound queue before being delivered to the Octel nodes. You can select a time range for the report (the default is 24 hours), and you can choose which Octel nodes to see in the report (by default, all nodes are shown). The Message Latency report shows only the outbound queue. Messages arrive quickly from Cisco Unity, but are delivered by analog lines to their target Octel node; therefore, it is possible for messages to back up in the queue waiting for an available port. •Node Message Traffic—Shows how many messages and how much data is passing between different Cisco Unity and Octel nodes. For example, you can use this report to determine which Octel nodes a specific Cisco Unity server is messaging with most heavily. You can select one or more Cisco Unity nodes, one or more Octel nodes, and a time range for the report. Refer to the Help file that comes with the Bridge Traffic Analyzer for more information about these reports. Backing Up and Restoring a Bridge Server This section explains how to backup data on the Bridge server, and how to restore that data to another Bridge server. See the following sections: •Backing Up the Bridge Server •Replacing a Bridge Server and Restoring Data Backing Up the Bridge Server Both offline and online backups are supported for the Cisco Unity Bridge server. When backing up the Bridge server, you need to back up only the configuration and data files; you do not need to back up the Bridge software because it is easy to reinstall the Bridge software on another server. The files that you back up on the Bridge server include: •WAV files of voice names for Octel and Unity node directory entries •A database that contains configuration data and information about Octel and Unity node directory entries •Configuration files For a list of backup and restore software supported for the Bridge server, refer to the "Supported Backup Software" section of Cisco Unity Bridge 3.0 System Requirements, and Supported Hardware and Software, available at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/bridge30/sysreq/30bsysrq.htm. No unique software agents are required. We recommend that you do the backup during off-peak hours. See the following procedures for step-by-step instructions: •To Do an Online Backup of the Bridge Server by Using Third-Party Backup and Restore Software •To Do an Offline Backup of the Bridge Server To Do an Online Backup of the Bridge Server by Using Third-Party Backup and Restore Software Step 1 Back up the following files and directories: •SN (include all files and subdirectories) •Starfish\Db\StarFish.mdb •VPIM\Vpim.cfg •VPIM\Propagation (include all files and subdirectories) Note The paths above are relative to the drive and directory in which the Bridge software is installed. The default is D:\Bridge. For detailed instructions, refer to the manufacturer documentation or Help. To Do an Offline Backup of the Bridge Server Step 1 On the Bridge server, on the Windows Start menu, click Programs > Administrative Tools > Services, and stop the following services: •Digital Networking •Unity Bridge Any calls that are in progress are allowed to finish before the services are stopped. Step 2 Back up the following directories: •SN (include all files and subdirectories) •Starfish\Db\StarFish.mdb •VPIM\Vpim.cfg •VPIM\Propagation (include all files and subdirectories) Note The paths above are relative to the drive and directory in which the Bridge software is installed. The default is D:\Bridge. Step 3 On the Windows Start menu, click Programs > Administrative Tools > Services, and start the following services: •Digital Networking •Unity Bridge Step 4 Close the Services window. Replacing a Bridge Server and Restoring Data When replacing a Bridge server, you install the Bridge software and then restore the configuration and data files. To Replace a Bridge Server and Restore Data We recommend that you replace the Bridge server during off-peak hours. Note that the paths below are relative to the drive and directory in which the Bridge software is installed. The default is D:\Bridge. Step 1 Install the new Bridge server according to the instructions in the "Overview of Mandatory Tasks for Installing the Cisco Unity Bridge" chapter of Cisco Unity Bridge Installation Guide, Release 3.0. The guide is available at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/bridge30/big/dom/index.htm. Step 2 After the post-installation restart of the new Bridge server, on the Windows Start menu, click Programs > Administrative Tools > Services, and stop the following services: •Digital Networking •Unity Bridge Step 3 On the Cisco Unity server on which the Interop Gateway service is running, click Programs > Administrative Tools > Services, right-click CsDomInteropGty, and select Stop. Messages from Cisco Unity subscribers and from the Bridge will be held in the Interop Gateway mail file until you restart the service. Step 4 If the old Bridge server has failed or is already offline, skip to Step 10. Otherwise, confirm that there are no more messages queued in the following directories on the Bridge server: •VPIM\Xcode\Inbound •VPIM\VM\In •IN Messages pass through these directories quickly, in the order listed, before reaching the analog queues. Step 5 In the Bridge Administrator, click Queue Status to see if there are outgoing messages in the analog queues. Wait for all messages in the queues to be sent before proceeding. You can view call progress on the Line Status page to determine when the outbound calls have finished. Step 6 On the Bridge server, on the Windows Start menu, click Programs > Administrative Tools > Services, right-click Unity Bridge, and select Stop. Any incoming calls that are in progress are allowed to finish before the service is stopped. When the Unity Bridge service has been stopped, the Bridge is unable to accept calls from the Octels. Step 7 Confirm that there are no more messages queued in the following directories on the Bridge server: •Starfish\Out •Out •VPIM\Xcode\Outbound •VPIM\Internet\Out Messages pass through these directories quickly, in the order listed, before being sent via SMTP to Domino. Step 8 If you have a recent backup, skip to Step 9. Otherwise, back up the following directories: •SN (include all files and subdirectories) •Starfish\Db\StarFish.mdb •VPIM\Vpim.cfg •VPIM\Propagation (include all files and subdirectories) Step 9 Shut down the old Bridge server. Step 10 Restore the following directories from the backup medium to the new Bridge server: •SN (include all files and subdirectories) •Starfish\Db\StarFish.mdb •VPIM\Vpim.cfg •VPIM\Propagation (include all files and subdirectories) Step 11 If the fully qualified domain name (FQDN) of the new Bridge server is the same as the old Bridge server, skip to Step 12. Otherwise, change the FQDN in the following places: •In the Bridge delivery location(s) on the Cisco Unity bridgehead server. If there are only a few delivery locations, use the Cisco Unity Administrator to change the FQDN on each delivery location. If there are many delivery locations, modify the delivery locations by using the Cisco Unity Bulk Import wizard. Refer to the section "Modifying Existing Delivery Locations" in the Cisco Unity Bulk Import wizard Help for details on preparing a CSV file and running the wizard. •If you are using host files for name resolution with the Bridge, change the FQDN in the host file on the applicable Domino or SMTP relay server. •If you are using DNS for name resolution with the Bridge, change the FQDN in the MX and A records on the DNS server. Step 12 On the Windows Start menu, click Programs > Administrative Tools > Services, and start the following services: •Digital Networking •Unity Bridge Step 13 Close the Services window on the Bridge server. Step 14 On the Cisco Unity server on which the Interop Gateway service is running, click Programs > Administrative Tools > Services, right-click CsDomInteropGty, and select Start. Step 15 Close the Services window. Changing the Interop Gateway Foreign Domain Name The following task list provides an overview of how to change the name of the Foreign domain used by the Interop Gateway. We recommend that you change the Foreign domain name after normal business hours when message traffic is light, because messages to AMIS recipients may be sent back as undeliverable until the Foreign domain name has been changed in every place that it is stored. 1. On the Cisco Unity server on which the Interop Gateway service—CsDomInteropGty—is running, rerun the Interop Gateway Configuration wizard and change the Foreign domain name. This updates settings stored in SQL and in the registry. (The settings in SQL will replicate to all other Cisco Unity servers in your installation, but the registry change must be made on each Cisco Unity server, as described in the next step.) 2. If your installation consists of multiple Cisco Unity servers (either Digitally Networked servers and/or secondary failover servers), you must change the Foreign domain name stored in the registry. Open the Advanced Settings Tool in Tools Depot to change the Foreign Domain name in the setting Networking - Change Interop Gateway Foreign Domain Name (Domino Only). 3. Restart Cisco Unity. 4. In Domino Designer, copy the agent from the CommServer\Utilities\Domino\Agents\UpdateRemoteSubscribers directory of a Cisco Unity server, and paste it in names.nsf on a "hub" Domino server that pushes out directory changes. 5. In the Domino Administrator, run the agent to change the Foreign domain name in the Forwarding Address field of each Person document that corresponds to an AMIS, Bridge, or VPIM subscriber. The following procedure provides detailed steps. To Change the Interop Gateway Foreign Domain Name Step 1 On the Cisco Unity server on which the Interop Gateway service—CsDomInteropGty—is running, browse to the directory in which Cisco Unity is installed (the default location is C:\CommServer). Step 2 Double-click UnityDominoInterOpSetup.exe to run the Interop Gateway Configuration wizard. Step 3 On the Welcome screen, click Next. Step 4 On the Configure the Interop Gateway screen, click either Use a New Foreign Domain or Use an Existing Foreign Domain. •If you choose to use a new Foreign domain, in the text box, enter the domain name that will be used to route AMIS messages to the Interop Gateway mail file. The Interop Gateway Configuration wizard creates a new Foreign domain document with the specified name. •If you choose to use an existing Foreign domain, click the Foreign domain name on the list. Step 5 Click Next to go to the Foreign Domain Mail Information screen. If you chose to use an existing Foreign domain, the mail file name and the Domino server on which the mail file resides are displayed. Verify the information, and skip to Step 6. If you chose to create a new Foreign domain: a. Click the down button for the Domino Server list and wait for the list to be populated with all of the Domino server names in your network. Choose the server on which the Interop Gateway mail file will be created. Although you can type in the server name, you must enter the server name by using the hierarchical naming format (for example "ServerName/Org"). b. In the Mail File Name field, enter the name of the mail file to be monitored by the Interop Gateway (for example, interop.nsf). The Interop Gateway Configuration wizard will create the mail file, so enter a file name that does not already exist. Step 6 Click Next. Choose the Windows account that the Interop Gateway service will log on with. We recommend that you choose Local System. However, if you choose an existing Windows account, you will need to ensure that it has the same level of permissions as were set by the Permissions wizard during Cisco Unity setup for the directory and messaging services account. Step 7 Click Next and review the summary information to verify that it is correct. Step 8 Click Finish and the wizard configures and starts the Interop Gateway service on the Cisco Unity server. When the wizard finishes, a message box displays to let you know whether the configuration was successful. Step 9 If your installation consists of only one Cisco Unity server, skip to Step 23. Otherwise, log on to another Cisco Unity server (either a Digitally Networked server or a secondary failover server), and on the Cisco Unity server desktop, double-click the Cisco Unity Tools Depot icon. Step 10 In the left pane of the Tools Depot window, expand Administration Tools, and double click Advanced Settings Tool. Step 11 In the Unity Settings list, click Networking - Change Interop Gateway Foreign Domain Name (Domino Only). Step 12 Enter the new Foreign domain name in the New Value field, and click Set. Step 13 Restart Cisco Unity. Step 14 Repeat Step 9 through Step 13 on each Cisco Unity server. Step 15 Optionally, copy the contents of the CommServer\Utilities\Domino\Agents\UpdateRemoteSubscriber directory on the Cisco Unity server to the Domino server where you will run Domino Designer. If you can browse to the Cisco Unity server from Domino Designer to open the agent, you can skip this step. Note that the UpdateRemoteSubscriber directory contains the files: •Agent code to update interop foreign domain.txt •UUIsFA.nsf The following steps describe how to copy and run the agent UUIsFa.nsf. If you are familiar with working with Domino agents, you may prefer to create a new agent by using the code in the .txt file instead. Also note that the following steps are specific to Domino R6.5. Adjust them as needed for other Domino versions. Refer to your Domino documentation for additional information. Step 16 Open Domino Designer, and click Open an Existing Database. Step 17 Browse to UUIsFA.nsf, and click Open. Step 18 Click View > Go To > Agents. Step 19 In the right pane, right-click the agent, and click Copy. Step 20 Click File > Database > Open, and open names.nsf on a hub Domino server that pushes out directory changes. Step 21 Click View > Go To > Agents. Step 22 Click Edit > Paste to add the agent to names.nsf. Step 23 In the right pane, double-click Update Unity Interop Subscriber Forwarding Address to open the agent. Step 24 Click the Save icon, close the agent dialog box, close the agent window, and exit Domino Designer. Step 25 Open the Domino Administrator, click File > Database > Open, and open names.nsf on the hub Domino server. Step 26 Click Actions > Update Unity Interop Subscriber Forwarding Address to run the agent. (The agent may be located on the Actions > Other menu.) Step 27 In the Old Foreign Domain dialog box, enter the old Foreign domain name and click OK. Step 28 In the New Foreign Domain dialog box, enter the new Foreign domain name and click OK. The agent searches the Person documents that corresponds to AMIS, Bridge, and VPIM subscribers looking for the old Foreign domain name in the Forwarding Address field. When it finds a match, the agent changes the domain name portion of the Forwarding Address field to the new Foreign domain name. Moving the Interop Gateway Mail File To move the Interop Gateway mail file to another Domino server: 1. Move the mail file. 2. Update the Foreign domain document with the new Domino server name. 3. Rerun the Interop Gateway Configuration wizard, and use the existing Foreign domain. The following procedure provides detailed steps. To Move the Interop Gateway Mail File Step 1 In the Domino Administrator, click the Files tab. Step 2 In the list in the right pane, right-click the Interop Gateway mail file, and click Move. Step 3 In the Move Database dialog box, specify the destination Domino server, and click OK. Step 4 Click the Configuration tab. Step 5 In the left pane, expand Messaging > Domain. Step 6 In the right pane, click the Foreign domain document used by the Interop Gateway, and click Edit Domain. Step 7 In the Foreign domain document, click the Mail Information tab. Step 8 In the Gateway Server Name field, enter the Domino server name where the Interop Gateway mail file was moved to. Step 9 Click Save and Close. Step 10 On the Cisco Unity server on which the Interop Gateway service is running, browse to the directory in which Cisco Unity is installed (the default location is C:\CommServer). Step 11 Double-click UnityDominoInterOpSetup.exe to run the Interop Gateway Configuration wizard. Step 12 On the Welcome screen, click Next. Step 13 On the Configure the Interop Gateway screen, click Use an Existing Foreign Domain, and click Next. Step 14 On the Domain screen, confirm that the new Domino server is listed in the Domino Server field, and click Next. Step 15 On the Interop Gateway Log On Properties Screen, we recommend that you click Log On as Local System Account. Step 16 Click Next to review the Foreign Domain settings, and then click Finish. When the wizard finishes, a message box displays to let you know whether the configuration was successful. Moving the UOmni Mail File For information on moving the UOmni mail file, refer to the "UOmni Mail File" section in the "Cisco Unity Data and Log Files" chapter in the Cisco Unity Maintenance Guide, available at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity40/maint/maint405/dom/index.htm.) Monitoring Recommendations Refer to the Unity and Bridge Monitoring Recommendations spreadsheet, available on http://www.ciscounitytools.com/Documents.htm. This Excel spreadsheet contains tabs that include events, performance monitor counters, and services that we recommend for monitoring Cisco Unity and Bridge deployments.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks