When you create an intersite link in Cisco Unity Connection Administration using the Link to Cisco Unity Site or Unity Connection Site by Manually Exchanging Configuration Files option, the site gateway on which you are creating the link reads the fully-qualified domain name (FQDN) for the remote site gateway from the configuration file that you upload, and attempts to resolve the FQDN using DNS.

If DNS is not configured on the Unity Connection site gateway, or the remote site gateway that you are linking to cannot be resolved via DNS, Connection Administration displays the error, “Unable to contact the remote site”. You may choose to go ahead and create a link to this site, but synchronization with this site does not begin until communication can be established without errors. Do you wish to continue?” (The use of DNS name resolution is optional with Unity Connection.)

When you see this error, do the following procedure to continue creating the link and to enable the synchronization tasks, which are automatically disabled when Unity Connection encounters this error condition.

When you create an intersite link in Cisco Unity Connection Administration using the Link to Cisco Unity Site or Unity Connection Site by Manually Exchanging Configuration Files option, the site gateway on which you are creating the link reads the fully-qualified domain name (FQDN) for the remote site gateway from the configuration file that you upload, and, if you check the Use Secure Sockets Layer (SSL) check box, verifies whether the FQDN matches the servername on the remote site gateway web SSL certificate (the certificate for browsing to the machine over HTTPS). If the values do not match, Connection Administration displays the error, "Hostname entered does not match that on the remote site certificate."

When you see this error, you can do the following procedure to repeat the link creation process and to circumvent the error by checking the Ignore Certificate Errors check box.

When you create an intersite link in Cisco Unity Connection Administration, the Unity Connection site gateway checks to see if the combined number of users and contacts on the gateway would exceed the actual limit after the link is created. It also checks if the combined number of system distribution lists on the gateway would exceed the system distribution list limit.

If the site gateway is unsuccessful at performing these checks, Connection Administration displays the error, "Unable to Link to the Specified Remote Site. Cause: Failed to Assess the Current Network Size." If you see this error, you can view the default traces for the Unity Connection Tomcat Application service (trace log filenames matching the pattern diag_Tomcat_*.uc) and search the file for the term "GetDirectoryCurrentSize." For detailed instructions on viewing the trace logs, see the Troubleshooting Cisco Unity Connection chapter.

For more information on the directory size limits, see the "Unity Connection Directory Size Limits" section in the "Overview of Networking " chapter of the Networking Guide for Cisco Unity ConnectionRelease 12.x, available at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/networking/guide/b_12xcucnetx.html

The error "Failed to link to this remote site as this specified location is already part of the network" is displayed when you attempt to create an intersite link in Connection Administration under any of the following conditions:

• You attempt to create an intersite link from a location to the location itself.

• You attempt to create an intersite link from one location to another location that is a member of the same Unity Connection site.

• You attempt to create an intersite link from a location on one site to a location on another site, and the sites are already linked.

If you see this error, check the hostname information or the configuration file that you are using to create the link. Verify that you are linking to the correct remote site gateway and that a link does not already exist between sites, then retry the linking process.

If Unity Connection users are unable to address messages to remote objects within a Unity Connection site or on a linked Unity Connection or Cisco Unity site, do the following tasks in the order presented:

1. Check for the presence of the remote object in Unity Connection on the location on which users are experiencing the problem. This indicates whether the remote object has been replicated. If the object is not found, see the “Troubleshooting Directory Synchronization” section on page 11-16 for further troubleshooting steps.

2. Check the partition and search space configuration. The remote object to which the message is being addressed must belong to a partition that is a member of the search space configured as the search scope for the user. See the “Checking the Partition and Search Space Configuration for Addressing to Remote Objects” section on page 11-11.

3. Turn on the CDE micro trace (level 12 CDL Access). For detailed instructions on enabling the traces and viewing the trace logs, see the Troubleshooting Cisco Unity Connection chapter.

If Cisco Unity users are unable to address messages to users on a Unity Connection site to which Cisco Unity is linked via an intersite link (also known as Unity Connection Networking), do the following tasks in the order presented:

1. Check for the presence of the Unity Connection user object as a Unity Connection Networking subscriber in the Cisco Unity Administrator. This indicates whether the Unity Connection user object has been replicated. If the object is not found, see the “Troubleshooting Directory Synchronization” section on page 11-16 for further troubleshooting steps.

2. If the problem involves addressing by extension, check to see if the Unity Connection user object has an extension in Cisco Unity, and if so, check whether the extension matches the format that Cisco Unity users are expecting. See the “Troubleshooting Unity Connection User Extension Creation in Cisco Unity” section on page 11-12.

Addressing to a particular recipient at a VPIM location can fail for one of the following reasons:

• Blind addressing is disabled for the VPIM location, and no VPIM contact exists for the recipient. If you are relying on automatic VPIM contact creation to populate VPIM contacts based on incoming messages, it is possible that contact creation is not set up properly for this location, or that no messages have been received from the remote user. Check the settings on the Contact Creation page for the VPIM location in Cisco Unity Connection Administration.

• A VPIM contact exists, but users are unable to locate it because the extension is incorrect or the contact name does not match user searches. Check the VPIM contact configuration in Connection Administration.

• Users are attempting to blind address to VPIM recipients, but the DTMF Access ID of the VPIM location is incorrect or does not match the pattern users are attempting to enter when addressing. Check the value of the DTMF Access ID setting on the Edit VPIM Location page in Connection Administration, and confirm that users are aware of the correct value.

• The user search scope does not include the partition of the VPIM contact or VPIM location. If the VPIM contact partition does not match the partition of the VPIM location to which the contact belongs, the search results depend on the method used to address the message as well as the partition and search space configuration. When users address messages to a VPIM mailbox by entering a VPIM location DTMF Access ID plus a remote user mailbox number, or when voice-recognition users say a name and location (for example, “John Smith in Seattle”), the action is allowed or denied based on the partition of the VPIM location. However, when users address to a VPIM contact using spell-by-name or by entering the local extension of the contact, or when voice-recognition users say the name of a contact without the location (for example, “John Smith”), the action is allowed or denied based on the partition of the VPIM contact, regardless of whether the partition of the VPIM location is out of scope for the user. In Connection Administration, on the Edit User Basics page for the user, check which search space is configured as the search scope. Then check which partition is configured for the VPIM contact (on the Edit Contact Basics page) or for the VPIM location (on the Edit VPIM Location page), as applicable. Finally, check the Edit Search Space page for the user search space to determine whether the partition appears in the Assigned Partitions list.

Blind addressing allows users to send messages to recipients at the VPIM location even if the recipients are not defined as contacts in the Unity Connection directory. If blind addressing is not working, confirm that you have enabled it for an individual VPIM location by checking the Allow Blind Addressing check box on the VPIM Location page in Cisco Unity Connection Administration. When this check box is checked for a location, users can address messages to recipients at this location by entering a number that is made up of the VPIM location DTMF Access ID and the mailbox number of the recipient, or by saying the digits of the mailbox number and the display name of the VPIM location (for example, “five five at Seattle office”).

In general, messages that are successfully addressed to a remote user using the phone interface should be delivered as long as SMTP connectivity is established between the locations. A notable exception occurs when a user replies to all recipients of a received message, and some of those recipients are not in the search scope of the replying user. In this case, the replying user receives a non-delivery receipt for any recipient who is not in the search scope.

Messages sent using an IMAP client to a remote user can fail if the profile information for the remote user (specifically, the SMTP proxy address information of the remote user) has not fully replicated to the Unity Connection location of the sending user. To diagnose and correct this condition, see the “Troubleshooting Directory Synchronization” section on page 11-16.

If the issue does not appear to be related to the partition and search space configuration or directory replication, you may be able to further diagnose the problem by turning on the Message Tracking Traces macro trace. For detailed instructions on enabling the traces and viewing the trace logs, see the Using Diagnostic Traces for Troubleshooting section.

In cases where you have recently added a location to a site or linked sites, it is possible for messages to be received from remote senders whose user object has not yet replicated to a location. If a user attempts to reply to a message that was sent by a sender whose user object has not yet replicated, the reply is not delivered, and the sender receives a non-delivery receipt (NDR). When this happens, the user who attempted the reply can resend the reply after the user object of the original message sender has replicated, and the reply is successfully delivered.

In order for incoming VPIM messages to be received and processed correctly, the following are required:

• SMTP connectivity must be available between the originating voice messaging system and Unity Connection.

• If messages from the originating voice messaging server are routed through a smart host that is different from the one that is configured on the System Settings > SMTP Configuration > Smart Host page in Cisco Unity Connection Administration, the IP address of this smart host must be added to the IP Address Access List as an allowed Unity Connection. (On the System Settings > SMTP Configuration > Server page, select Edit > Search IP Address Access List to view or modify the access list.)

• The domain name in the incoming message “From” field must match the Remote VPIM Domain Name value that is defined for the VPIM location in Connection Administration.

• If a Remote Phone Prefix value is defined for the VPIM location, the mailbox number in the incoming message “From” field must begin with the prefix digits.

• If a Cisco Unity Connection Phone Prefix is defined for the VPIM location, the mailbox number in the incoming message “To” field must begin with the prefix digits.

• The Unity Connection users receiving the message must be in a partition that is a member of the search space that is defined as the search scope of the VPIM location on the receiving server.

• If intersite networking is in use, the VPIM location must be configured on a Unity Connection location within the Unity Connection site on which the recipient is homed. VPIM locations and contacts are replicated within a site but are not replicated across intersite links, and site gateways do not relay VPIM messages to other sites.

You can verify SMTP connectivity and check the format of the “From” and “To” fields by turning on all levels of SMTP micro traces. (“MAIL FROM” and “RCPT TO” appear in the SMTP trace logs.) In addition, when you turn on all levels of MTA micro traces, the MTA log contains information about the processing of the message, including messages describing prefix processing errors. You can use the message ID listed at the end of the output file path name in the SMTP logs (for example, csUnitySmtp-30-1223425087697), to locate a message in the MTA log, or search by the recipient address (for example, 5551212@receiving-server-domain.com). For detailed instructions on enabling the traces and viewing the trace logs, see the Troubleshooting Cisco Unity Connection chapter.

In order for outgoing VPIM messages to be received and processed correctly, the following are required:

• SMTP connectivity must be available between Unity Connection and the receiving voice messaging system, either through direct TCP/IP connectivity to port 25, or through an SMTP smart host. (You can configure the SMTP smart host on the System Settings > SMTP Configuration > Smart Host page in Cisco Unity Connection Administration.)

• The audio attachment on the VPIM message must be in a format that is playable on the remote system. If the remote voice messaging system is not Unity Connection or Cisco Unity, you may need to configure the Outbound Messages setting for the VPIM location in Cisco Unity Connection Administration to use the G.726 codec to transcode the audio format.

As with incoming VPIM messages, when troubleshooting outgoing messages, we recommend that you start by turning on all MTA and SMTP micro traces. When examining the logs for outgoing message issues, start with the MTA log first, then review the SMTP log. For detailed instructions on enabling the traces and viewing the trace logs, see the Troubleshooting Cisco Unity Connection chapter.

Within a site, each location uses SMTP to exchange directory synchronization information and messages directly with every other location. Use the troubleshooting information in this section if you are experiencing difficulties with directory synchronization within a single Unity Connection site.

Replication between sites is accomplished by means of a Feeder service and a Reader service running on each site gateway. The Reader service periodically polls the remote site gateway for any directory changes since the last poll interval. The Feeder service checks the change tracking database for directory changes and responds to poll requests with the necessary information. The Feeder service is implemented as a web site that returns directory information in XML format when it receives a request from the remote Reader. Because directory information includes names and extensions, it is treated as confidential, and authentication is required to access the feed. We also recommend that you configure SSL on each site gateway in order to encrypt the directory information.

The synchronization that occurs after two sites are first joined can take anywhere from a few minutes to a few hours depending on the directory size. Later updates only synchronize changes since the last cycle, unless you manually request a full resynchronization.

On the Unity Connection site gateway, you can configure the schedule on which the Reader (also referred to as the FeedReader in Unity Connection) polls the remote Feeder for directory data, and the schedule on which it polls for recorded names. In Cisco Unity Connection Administration on the site gateway, you can access the schedules on the Tools  > Task Management page by selecting either the Synchronize Directory With Remote Network task or the Synchronize Voice Names With Remote Network task.

On the Cisco Unity site gateway, you can enable or disable synchronization of recorded names, and configure the interval at which the Reader polls the Unity Connection Feeder for directory updates and recorded names. In the Cisco Unity Administrator on the site gateway, you can access both settings (Synchronize Voice Names and Feeder Interval) on the Networking > Unity Connection Networking page. Note that unlike the Unity Connection Reader, which has separate configurable schedules for polling directory data and recorded names, the Cisco Unity Reader polls for both (if recorded name synchronization is enabled) during each cycle.

Table 11-3 lists the tools and details you can use to collect information about the operation of the Feeder and Reader applications for both Cisco Unity Connection and Cisco Unity.

If you want to manually start an incremental update of the directory on either site, you can do so using the Sync button on the Networking > Links > Intersite Links page in Cisco Unity Connection Administration on the Unity Connection site gateway or using the Sync Now button on the Network > Unity Connection Networking page in the Cisco Unity Administrator on the Cisco Unity site gateway. To initiate a full resynchronization of the entire directory, use the Resync All button on the Networking > Links > Intersite Links page in Cisco Unity Connection Administration on the Unity Connection site gateway or the Total Sync button on the Network > Unity Connection Networking page in the Cisco Unity Administrator on the Cisco Unity site gateway.

If a user attempts a cross-server sign-in and hears the opening greeting, the problem may be caused by one of the following:

• The originating location is not configured for cross-server sign-in hand-offs to the destination location. In Cisco Unity Connection Administration on the originating location, confirm that the Allow Cross-Server Sign-In to this Remote Location check box is checked on the Edit Unity Connection Location page for the destination location.

• The user is not found in the search scope on the originating location. Unity Connection uses the search scope of the call when it reaches the Attempt Sign-In conversation to identify which user is trying to sign in. In Cisco Unity Connection Administration on the originating location, check the direct call routing rules to determine which search space is set by the rule that sends calls to the Attempt Sign-In conversation. If the partitions that contain remote users are not a part of this search space, cross-server sign-in does not work, even if it is enabled.

When a cross-server sign-in hand-off fails to complete successfully, users hear a prompt indicating that their home server cannot be reached at this time. This may happen for one of the following reasons:

• The destination location is not configured to accept cross-server hand-offs. In Cisco Unity Connection Administration on the destination location, confirm that the Respond to Cross-Server Handoff Requests check box is checked on the System Settings > Advanced > Conversations page.

• The Cross-Server Dial String that is defined for the destination location on the originating location is incorrect, or the originating location is unable to place a call to this string using the phone system integration that is used to dial out. In Connection Administration on the originating location, check the Cross-Server Dial String value on the Edit Unity Connection Location page.

• No ports are available to dial out on the originating location or to answer the call on the destination location. You can use the Unity Connection Port Usage Analyzer to help determine if port usage is becoming a problem for cross-server transfers.

If a user attempts a cross-server sign-in and the call appears to be handed off correctly to the destination location but the user cannot sign in, the most likely cause is that the user is not found in the search scope on the destination location, or another user with an overlapping extension is found first in the search scope.

Unity Connection uses the search scope of the call when it reaches the Attempt Sign-In conversation to identify which user is trying to sign in, both on the originating and destination locations. In general, we recommend that the same search scope be used by the routing rules that handle cross-server sign-in on both the originating and destination locations. If necessary, you can add a routing rule on the destination location that specifically handles cross-server calls (for example, based on the calling number matching the extension of a port at the originating location).

To determine which search space is in use as the search scope during the call, turn on the CDE micro trace (level 4 Search Space). For detailed instructions on enabling the traces and viewing the trace logs, see the Troubleshooting Cisco Unity Connection chapter.

For information on configuring call routing rules and managing partitions and search spaces, see the “Dial Plan” section of the “Call Management” chapter of the System Administration Guide for Cisco Unity Connection Release 12.x, available at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/administration/guide/b_12xcucsag.html.

If a caller attempts a cross-server transfer and the call appears to be handed off correctly to the destination location but the caller reaches the wrong user at the destination, the most likely cause is that another user with an overlapping extension is found first in the search scope when the call is passed to the destination.

To determine which search space is in use as the search scope during the call, turn on the CDE micro trace (level 4 Search Space). For detailed instructions on enabling the traces and viewing the trace logs, see the Troubleshooting Cisco Unity Connection chapter.

If a caller attempts a cross-server transfer and the call appears to be handed off correctly to the destination location, but the caller hears a prompt indicating that the call cannot be completed and Unity Connection hangs up, the most likely cause is that the remote user is not found in the search scope when the call is passed to the destination.

To determine which search space is in use as the search scope during the call, turn on the CDE micro trace (level 4 Search Space). For detailed instructions on enabling the traces and viewing the trace logs, see the Troubleshooting Cisco Unity Connection chapter.