Networking Guide for Cisco Unity

Connection
Release 9.x
Published June 2013

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883

Text Part Number:

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public
domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this
URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1110R)
Networking Guide for Cisco Unity Connection Release 9.x
2013 Cisco Systems, Inc. All rights reserved.

CONTENTS
Preface

vii

Audience and Use

vii

Documentation Conventions

vii

Cisco Unity Connection Documentation viii

Documentation References to Cisco Unified Communications Manager Business Edition
Obtaining Documentation and Submitting a Service Request
Cisco Product Security Overview

CHAPTER

viii

viii

viii

Overview of Networking Concepts in Cisco Unity Connection 9.x

About Cisco Unity Connection 9.x Sites and Intrasite Links

1-1

1-1

About Cisco Voicemail Organizations and Intersite Links in Cisco Unity Connection 9.x
About Linking Two Cisco Unity Connection Sites 1-3
About Linking Cisco Unity Connection and Cisco Unity Sites 1-3
About VPIM Networking in Cisco Unity Connection 9.x

1-5

Directory Synchronization in Cisco Unity Connection 9.x 1-5

Replication Within a Cisco Unity Connection Site 1-5
Replication Between Two Cisco Unity Connection Sites 1-7
Replication Between Cisco Unity and Cisco Unity Connection Sites
Cisco Unity Connection 9.x Directory Size Limits

1-2

1-8

1-10

Messaging in Cisco Unity Connection 9.x 1-11

How Messages to System Distribution Lists Are Handled Within a Cisco Unity Connection Site
How Messages to System Distribution Lists Are Handled Between Sites 1-12
Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

1-12

Addressing and Dial Plan Considerations in Cisco Unity Connection 9.x 1-13
Addressing Options for Non-Networked Phone Systems 1-13
Identified User Messaging 1-14
Considerations for Intersite Networking Between Cisco Unity and Cisco Unity Connection
Migrating Users From Cisco Unity to Cisco Unity Connection 9.x

CHAPTER

1-14

1-17

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site 2-1
Prerequisites 2-1
Task List for Setting Up a Cisco Unity Connection Site

1-11

2-1

2-2

Book Title
78-xxxxx-xx

iii

Contents

Procedures for Setting Up a Cisco Unity Connection Site

2-3

Linking Two Cisco Unity Connection 9.x Sites 2-16

Prerequisites 2-17
Task List for Linking Cisco Unity Connection Sites 2-17
Procedures for Linking Cisco Unity Connection Sites 2-18
Notable Behavior in Networked Cisco Unity Connection 9.x Servers 2-24
Intersite Networking: No Results Are Found When a Directory Handler Search Scope is Set to a
Remote System Distribution List 2-24
Intersite Networking: Users May Receive Multiple Copies of a Message Sent to Multiple Distribution
Lists 2-25
Networked Broadcast Messages Are Not Supported 2-25
Networked Dispatch Messages Are Not Supported 2-25
Manual Resynchronization Runs Both Directory and Voice Name Synchronization Tasks 2-25
Replication with Cisco Unity Connection Clusters 2-25
Users Can Add Remote Users as Private Distribution List Members 2-25

CHAPTER

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers

3-1

Setting Up an Intersite Link Between Cisco Unity and Cisco Unity Connection 9.x Gateways 3-1
PrerequisitesCisco Unity 3-1
PrerequisitesCisco Unity Connection 3-2
Task List for Setting Up an Intersite Link Between Cisco Unity and Cisco Unity Connection
Gateways 3-2
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways 3-4
Making Deployment Decisions and Gathering Important Information 3-4
Determining the Cisco Unity Interoperability Domain Name 3-4
Preparing the Cisco Unity Gateway 3-5
Configuring a Previously Installed Interoperability Gateway for Cisco Unity Connection
Interoperability on Exchange 2010 or 2007 3-7
Configuring a Previously Installed Interoperability Gateway for Cisco Unity Connection
Interoperability on Exchange 2003 3-10
Configuring SMTP Access on the Cisco Unity Connection Gateway 3-11
Downloading the Cisco Unity Gateway Configuration File 3-12
Setting Up a Template for Cisco Unity Connection Users on the Cisco Unity Gateway 3-12
Creating the Intersite Link on the Cisco Unity Connection Gateway 3-13
Creating the Intersite Link on the Cisco Unity Gateway 3-15
Configuring Partitions and Search Spaces for Cisco Unity and Cisco Unity Connection
Interoperability 3-16
Configuring Individual System Distribution Lists for Synchronization 3-17
Extending Cisco Unity Identified Subscriber Messaging to Include Connection Networking
Subscribers 3-18

Book Title

iv

78-xxxxx-xx

Contents

Notable Behavior in Networking Cisco Unity and Cisco Unity Connection 9.x 3-19
Changes to Configuration Settings in the Cisco Unity Administrator Do Not Take Effect Immediately
on the Interoperability Gateway for Microsoft Exchange 3-19
Cisco Unity Connection Users Are Not Listed in the Directory in Exchange 2010 or 2007
Organizations 3-19
Differences in User Experience Between Cisco Unity and Cisco Unity Connection 9.x 3-20
Display of Cisco Unity User Address Information 3-20
Feature Support Limitations 3-20
Manual Resynchronization on the Cisco Unity Connection Site Gateway Runs Both Directory and
Voice Name Synchronization Tasks 3-21
No Results Are Found When a Cisco Unity Connection 9.x Directory Handler Search Scope is Set to a
Remote System Distribution List 3-21
Outbound SMTP Authentication 3-21
Users May Receive Multiple Copies of a Message Sent to Multiple Distribution Lists 3-21
ViewMail for Microsoft Outlook and Body Text in Voice Messages 3-21

CHAPTER

VPIM Networking in Cisco Unity Connection 9.x

4-1

Setting Up Cisco Unity Connection 9.x to Use VPIM Networking 4-1

Prerequisites 4-2
Task List: Setting Up Cisco Unity Connection to Use VPIM Networking

4-2

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking 4-3
Making Design Decisions and Gathering Needed Information 4-3
Determining the Domain Name 4-4
Resolving Names with IP Addresses 4-4
Verifying Connectivity with the Remote Voice Messaging System 4-5
Creating VPIM Locations 4-6
Customizing VPIM Locations 4-6
Creating VPIM Contacts 4-7
Customizing VPIM Contact Directory Update Settings 4-11
Adding Alternate Names for Each VPIM Location 4-14
Gathering Information About Cisco Unity Connection to Configure Another Voice Messaging System
for VPIM 4-15
Deleting VPIM Contacts in Cisco Unity Connection 9.x
Removing a VPIM Location in Cisco Unity Connection 9.x

4-15
4-15

VPIM Concepts in Cisco Unity Connection 9.x 4-16

VPIM Messages 4-16
VPIM Addresses 4-17
Message Addressing Options 4-18
Messaging Similarities and Limitations 4-18
Audio Format Considerations 4-18
Book Title
78-xxxxx-xx

Contents

CHAPTER

Making Changes to the Networking Configuration in Cisco Unity Connection 9.x

Removing a Location From a Cisco Unity Connection 9.x Site

Making Changes to a Cisco Unity Connection 9.x Site Gateway
Making Changes to a Cisco Unity Site Gateway

5-1

5-1
5-3

5-3

Removing an Intersite Link Between a Cisco Unity Connection 9.x Site and a Cisco Unity Site
Removing an Intersite Link Between Two Cisco Unity Connection 9.x Sites

CHAPTER

5-6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

5-4

6-1

Overview of Cross-Server Sign-In, Transfer, and Live Reply in Cisco Unity Connection 9.x 6-1
Search Space Considerations for Cross-Server Sign-In, Transfers, and Live Reply 6-2
Cross-Server Sign-In in Cisco Unity Connection 9.x 6-3
Prerequisites: Enabling Cross-Server Sign-In 6-4
Task List: Enabling Cross-Server Sign-In 6-4
Procedures: Enabling Cross-Server Sign-In 6-5
Cross-Server Transfers in Cisco Unity Connection 9.x 6-9
Prerequisites: Enabling Cross-Server Transfers 6-9
Task List: Enabling Cross-Server Transfers 6-10
Procedures: Enabling Cross-Server Transfers 6-11
Cross-Server Live Reply in Cisco Unity Connection 9.x 6-15
Prerequisites: Enabling Cross-Server Live Reply 6-16
Task List: Enabling Cross-Server Live Reply 6-16
Procedures: Enabling Cross-Server Live Reply 6-17
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x 6-22
Cross-Server Sign-In Does Not Provide User Workstation Client Sign-In Access 6-22
Users Are Always Prompted for a Password During Cross-Server Sign-In Between Cisco Unity
Connection and Cisco Unity 6-22
Factors That Can Cause Delays During Cross-Server Handoff 6-22
Increased Port Usage with Cross-Server Features 6-23
Transfer Overrides on Cross-Server Transfers 6-23
Using Cross-Server Features with the Display Original Calling Number on Transfer Parameter 6-24
INDEX

Book Title

vi

78-xxxxx-xx

Preface
Audience and Use
The Networking Guide for Cisco Unity Connection is intended for system administrators and others
responsible for setting up and managing networking in Cisco Unity Connection. If you are setting up
Connection to communicate with other voice messaging systems, you also need a working knowledge
of those voice messaging systems.

Documentation Conventions
Table 1

Conventions in the Networking Guide for Cisco Unity Connection Release 9.x

Convention

Description

boldfaced text

Boldfaced text is used for:

<>
(angle brackets)
(hyphen)
>
(right angle bracket)

Key and button names. (Example: Select OK.)

Information that you enter. (Example: Enter Administrator

in the User Name box.)

Angle brackets are used around parameters for which you supply
a value. (Example: In your browser, go to https://<Cisco Unity
Connection server IP address>/cuadmin.)
Hyphens separate keys that must be pressed simultaneously.
(Example: Press Ctrl-Alt-Delete.)
A right angle bracket is used to separate selections that you make
in the navigation bar of Cisco Unity Connection Administration.
(Example: In Cisco Unity Connection Administration, expand
Contacts > System Contacts.)

The Networking Guide for Cisco Unity Connection Release 9.x also uses the following conventions:

Note

Means reader take note. Notes contain helpful suggestions or references to material not covered in the
document.

Networking Guide for Cisco Unity Connection Release 9.x

vii

Preface

Caution

Means reader be careful. In this situation, you might do something that could result in equipment damage
or loss of data.

Cisco Unity Connection Documentation

For descriptions and URLs of Cisco Unity Connection documentation on Cisco.com, see the
Documentation Guide for Cisco Unity Connection. The document is shipped with Connection and is
available at http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/roadmap/9xcucdg.html.

Documentation References to Cisco Unified Communications Manager

Business Edition
The name of the product known as Cisco Unified Communications Manager Business Edition in
versions 9.0 and earlier has been changed to Cisco Unified Communications Manager Business Edition
5000 in versions 9.0.
In the Cisco Unity Connection 9.x documentation set, references to Cisco Unified Communications
Manager Business Edition and Cisco Unified CMBE apply to both Business Edition version 9.0 and
to Business Edition 5000 versions 9.0. The references do not apply to Business Edition 6000.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional
information, see the monthly Whats New in Cisco Product Documentation, which also lists all new and
revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the Whats New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed
and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free
service and Cisco currently supports RSS Version 2.0.

Cisco Product Security Overview

This product contains cryptographic features and is subject to United States and local country laws
governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption. Importers, exporters, distributors
and users are responsible for compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local
laws, return this product immediately.
Further information regarding U.S. export regulations can be found at
http://www.access.gpo.gov/bis/ear/ear_data.html.

Networking Guide for Cisco Unity Connection Release 9.x

viii

CH A P T E R

Overview of Networking Concepts in Cisco Unity

Connection 9.x
Each Cisco Unity Connection server (or cluster) has a maximum number of users that it can serve. When
the messaging needs of your organization require more than one Connection server or cluster, or you
need a way to combine multiple Connection directories or to internetwork Connection with Cisco Unity,
you can link Connection servers or clusters together to form sites, and link a Connection site with
another Connection site or with a Cisco Unity site to form a Cisco Voicemail Organization.
See the following sections:

Note

About Cisco Unity Connection 9.x Sites and Intrasite Links, page 1-1

About Cisco Voicemail Organizations and Intersite Links in Cisco Unity Connection 9.x, page 1-2

About VPIM Networking in Cisco Unity Connection 9.x, page 1-5

Directory Synchronization in Cisco Unity Connection 9.x, page 1-5

Cisco Unity Connection 9.x Directory Size Limits, page 1-10

Messaging in Cisco Unity Connection 9.x, page 1-11

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x, page 1-12

Addressing and Dial Plan Considerations in Cisco Unity Connection 9.x, page 1-13

Migrating Users From Cisco Unity to Cisco Unity Connection 9.x, page 1-17

The information in this chapter is not applicable to use with Cisco Unified Communications Manager
Business Edition (CMBE). In a Cisco Unified CMBE configuration, the only supported networking
option is VPIM Networking. See the VPIM Networking in Cisco Unity Connection 9.x chapter.

About Cisco Unity Connection 9.x Sites and Intrasite Links

You can join two or more Connection servers or clusters (up to a maximum of ten) to form a
well-connected network, referred to as a Connection site. The servers that are joined to the site are
referred to as locations. (When a Connection cluster is configured, the cluster counts as one location in
the site.) Within a site, each location uses SMTP to exchange directory synchronization information and
messages directly with every other location. Each location is said to be linked to every other location in
the site via an intrasite link. Figure 1-1 illustrates a site of five Connection locations joined by intrasite
links.

Networking Guide for Cisco Unity Connection Release 9.x

1-1

Chapter 1
About Cisco Voicemail Organizations and Intersite Links in Cisco Unity Connection 9.x

Figure 1-1

Overview of Networking Concepts in Cisco Unity Connection 9.x

A Cisco Unity Connection Site Joined by Intrasite Links Among All Locations

Cisco Unity
Connection

Cluster
(active/active pair)

Cisco Unity
Cisco Unity
Connection
Connection
Cisco Unity

251167

Cluster
(active/active pair)

The Connection site concept was known as a Digital Network in release 7.x. You can join 7.x locations
and 8.x locations in the same Connection site (intrasite links), as long as you do not link the site to any
other site (intersite links require that each Connection location be at release 9.x).
Each Cisco Unity Connection server (or cluster) is represented in the site as a single Connection
location, which is created locally during installation and which cannot be deleted from the server itself.
When you join the server (or cluster) to an existing location in a site, a Connection location is
automatically created for the server (or cluster) on all other locations in the site, and these locations
begin to perform directory synchronization with the new location. A Connection location can only
belong to a single site.

About Cisco Voicemail Organizations and Intersite Links in

Cisco Unity Connection 9.x
You can use an intersite link to connect one Cisco Unity Connection site to another Connection site,
allowing you to scale your organization from a maximum of ten locations to a maximum of twenty. Or,
you can use an intersite link to connect an 9.x Connection server or site to a Cisco Unity server or
Cisco Unity Digital Network. The linked sites are referred to as a Cisco Voicemail Organization.
To create an intersite link, you select a single location from each site to act as a gateway to the other site.
All directory synchronization communications pass between the two site gateways, thereby limiting the
connectivity requirements and bandwidth usage to the link between those two site gateway locations.
Only one intersite link is supported per site. So, you can link a single Connection site to a single
Cisco Unity site, or a single Connection site to another Connection site.
See the following sections for additional details:

About Linking Two Cisco Unity Connection Sites, page 1-3

About Linking Cisco Unity Connection and Cisco Unity Sites, page 1-3

Networking Guide for Cisco Unity Connection Release 9.x

1-2

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

About Cisco Voicemail Organizations and Intersite Links in Cisco Unity Connection 9.x

About Linking Two Cisco Unity Connection Sites

When you link two Cisco Unity Connection sites with an intersite link, the gateway for each site is
responsible for collecting information about all changes to the local site directory, and for polling the
remote site gateway periodically to obtain information about updates to the remote site directory. The
gateways use the HTTP or HTTPS protocol to exchange directory synchronization updates.
Each site gateway is also responsible for transmitting messages that are addressed to recipients at the
remote site and for receiving messages that are addressed to recipients in its own site. Intersite messages
are transmitted and received via SMTP.
When you use a Connection cluster as a site gateway, only the publisher server in the cluster participates
in directory synchronization over the intersite link. However, the subscriber server continues to provide
message exchange over the intersite link if the publisher server is down.
Figure 1-2 illustrates the role of the site gateways and the intersite link in connecting two Connection
sites.
Note that in order to link two Connection sites, all servers in each site must be running Cisco Unity
Connection release 9.x.
Figure 1-2

A Cisco Voicemail Organization Consisting of Two Cisco Unity Connection Sites Connected via an Intersite
Link
Cisco Unity Connection Site

Cisco Unity Connection Site

Directory Exchange-HTTP(S)
Firewall

Firewall

Internet
SMTP
Cisco Unity
infrastructure
Connection
Site Gateway

or
Intranet

Message Exchange-SMTP

SMTP
Cisco Unity
infrastructure Connection
Site Gateway
Cisco Unity
Connection
Location

Path of directory
synchronizations
Path of voice messages

277991

Cisco Unity
Connection
Location

About Linking Cisco Unity Connection and Cisco Unity Sites

When you link a Cisco Unity site to a Cisco Unity Connection site, the gateway for each site is
responsible for collecting information about all changes to the local site directory, and for polling the
remote site gateway periodically to obtain information about updates to the remote site directory. The
gateways use the HTTP or HTTPS protocol to exchange directory synchronization updates.
For message exchange, the Interoperability Gateway for Microsoft Exchange functions as the messaging
gateway for the Cisco Unity site. The Interoperability Gateway can be installed on a Microsoft Exchange
2010 or Exchange 2007 server configured with the Hub Transport role, or on a Microsoft Exchange 2003
server. (For up-to-date version support and requirements for the Interoperability Gateway, see the
Cisco Unity Networking Options Requirements at
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html.)

Networking Guide for Cisco Unity Connection Release 9.x

1-3

Chapter 1
About Cisco Voicemail Organizations and Intersite Links in Cisco Unity Connection 9.x

Overview of Networking Concepts in Cisco Unity Connection 9.x

Messages composed by Cisco Unity users that include external recipients are routed by the mail system
to a folder that the Interoperability Gateway periodically checks. The Interoperability Gateway picks up
a message to be processed from the folder, looks up and translates the sender and recipient information
into the required format, adds or removes message properties as applicable, converts and encrypts or
decrypts the audio if applicable for the destination location, performs message part and format
conversion, and hands the message back to the messaging system for delivery. For several of these tasks,
the Interoperability Gateway needs access to Cisco Unity directory information. To get this information,
it contacts the Cisco Unity web services resource on a Cisco Unity 8.x server in the Cisco Unity site.
(The Interoperability Gateway can be configured to use both a primary and secondary web services
server. The site gateway can be used as the web services server, although any 8.x server in the site can
be used.)
Figure 1-3 depictsat a high levelthe role of the Interoperability Gateway for Microsoft Exchange,
the site gateways, and the intersite link in connecting Cisco Unity and Cisco Unity Connection sites. The
Cisco Unity site can consist of a single Cisco Unity server, a failover pair, or a Digital Network
containing multiple Cisco Unity servers or failover pairs. Likewise, the Connection site can consist of a
single Connection server, a Connection cluster, or more than one server or cluster.
Figure 1-3

Cisco Voicemail Organization Consisting of a Cisco Unity Site Connected to a Cisco Unity Connection Site
via an Intersite Link
Cisco Unity Site
(Digital Network)
Cisco Unity Connection Site

Directory Exchange-HTTP(S)
Firewall

Cisco Unity
Site
Gateway

Firewall

Corporate
Directory
(Active
Directory)

Internet
or

Interoperability
Cisco Unity
Gateway/
Location
Microsoft Exchange

Path of directory
synchronizations
Path of voice messages

277992

Cisco Unity
Connection
Location

SMTP
SMTP
Cisco
Intranet
infrastructure
infrastructure
Unity
Connection
Message Exchange -SMTP
Site Gateway

Note that in order to link Cisco Unity and Cisco Unity Connection sites, all servers in the Connection
site must be running Connection 9.x. The Cisco Unity site gateway must be running Cisco Unity 8.x.
Other Cisco Unity servers in the Cisco Unity site may be running Cisco Unity 5.0 and later with
Microsoft Exchange provided that the applicable engineering special is installed to add Connection
Networking support. For additional details and requirements, see the Cisco Unity Networking Options
Requirements at
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html.)
When you use a Connection cluster as the Connection site gateway, only the publisher server in the
cluster participates in directory synchronization with Cisco Unity. However, the subscriber server can
continue to provide message exchange over the intersite link if the publisher server is down. Likewise,

Networking Guide for Cisco Unity Connection Release 9.x

1-4

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

About VPIM Networking in Cisco Unity Connection 9.x

when you use a Cisco Unity failover pair as the Cisco Unity site gateway, only the primary Cisco Unity
server participates in directory synchronization with Connection, although message exchange can
continue even when the secondary Cisco Unity server is active.

About VPIM Networking in Cisco Unity Connection 9.x

Cisco Unity Connection 9.x supports the Voice Profile for Internet Mail (VPIM) protocol, which is an
industry standard that allows different voice messaging systems to exchange voice and text messages
over the Internet or any TCP/IP network. VPIM is based on the Simple Mail Transfer Protocol (SMTP)
and the Multi-Purpose Internet Mail Extension (MIME) protocol.
VPIM Networking is supported for use with Cisco Unified Communications Manager Business
Edition (CMBE).
Connection 9.x supports up to 10 VPIM locations and 100,000 VPIM contacts in the Connection
directory. These same limits apply either to the directory of a single Connection server or cluster pair,
or to the global directory in a site.
If you deploy VPIM in a Connection networking site, we recommend that you designate a single
Connection location in the site as the bridgehead to handle the configuration of VPIM locations and
contacts. The VPIM location data and all contacts at the VPIM location (including automatically created
contacts) are replicated from the bridgehead to other locations within the site. When a VPIM message is
sent by a user who is homed on a Connection location other than the bridgehead, the message first passes
to the bridgehead, which handles forwarding the message to the destination server. Likewise, messages
from VPIM contacts are received by the bridgehead and relayed to the home server of the Connection
recipient.
If you deploy VPIM in a Cisco Voicemail Organization, you must independently configure each site for
VPIM. VPIM locations and contacts are not replicated across intersite links, and site gateways do not
relay VPIM messages to other sites.
For detailed information about VPIM networking, see the VPIM Networking in Cisco Unity
Connection 9.x chapter.

Directory Synchronization in Cisco Unity Connection 9.x

Each location in a Cisco Unity Connection site or Cisco Voicemail Organization has its own directory
of users and other objects that were created on the location and are said to be homed on that location.
The collection of objects and object properties that are replicated among locations and sites is referred
to as the global directory.
See the following sections for details on the specific objects and object properties that are replicated
during directory synchronization:

Replication Within a Cisco Unity Connection Site, page 1-5

Replication Between Two Cisco Unity Connection Sites, page 1-7

Replication Between Cisco Unity and Cisco Unity Connection Sites, page 1-8

Replication Within a Cisco Unity Connection Site

Within a Cisco Unity Connection site, each location replicates the objects and object properties shown
in Table 1-1 from its directory to every other location:

Networking Guide for Cisco Unity Connection Release 9.x

1-5

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Directory Synchronization in Cisco Unity Connection 9.x

Table 1-1

Replicated Objects in a Cisco Unity Connection Site

Replicated Object
Users with mailboxes

Replicated Properties

Alias

First name, last name, display name, alternate names

Extension, cross-server transfer extension, and alternate

extensions

Directory listing status

Partition

Recorded name

SMTP address and SMTP proxy addresses

System contacts

All properties

System distribution lists

All properties, including list membership

Partitions

All properties

Search spaces

All properties, including membership

Connection location

VPIM location

Display name

Host address

SMTP domain name

Connection version

All properties except Contact Creation settings (contact creation is

handled on the Connection location that homes the VPIM location)

In most cases, you can use replicated objects just as you would use local objects; for example, you can
assign a remote user to be the message recipient of a system call handler, or configure the search scope
of a user to use a remote search space. Note the following exceptions:

System call handler owners must be local users.

Objects that belong to a partition (users, contacts, handlers, system distribution lists, and VPIM
locations) can only belong to local partitions. You can, however, add a remote partition to a local
search space.

When a replicated object that is homed on a Connection location is added, modified or deleted, the
location sends an object change request containing details about the change to all other locations. The
object change requests for a given location are ordered and tracked with a number known as the Unique
Sequence Number (USN). For each change, the location increments the USN by one, and notes the
change in its database. When a remote location receives an object change request with a USN value that
is one higher than the previous request it received from the sender, it updates its copy of the Connection
directory accordingly, and increments its tracked copy of the USN for the sender. If a remote location
misses one or more changes and receives a change request with a USN that is more than one higher than
the previous request it received from this location, it can retrieve the missed changes by requesting the
USN values that it missed.
In addition to the USN, each location has another associated number known as the Replication Set. The
Replication Set value is used to track the set of changes to which a USN belongs. The Replication Set
value is automatically changed during an upgrade, restore, or rollback operation. This ensures that any
changes to the database as a result of the operation are replicated to the network. For example, if
Location A receives a message with replication set 10 and USN 5 from Location B, and then receives a

Networking Guide for Cisco Unity Connection Release 9.x

1-6

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Directory Synchronization in Cisco Unity Connection 9.x

message with replication set 9 and USN 5 from Location B, it knows to ignore the message with
replication set 9 because it is a lower number and the message predates the message with replication set
10. If Location A receives another message from Location B with replication set 10 and USN 5 again,
Location A knows this is a duplicate message and can ignore it.
When a bulk operation is in progress on a location, replication is paused on that location until the
operation completes.

Replication Between Two Cisco Unity Connection Sites

As shown in Table 1-2, the same objects and object properties are replicated between two Cisco Unity
Connection sites as within a single Connection site, with the following exceptions:

System contacts are not replicated between sites.

For each site, you can choose whether to synchronize all system distribution lists that are homed on
the remote site. Also, for each individual list, you can choose whether the list is offered for
replication to the remote site.

System distribution list membership is not replicated between sites.

VPIM locations (and contacts) are not replicated between sites.

Table 1-2

Objects That Are Replicated from One Cisco Unity Connection Site to Another

Replicated Object

Replicated Properties

Users with mailboxes

System distribution lists

Alias

First name, last name, display name, alternate names

Extension, cross-server transfer extension, and alternate

extensions

Directory listing status

Partition

Recorded name1

SMTP address and SMTP proxy addresses

Alias

Display name

Extension

Partition

Recorded name1

Partitions

All properties

Search spaces

All properties

Connection locations

Display name

Host address

SMTP domain name

Connection version

1. For each site, you can choose whether to synchronize recorded names for remote site objects.

Networking Guide for Cisco Unity Connection Release 9.x

1-7

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Directory Synchronization in Cisco Unity Connection 9.x

2. A local site system distribution list is only synchronized by the remote site if the Include Distribution Lists When
Synchronizing Directory Data check box is checked for the intersite link on the remote site gateway, and the Replicate to
Remote Sites Over Intersite Links check box is checked for the list.

Just as with intrasite links, you can use replicated objects from a remote site just as you would use local
objects, except that call handler owners must be local users, and objects that belong to a partition can
only belong to local partitions.
Intersite replication 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.
On each site gateway, you can configure the schedule on which the Reader polls the remote Feeder for
directory data, and the schedule on which it polls for recorded names. In Cisco Unity Connection
Administration on a 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. Alternatively, you can access either task by using the Related Links
field on the Edit Intersite Link page.
When the Synchronize Voice Names With Remote Network task is enabled, the Reader will process
recorded name files for remote users and system distribution lists (if applicable). Once a recorded name
is created for a remote object on the local site, it is updated only if the remote and local filenames for
the recorded name differ. If, for example, you change the outgoing codec for recorded names on the
remote site gateway, the local site will not update its files because the change does not affect filenames.
In order to pull updated copies of recorded names in this case, you must clear all existing recorded names
from the local site gateway and then do a full resynchronization by using the Clear Recorded Names
button and the Resync All button on the Search Intersite Links page in Connection Administration.

Replication Between Cisco Unity and Cisco Unity Connection Sites

When you link a Cisco Unity site and a Cisco Unity Connection site, a contact (known as a Connection
Networking subscriber in the Cisco Unity Administrator) is added to the Cisco Unity directory and to
Active Directory for each Connection user. Likewise, a user (known as a Cisco Unity user in Cisco Unity
Connection Administration) is added to the Connection site global directory for each Cisco Unity user.
Connection system contacts and VPIM contacts are not replicated to Cisco Unity, nor are Cisco Unity
networking contacts (AMIS, Bridge, VPIM, Internet, or Trusted Internet subscribers) replicated to
Connection.
A system distribution list may be replicated from one site to another if the local site is configured to pull
lists from the remote site, and if the list itself is configured to allow replication to other sites. Lists that
contain system contacts or networking contacts cannot be configured to allow replication to other sites.
For those lists that are replicated, only the list name and other information used in addressing are
replicated; list membership is not replicated.
Table 1-3 lists the objects that are replicated between Cisco Unity and Cisco Unity Connection sites, and
the object properties that are replicated.

Networking Guide for Cisco Unity Connection Release 9.x

1-8

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Directory Synchronization in Cisco Unity Connection 9.x

Table 1-3

Objects That Are Replicated Between Cisco Unity and Cisco Unity Connection Sites

Replicated Object
Cisco Unity Connection
users with mailboxes

Cisco Unity users

System distribution lists3

Locations

Replicated Properties

Alias

First name, last name, display name, alternate names

Extension, cross-server transfer extension, and alternate extensions1

Directory listing status

Recorded name2

SMTP address and SMTP proxy addresses

Alias

First name, last name, display name, alternate names

Extension, transfer extension, and alternate extensions

Directory listing status

Recorded name2

Alias

Display name

Extension1

Recorded name2

Display name

Host address

SMTP domain name

1. Connection extensions are replicated to Cisco Unity only if they do not conflict with existing objects in the dialing domain
as defined on the Cisco Unity site gateway.
2. For each site, you can choose whether to synchronize recorded names for remote site objects.
3. A system distribution list is only synchronized from another site if the intersite link is configured to allow synchronization
of remote lists, and the list itself is configured to allow replication to other sites.

Intersite replication 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.
On the Connection site gateway, you can configure the schedule on which the Reader polls the remote
Feeder for directory data, and the schedule on which it polls for recorded names. In Cisco Unity
Connection Administration on a 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. Alternatively, you can access either task by using
the Related Links field on the Edit Intersite Link page.
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 Cisco Unity Connection Feeder for directory updates
and recorded names. Note that unlike the 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.

Networking Guide for Cisco Unity Connection Release 9.x

1-9

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Cisco Unity Connection 9.x Directory Size Limits

When the Synchronize Voice Names With Remote Network task is enabled, the Reader will process
recorded name files for remote users and system distribution lists (if applicable). When a recorded name
has been created for a remote object on the local site, it is updated only if the remote and local filenames
for the recorded name differ. If, for example, you change the outgoing codec for recorded names on the
remote site gateway, the local site will not update its files because the change does not affect filenames.
In order to pull updated copies of recorded names from Cisco Unity to Connection, you must clear all
existing recorded names from the Connection site gateway by using the Clear Recorded Names button
on the Networking > Links > Search Intersite Links page in Connection Administration. In order to pull
updated copies of recorded names from Connection to Cisco Unity, use the Clear Voice Names button
on the Network > Connection Networking Profile page in the Cisco Unity Administrator.

Cisco Unity Connection 9.x Directory Size Limits

The Cisco Unity Connection global directory (the entire collection of local and replicated objects) is
subject to certain size limits. The same limits apply both to a single Connection site or to a Cisco
Voicemail Organization of linked sites (regardless of whether a Connection site is linked to another
Connection site or to a Cisco Unity site). In a Cisco Voicemail Organization, exceeding the limits affects
the ability to link sites together, and to replicate additional directory objects across the intersite link
when the sites have been linked. In Connection 9.x, there are separate limits on the number of users and
contacts and on the number of system distribution lists.
The size limits at the time of the 9.x release are:

A combined total of 100,000 users and system contacts (both contacts associated with a VPIM
location and those not associated with a location)

100,000 system distribution lists

25,000 users per system distribution list
1.5 million total list members across all system distribution lists
20 levels of nesting (where one system distribution list is included as a member of another list)

Note

Additional directory object limits exist, and the directory object limits may have been updated since the
time of release. For detailed and up-to-date limit information, see the System Requirements for
Cisco Unity Connection Release 9.x at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/requirements/9xcucsysreqs.html.
When you attempt to link a Connection site to another Connection site or to a Cisco Unity site, both the
user and system contact limit and the system distribution list limit are checked by the Connection site
gateway. If the combined number of users and contacts on the gateway after the link is created would
exceed the user and contact limit, or the combined number of system distribution lists on the gateway
would exceed the list limit, you will not be able to link the sites. (Note that the global directory sizes of
two sites do not necessarily match after they are linked because contacts are not replicated across the
intersite link. However, each Connection site is still subject to the maximum size limits, which include
system contacts.)
Consider the following example of the user and system contact limit check. Connection site A has 40,000
users and 5,000 system contacts, and Connection site B has 50,000 users and 15,000 contacts. If you
linked these sites together, the global directory on Connection site A would have 95,000 user and contact
objects (40,000 plus 5,000 plus 50,000). However, the global directory on Connection site B would have
a total of 105,000 user and contact objects (50,000 plus 15,000 plus 40,000). Attempting to join these
two sites would fail because the user and contact limit is exceeded on site B. However, attempting to join

Networking Guide for Cisco Unity Connection Release 9.x

1-10

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Messaging in Cisco Unity Connection 9.x

Connection site A with a Cisco Unity site that has 50,000 users and 15,000 networking contacts would
succeed, because the Connection site global directory of 95,000 user and contact objects would not
exceed the 100,000 user and system contact limit.
In addition to checking the limits at the time two sites are joined, each Connection site gateway also
checks the user and system contacts limit and the system distribution lists limit each time the Reader
service runs. If the limits have been exceeded by five percent or more, the Reader service will no longer
create new directory objects for remote site objects. It will, however, continue to make changes to
existing objects or delete them if they are removed from the remote site. This state is therefore known
as delete mode. In order to get the Reader out of delete mode, you must remove a sufficient quantity
of objects of the appropriate type to get to less than five percent above the limit (for example, remove
remote users, local users, or local system contacts if the user and system contact limit has been exceeded,
or remove local or remote system distribution lists if the system distribution list limit has been
exceeded.)

Messaging in Cisco Unity Connection 9.x

See the following sections for details on how messaging is handled in specific networking situations:

How Messages to System Distribution Lists Are Handled Within a Cisco Unity Connection Site,
page 1-11

How Messages to System Distribution Lists Are Handled Within a Cisco Unity Connection Site,
page 1-11

How Messages to System Distribution Lists Are Handled Within a Cisco Unity
Connection Site
Because system distribution lists are replicated among locations in a Cisco Unity Connection site, a user
can address messages to any system distribution list at any location, as long as the list is reachable in the
user search scope.
When a user addresses a message to a system distribution list, the local Cisco Unity Connection location
parses the distribution list membership. The sending location delivers the message directly to local users
on the list. If there are remote Connection users on the list, the sending location delivers the message to
each location that homes these remote users. If there are VPIM users on the list, the sending server either
delivers the message to the VPIM destination if the VPIM location is homed locally, or passes it to the
server on which the location is homed and that server handles forwarding the message to the destination
server.
Connection includes the following predefined system distribution lists: All Voicemail Users,
Undeliverable Messages, and All Voicemail-Enabled Contacts. Each Connection server in your
organization has a distinct version of each of these lists. If you have not changed the names of these lists
to be unique, during initial replication each server automatically adds the remote server name to the
display name of any remote lists whose names overlap with local list names.
By default, the predefined lists on each Connection location have the same recorded name, and the All
Voicemail Users and All Voicemail-Enabled Contacts lists have the same extension at each location (the
Undeliverable Messages list by default is not assigned an extension, because users do not typically
address messages to this list). When setting up a Connection site, you should consider modifying the
recorded name of each All Voicemail Users list and each All Voicemail-Enabled Contacts list; if you do

Networking Guide for Cisco Unity Connection Release 9.x

1-11

Chapter 1
Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Overview of Networking Concepts in Cisco Unity Connection 9.x

not, users can hear a confusing list of choices when they address messages by name to one of these lists.
When users address by extension to a list whose extension overlaps that of another list, they reach the
first list that is located when Connection searches the partitions of the user search space in order.

Tip

Distribution lists can be nested such that a distribution list contains other lists. You can create one master
All Voicemail Users distribution list for a site that contains the All Voicemail Users list of each
Connection location.

How Messages to System Distribution Lists Are Handled Between Sites

With intersite networking (either between Cisco Unity Connection sites or between Cisco Unity and
Connection sites), replication of system distribution lists is optional, and when lists are replicated, only
the information needed to address a message to the list is replicated. Therefore, when a user addresses a
message to a system distribution list that is homed in another site, the message is routed to the remote
site gateway (if the remote site is a Connection site) or to the Interoperability Gateway for Microsoft
Exchange (if the remote site is a Cisco Unity site). At this point, the system distribution list recipient is
handled as though the message originated within the remote site.
It is possible to nest system distribution lists such that a local list contains remote lists as members. For
example, you could nest the All Voicemail Users distribution list from one site within the All Voicemail
Users list of the other site. (If you are networking Cisco Unity with Connection, note that Connection
users may be automatically created as members of the All Subscribers list or other lists depending on
the template that you specify when creating the intersite link.) When you nest a remote list as a member
of a local list, we recommend the following practices:

Avoid nesting local lists as members of the remote list.

Do not allow the local list to replicate to the remote site.

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity

Connection 9.x
In order to limit replication traffic and keep the directory size manageable, only a subset of user
information is replicated from the home location of the user to other locations. For this reason, only the
user home location has information about call transfer settings, greetings, and other specific details for
the user. In order for a location to properly handle calls destined for a user on a different location, the
location that receives the call must hand off the call to the home location of the user. The purpose of the
cross-server features is to make the user experience in a networked environment almost the same as in a
single server environment, as shown in Table 1-4.
Table 1-4

Cross-Server Features

Feature

Description

Cross-server sign-in

Cross-server sign-in allows administrators to provide users who are

homed on different locations with one phone number that they can
call to sign in. When calling from outside the organization,
usersno matter which is their home servercall the same number
and are transferred to the applicable home server to sign in.

Networking Guide for Cisco Unity Connection Release 9.x

1-12

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Addressing and Dial Plan Considerations in Cisco Unity Connection 9.x

Table 1-4

Cross-Server Features (continued)

Feature

Description

Cross-server transfer

Cross-server transfer enables calls from the automated attendant or

from a directory handler of one server to be transferred to a user on
another server, according to the call transfer and screening settings
of the called user.

Cross-server live reply

Cross-server live reply allows users who listen to their messages by

phone to reply to a message from a user on another server by calling
the user (according to the call transfer and screening settings of the
called user).

The cross-server features can be enabled both within a site and across the entire Cisco voicemail
organization. For more information and instructions on enabling the cross-server features, see the
Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x chapter.

Addressing and Dial Plan Considerations in Cisco Unity

Connection 9.x
See the following sections for addressing and dial plan considerations in specific networking situations:

Addressing Options for Non-Networked Phone Systems, page 1-13

Identified User Messaging, page 1-14

Considerations for Intersite Networking Between Cisco Unity and Cisco Unity Connection,
page 1-14

Addressing Options for Non-Networked Phone Systems

If your organization has a separate phone system for each location, users at one location dial a complete
phone number, not just an extension, when calling someone at another location. When users sign in to
send messages to users on another networked location, the number that they enter when addressing a
message by extension depends on whether the numbering plans overlap across locations.
When user extensions on one location overlap with user extensions on another location, you can provide
unique extensions for each user by setting up alternate extensions for each user account. For each user,
enter a number for the alternate extension that is the same as the full phone number for the user, and
make sure that the alternate extension is in a partition that is a member of the search spaces that users at
other locations use. Once this has been set up, when users sign in to send messages, the number that they
enter when addressing messages is the same number that they use when calling.
When numbering plans do not overlap across networked locationsthat is, when user extensions are
unique across locationsusers can enter an extension when addressing a message to a user who is
associated with another location. Optionally, as a convenience for users in this circumstance, you may
choose to add alternate extensions to each user account, so that users do not need to remember two
different numbersone for calling a user directly, and one for addressing a message. However, if you
do not set up alternate extensions, be sure to tell users to use the extension instead of the full phone
number when addressing messages to users who are associated with another location.

Networking Guide for Cisco Unity Connection Release 9.x

1-13

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Addressing and Dial Plan Considerations in Cisco Unity Connection 9.x

Note that alternate extensions have other purposes beyond their use in networking, such as handling
multiple line appearances on user phones.

Identified User Messaging

When a user calls another user, and the call is forwarded to the greeting of the called user, the ability of
Cisco Unity Connection to identify that it is a user who is leaving a message is referred to as identified
user messaging. Because Connection is able to identify the caller as a user:

Connection plays the internal greeting of the called user when the caller leaves a message.

Connection plays the recorded name of the user who left the message when the recipient listens to
the message.

Connection allows the recipient to record a reply.

It is important to note the difference between the following two circumstances:

A user signs in to Connection, and then records and sends a message. In this circumstance, when the
user has signed in, Connection can identify the message as being from the user, regardless of which
location the message recipient is homed on. In this case, the phone system is not involved and the
recipient phone does not ring. Instead, the message is sent via networking message exchange (by
using SMTP).

A user places a phone call to another user, and then leaves a message. This circumstance is the basis
of identified user messaging.

As long as identified user messaging is enabled on a Connection location, Connection is able to identify
both local and remote users. Note, however, that for identified user messaging to work in both cases, the
initial search scope of the call must be set to a search space that locates the correct user based on the
calling extension, regardless of whether the caller is a local or remote user.
If a user calls from an extension that is in a partition that is not a member of the search space that was
set as the initial search scope for the call, the call is not identified as coming from the user. If the
extension of the user overlaps with an extension in another partition that also appears in this search
space, the call is identified as coming from the first object that Connection finds when searching the
partitions in the order that they appear in the search space.
In situations where numbering plans overlap across locations, it is therefore possible to have a user leave
a message that is incorrectly identified as coming from another user with the same extension in a
different partition. Because the initial search scope of the call is based on call routing rules, to avoid this
situation, use the following configuration guidelines:

Maintain a separate search space for each location in which the partition containing its users appears
first in the search space. (By default, each Connection server uses its own default partition and
default search space, which are replicated to other locations when the server is networked.)

On each location, set up forwarded call routing rules specific to every other location by specifying
a routing rule condition that applies only to calls from that location (for example, based on the port
or phone system of the incoming call). Configure the rule to set the search scope of the call to the
search space in which the partition containing users at the location appears first.

Considerations for Intersite Networking Between Cisco Unity and Cisco Unity
Connection
See the following sections:

Networking Guide for Cisco Unity Connection Release 9.x

1-14

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Addressing and Dial Plan Considerations in Cisco Unity Connection 9.x

Cisco Unity Connection Search Spaces and Cisco Unity Users, page 1-15

Cisco Unity Dialing Domains and Cisco Unity Connection Users, page 1-15

Combining Cisco Unity Unified Messaging and Cisco Unity Connection Integrated Messaging
When Users Have Accounts in the Same Active Directory Deployment, page 1-16

Cisco Unity Connection Search Spaces and Cisco Unity Users

When you link a Cisco Unity site and a Cisco Unity Connection site, a partition is automatically created
in the Connection directory for each Cisco Unity server, and all Cisco Unity users and system
distribution lists that are homed on the server are placed in the partition. However, the partition is not
automatically added to search spaces on the Connection locations. In order for Connection users to have
permission to address messages to Cisco Unity users, you must add the partition to the search spaces
used by those Connection users. Note that the order a partition appears in a search space is important if
users address messages by extension. If, for example, Connection and Cisco Unity users have
overlapping 4-digit extensions and you want Connection users to be able to reach other Connection users
by their 4-digit primary extension and reach Cisco Unity users by a unique 7-digit alternate extension,
make sure that the Cisco Unity partition appears after any Connection partitions that contain the
overlapping 4-digit extensions.

Cisco Unity Dialing Domains and Cisco Unity Connection Users

A dialing domain is a collection of servers that access the same directory and that are integrated with the
same phone system or phone system network. A dialing domain is a grouping scheme that allows
Cisco Unity to handle call transfers and addressing by extension from one server to another. Within the
dialing domain, extensions must be unique just as the phone extensions in the phone system must be
unique.
When you link a Cisco Unity site and a Cisco Unity Connection site, the Connection user and system
distribution list objects that are created in the Cisco Unity directory belong to the dialing domain that is
configured on the Cisco Unity site gateway. Because the Connection search space and partition design
accommodates overlapping extensions and may include users who have a primary extension and
alternate extensions in different partitions, you must choose how to map Connection extensions to the
Cisco Unity dialing domain. To do so, for each Connection location, you specify a single partition that
Cisco Unity pulls extensions from. (In Cisco Unity Connection Administration, you configure the Local
Partition That Cisco Unity Users Can Address to By Extension field on the Edit Location page for the
local location.) For example, consider a Connection user, Kelly Bader, who has two extensionsa
primary extension (4441) in the Sales Partition and an alternate extension (2025555) in the Chicago
Partition. If the partition that maps extensions to the dialing domain for Kellys home server location is
Chicago Partition, Cisco Unity users can address to Kelly by entering extension 2025555; they will
not be able to address to her by entering extension 4441. If the partition that maps to the dialing domain
for Kellys location is changed to Sales Partition, Cisco Unity users can address to Kelly by entering
extension 4441 but not by entering extension 2025555. (In either case, Cisco Unity users can address to
Kelly by name rather than by extension.)
If the extension of a Connection user conflicts with an existing extension in the dialing domain, and the
user has alternate extensions available in the partition that Cisco Unity pulls from, Cisco Unity will
attempt to assign one of the alternate extensions of the user as the extension of the corresponding contact
object. If there are no alternate extensions available or if the alternate extensions all conflict with
existing extensions in the dialing domain, the new object is created without an extension, and can only
be addressed by name. Similarly, if the object does not have any extension in the partition that maps to
the dialing domain, the new object is created without an extension.

Networking Guide for Cisco Unity Connection Release 9.x

1-15

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Addressing and Dial Plan Considerations in Cisco Unity Connection 9.x

Combining Cisco Unity Unified Messaging and Cisco Unity Connection Integrated Messaging When
Users Have Accounts in the Same Active Directory Deployment
When you link a Cisco Unity Unified Messaging site with a Connection site and users in both sites have
email accounts in the same Active Directory environment, the contacts that Cisco Unity creates for
Connection users can complicate the user experience when users address messages via ViewMail for
Outlook or other email clients.
Consider as an example the following two users:

Pat Jones, a Cisco Unity user with a Unified Messaging account that uses the alias
[email protected]. Pat uses Microsoft Outlook and Cisco Unity ViewMail for Outlook to access
email and voice messages in one mailbox.

Robin Smith, a Connection user who also has a separate Microsoft Exchange email account with
alias [email protected]. Robin uses Microsoft Outlook and Connection ViewMail for Outlook
to access email in the Exchange mailbox and voice messages in the Connection mailbox.

Prior to linking the Cisco Unity and Connection sites, the contacts list that Pat and Robin use in Outlook
contains one entry for Pat Jones as [email protected] and one for Robin Smith as
[email protected]. Robin also has [email protected] defined as an SMTP proxy address in
Connection in order to send voice messages with Connection ViewMail for Outlook and receive
messages that are addressed by using the Outlook contacts list. (Before the two sites are linked, however,
Pat and Robin cannot use their ViewMail clients to send voice messages to each other.)
Once the two sites are linked, Cisco Unity adds an additional contact to Active Directory for Robin
Smith. By default, this contact has a display name of Robin Smith - Voicemail to distinguish it from
Robins Exchange account. (The -Voicemail display name suffix is configurable.) The contact has an
SMTP address in the format UCI_<alias>_BH-<Connection location identifier>@<domain generated
according to Exchange Contact-creation policies>. Cisco Unity users can and should use this contact
when addressing voice messages via ViewMail. Voice messages addressed to Connection user email
accounts rather than to their contacts are delivered as emails with voice attachments and will not light
the user message waiting indicator or otherwise be accessible via Connection.
If another Connection user tries to address a voice message to the Robin Smith - Voicemail contact in
the contacts list, this message will be returned as undeliverable by default, because Connection does not
recognize the UCI_<alias>_BH-<Connection location identifier>@<Cisco Unity site gateway domain>
address as belonging to a Connection user. To mitigate this issue, you can add the address as an SMTP
proxy address for the user. (You can use Active Directory Users and Computers to export a list of
Connection contacts, then add SMTP proxy addresses to Connection users in bulk by using the Bulk
Administration Tool. For information on using the Bulk Administration Tool, see the Using the
Cisco Unity Connection Bulk Administration Tool chapter of the User Moves, Adds, and Changes
Guide for Cisco Unity Connection Release 9.x, at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/user_mac/guide/9xcucmacx.html.)
With the SMTP proxy address in place for Robin, other Connection users can send voice messages to
the Robin Smith - Voicemail contact. However, if a Connection user tries to address an email to the
contact, the email will be returned as undeliverable.
Cisco Unity users have one entry in Active Directory even after the sites are linked. Users in either site
can address voice messages to the entry in ViewMail for Outlook.
Note that if you choose to synchronize one or more Connection system distribution lists into a
Cisco Unity Unified Messaging deployment, an Active Directory group is created for each list, which
users can see in the contacts list. The group is created with the same configurable suffix (- Voicemail
by default) added to the display name. As with the user contact entries, Connection users who try to
address messages to the group will receive a non-delivery receipt in response. However, in this case, you

Networking Guide for Cisco Unity Connection Release 9.x

1-16

Chapter 1

Overview of Networking Concepts in Cisco Unity Connection 9.x

Migrating Users From Cisco Unity to Cisco Unity Connection 9.x

cannot currently mitigate the issue for synchronized distribution lists by using SMTP proxy addresses
because you cannot configure SMTP proxy addresses for lists. To work around the issue, you have a
couple of options:

Do not synchronize Connection system distribution lists to the Cisco Unity site. Instead, create any
lists that Cisco Unity users need directly on the Cisco Unity site, adding Connection contacts as
members when necessary.

Use multiple contact lists in Microsoft Exchange to segment addressing between Cisco Unity and
Connection users so that Connection users do not have access to the addresses of groups that
Cisco Unity creates for Connection lists.

Note that while Connection users should not address messages to Connection system distribution lists
by using the group address-book entry, they can address messages to Connection lists by entering the list
address in the format <list alias>@<Connection server SMTP domain>.

Migrating Users From Cisco Unity to Cisco Unity Connection 9.x

When intersite networking is configured between Cisco Unity and Cisco Unity Connection, you can
gradually migrate Cisco Unity users to Cisco Unity Connection 9.x. For more information, see the
Migrating from Cisco Unity to Cisco Unity Connection 9.x by Gradually Moving Data chapter in the
Reconfiguration and Upgrade Guide for Cisco Unity Connection Release 9.x at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/upgrade/guide/9xcucrugx.html.

Networking Guide for Cisco Unity Connection Release 9.x

1-17

Chapter 1
Migrating Users From Cisco Unity to Cisco Unity Connection 9.x

Networking Guide for Cisco Unity Connection Release 9.x

1-18

Overview of Networking Concepts in Cisco Unity Connection 9.x

CH A P T E R

Setting Up Networking Between Cisco Unity

Connection 9.x Servers
See the following sections:

Setting Up a Cisco Unity Connection 9.x Site, page 2-1

Linking Two Cisco Unity Connection 9.x Sites, page 2-16

Notable Behavior in Networked Cisco Unity Connection 9.x Servers, page 2-24

Setting Up a Cisco Unity Connection 9.x Site

This section describes the prerequisites for setting up a Cisco Unity Connection site, and provides a
high-level task list of all of the tasks that you need to complete for the setup, and the order in which they
should be completed. If you are unfamiliar with Connection site concepts, you should first read the
Overview of Networking Concepts in Cisco Unity Connection 9.x chapter and then review the task list
and procedures before beginning the setup.
You can link up to 10 Cisco Unity Connection locations in a single site. If you have more than 10
locations, set up two sites and link them together. (In order to link sites, all servers in each site must be
running Connection version 9.x. You cannot link more than two sites together.) For procedures, see the
Linking Two Cisco Unity Connection 9.x Sites section on page 2-16.
See the following sections:

Prerequisites, page 2-1

Task List for Setting Up a Cisco Unity Connection Site, page 2-2

Procedures for Setting Up a Cisco Unity Connection Site, page 2-3

Prerequisites
Before starting the setup, verify that the following prerequisites have been met on each server that will
join the site (for clusters, verify these prerequisites for the publisher server):

The server meets the requirements listed in the Requirements for Intrasite Networking section of
the System Requirements for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/requirements/9xcucsysreqs.html
.

Cisco Unity Connection is already installed.

Networking Guide for Cisco Unity Connection Release 9.x

2-1

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

The servers that will be networked together are directly accessible through TCP/IP port 25 (SMTP),
or SMTP messages are routable through an SMTP smart host.

For Connection clusters, you must have a smart host available to resolve the SMTP domain of the
cluster to both the publisher and subscriber servers in order for message traffic to reach the cluster
subscriber server in the event that the publisher server is down.

In addition, before setting up a Connection site, you should be familiar with the concepts in the
Managing Partitions and Search Spaces in Cisco Unity Connection 9.x chapter of the System
Administration Guide for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx.htm
l.

Task List for Setting Up a Cisco Unity Connection Site

Use this task list to set up a networking site between Cisco Unity Connection servers or clusters. The
cross-references take you to detailed procedures.
If you have a Connection cluster, do the tasks only on the publisher server.
1.

Make decisions about your networking deployment approach and gather information needed to
configure the site. See the Making Deployment Decisions and Gathering Needed Information for
Setting Up a Site section on page 2-4.

2.

Check the display name of each server that you are joining to the site, and modify it if it is not
unique, or if you want to select a more descriptive name. Also check the SMTP domain of each
server that you are joining to the site, and modify it if it is not unique. See the Verifying That Each
Cisco Unity Connection Server Has a Unique Display Name and SMTP Domain section on
page 2-5.

Caution

If the display name of a server matches the display name of another server on the site, the
server will not be able to join the site. Likewise, if the SMTP domain matches the SMTP
domain of another server on the site, the server will not be able to join the site.

3.

Start by linking two Connection servers together to create a site, then link additional servers to any
location in the site. See the Linking Cisco Unity Connection Servers with an Intrasite Link section
on page 2-7.

4.

If any servers in the site require a smart host to transmit and receive SMTP messages from other
servers (for example, because a firewall separates the servers, or because the servers are part of a
Connection cluster), configure the smart host, and configure the applicable locations to route
through the host. See the Configuring a Smart Host section on page 2-9.

Note

5.

For each Connection cluster that you have added to the site, you must configure all other
locations to route to the cluster through a smart host in order for message traffic to reach the
cluster subscriber server in the event that the publisher server is down. (You also configure the
smart host to resolve the SMTP domain of the cluster to both the publisher and subscriber
servers.)
For each cluster that you have added to the network, add the IP address of the subscriber server to
the IP address access list on every other location on the network; this ensures that other locations
can receive message traffic from the subscriber server if the publisher server is down. See the
Configuring SMTP Access for Cluster Subscriber Servers section on page 2-10.

Networking Guide for Cisco Unity Connection Release 9.x

2-2

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

6.

Verify that replication is complete among locations. See the Checking Replication Status Within a
Site section on page 2-11.

7.

Configure search spaces at each location to allow users who are homed at the location to address to
users at other locations. See the Configuring Search Spaces for Cisco Unity Connection Sites
section on page 2-12.

8.

Secure the site so that message transmissions are not misdirected. See the Securing the Cisco Unity
Connection Site section on page 2-13.

9.

Optionally, set up cross-server features. See the Cross-Server Sign-In, Transfers, and Live Reply
in Cisco Unity Connection 9.x chapter.

10. Test the site. See the Testing the Intrasite Setup section on page 2-13.
11. Optionally, set up a site-wide All Users distribution list. See the Creating a Site-Wide All

Voicemail Users Distribution List section on page 2-15.

12. If any servers in the site were previously configured as VPIM locations on other servers in the

network, clean up the unused VPIM locations. See the Cleaning Up Unused Cisco Unity
Connection VPIM Locations and Contacts section on page 2-16.
13. If you have not already done so, set up VPIM Networking to connect the Connection locations to

any other VPIM-compatible voice messaging systems. See the VPIM Networking in Cisco Unity
Connection 9.x chapter.
14. Optionally, create a mapping of which users are homed on which location. See the Mapping Users

to Their Home Locations section on page 2-16.

15. Optionally, if you have a large site that includes locations running Connection 9.x, review the

advanced settings available on the System Settings > Advanced > Intrasite Networking page in
Cisco Unity Connection Administration in case you need to tune the communications between the
Connection Digital Networking Replication Agent services on these locations. For a description of
the settings, including recommendations on how to use them together, see the Intrasite Networking
Configuration (Cisco Unity Connection 9.x section in the Cisco Unity Connection 9.x Advanced
Settings chapter of the Interface Reference Guide for Cisco Unity Connection Administration
Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/gui_reference/guide/9xcucgrgx.
html.
Also note that the Limit Number of Simultaneous Incoming Connections and Limit Number of
Simultaneous Outgoing Connections fields on the System Settings > SMTP Configuration > Server
page in Connection Administration affect the replication agent (and also affect intrasite messaging
between users as well as other features that use SMTP for message transmission). For information
on these settings, see the SMTP Server Configuration section in the Cisco Unity Connection 9.x
Advanced Settings chapter of the Interface Reference Guide for Cisco Unity Connection
Administration Release 9.x.

Procedures for Setting Up a Cisco Unity Connection Site

See the following sections:

Making Deployment Decisions and Gathering Needed Information for Setting Up a Site, page 2-4

Verifying That Each Cisco Unity Connection Server Has a Unique Display Name and SMTP
Domain, page 2-5

Linking Cisco Unity Connection Servers with an Intrasite Link, page 2-7

Configuring a Smart Host, page 2-9

Networking Guide for Cisco Unity Connection Release 9.x

2-3

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

Configuring SMTP Access for Cluster Subscriber Servers, page 2-10

Checking Replication Status Within a Site, page 2-11

Configuring Search Spaces for Cisco Unity Connection Sites, page 2-12

Securing the Cisco Unity Connection Site, page 2-13

Testing the Intrasite Setup, page 2-13

Creating a Site-Wide All Voicemail Users Distribution List, page 2-15

Cleaning Up Unused Cisco Unity Connection VPIM Locations and Contacts, page 2-16

Mapping Users to Their Home Locations, page 2-16

Making Deployment Decisions and Gathering Needed Information for Setting Up a Site
Before you begin setting up a site, be sure to plan for the following, and gather the applicable
information:

If your network includes voice messaging servers that do not meet the prerequisites for joining a
Cisco Unity Connection site but support the Voice Profile for Internet Mail (VPIM) protocol (for
example, Cisco Unified Communications Manager Business Edition, Cisco Unity Connection 2.x
servers, Cisco Unity 4.x and 5.x, or other VPIM-compatible systems), use VPIM Networking to
connect them.
We recommend the following approaches:
Unless your servers are already configured for VPIM, set up the site first, then set up VPIM

Networking.
Choose a single Connection location in the site to handle the configuration of VPIM locations

and contacts. This location is referred to as the bridgehead. The VPIM location and contact
objects are replicated from the bridgehead to all digitally networked Connection locations so
that those locations can address VPIM messages; the networked locations then forward the
messages to the bridgehead for delivery to the remote voice messaging server. Managing these
objects from a single location simplifies maintenance tasks and avoids potential overlaps in
contact information that could cause confusion to users when they attempt to address messages.
If you have already configured VPIM locations on multiple systems that are joining a site, delete

duplicate VPIM locations from all but one server before setting up the site. For instructions, see
the Removing a VPIM Location in Cisco Unity Connection 9.x section on page 4-15.
If you are migrating a VPIM location to a Connection site (for example, because you used VPIM

Networking to connect two or more Cisco Unity Connection 2.x servers and have upgraded the
servers to Connection 9.x) set up the Connection site first. After the directory is fully replicated
and you have tested message exchange between the Connection locations, remove the VPIM
locations and VPIM contacts that represent the migrated servers and their users. The task list
reminds you when to do this task.

By default, every Connection location (server or cluster) includes several predefined system
distribution lists, which you can modify but not delete. If you have not renamed these lists so that
the list names are unique on each location, or if you have added additional lists whose names are
identical across locations, during initial replication each location automatically adds the remote
server name to the display name of any remote lists whose names overlap with local list names. (The
default lists are All Voicemail Users, Undeliverable Messages, and All Voicemail-Enabled
Contacts.) This can cause confusion when local users try to address to those remote lists.
To solve this problem, you can use one of the following approaches:

Networking Guide for Cisco Unity Connection Release 9.x

2-4

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

If you want to maintain separate lists on each location, you can modify the name of each list on

its home location so that it is unique (for example All Voicemail Users on <Location Name>)
and notify your users of the new list names for each server. If you choose this approach, you
should also modify the recorded name of each list to indicate its source.
Alternatively, after setting up the site, you can create a master list that includes all users on all

networked locations. The task list includes instructions on when and how to do this task.

If you want to synchronize Connection user data with user data in an LDAP directory, we
recommend that you configure Connection for integration with the LDAP directory prior to setting
up the site, to simplify testing and troubleshooting.

Make note of the following information about each server that is joining the network:
The IP address or fully qualified domain name (FQDN) of the server.
The user name and password of a user account that is assigned to the System Administrator role.
The dial strings that other servers will use to call this server, if cross-server sign-in or transfer

will be configured on other servers to hand off calls to this server.

Verifying That Each Cisco Unity Connection Server Has a Unique Display Name and SMTP Domain
Each Cisco Unity Connection server that you join to a Connection site must have a unique display name.
The display name must be unique both among Connection locations and among VPIM locations. If the
display name is not unique, the server will not be able to join the site. For new Connection installations,
the display name is typically the same as the host name of the server; however, if you changed the display
name or upgraded the server from Connection 2.x (which uses Local VMS as the default display
name), you may need to change the display name so that it does not overlap with other locations on the
network.

Tip

Choose a display name for each server that is descriptive and that will help you identify the
location when it is listed among all locations in the organization in Cisco Unity Connection
Administration.

Each Connection server that you join to the site must also have a unique SMTP domain, both among
Connection locations and among VPIM locations. By default, the SMTP domain is configured during
installation to include the hostname of the server, in order to insure that it is unique. However, if the
SMTP domains of multiple servers have been modified to the same value, you must change the domains
to unique values before joining the servers in a site.
If you are migrating a server from VPIM Networking to intrasite or intersite networking, it is likely that
the display name or SMTP domain of the server overlaps with the VPIM location configured for the
server. If the domain name overlaps, you will need to disrupt messaging to the VPIM location while
doing the migrationeither by changing the SMTP domain of the VPIM location, or by removing the
VPIM location. (To remove the VPIM location, see the Removing a VPIM Location in Cisco Unity
Connection 9.x section on page 4-15.)
To Verify That Each Cisco Unity Connection Server Has a Unique Display Name and SMTP Domain
Step 1

Check the Display Name of the first server:

a.

In Cisco Unity Connection Administration on the first server, expand Networking, then select
Locations.

Networking Guide for Cisco Unity Connection Release 9.x

2-5

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

b.
Step 2

Step 3

On the Search Locations page, note the Display Name of the local server. We recommend that you
make a list of all Display Names that you can consult later.

Check the SMTP domain of the first server:

a.

Expand System Settings > SMTP Configuration, then select Server.

b.

On the SMTP Server Configuration page, note the SMTP Domain of the local server.

Check the Display Name and SMTP Domain Name of all VPIM locations homed on the local server:
a.

Expand Networking, then select VPIM.

b.

On the Search VPIM Locations page, note the Display Name of each VPIM location.

c.

Select the first VPIM location in the table. On the Edit VPIM Location page, note the SMTP Domain
Name of the VPIM location.

d.

Select Next and note the SMTP Domain Name of the next VPIM location.

e.

Repeat Step 3d. for each remaining VPIM location.

Step 4

Repeat Step 1 through Step 3 on each location that will be joined to the site.

Step 5

If the Display Name of a location conflicts with that of another location, or you want to modify a name
to be more descriptive, change one of the display names:

Step 6

Step 7

To change the Display Name of a Connection location, do Step 6.

To change the Display Name of a VPIM location, do Step 7.

If the Display Names are all unique, skip to Step 9.

Change the Display Name of the Connection location:

a.

On the server for which you want to change the Display Name, expand Networking, then select
Locations.

b.

Select the Display Name of the local server.

c.

On the Edit Location page, modify the Display Name value, and select Save.

To change the Display Name of a VPIM location:

a.

On the server on which the VPIM location is homed, expand Networking, then select VPIM.

b.

On the Search VPIM Locations page, select the Display Name of the location that you want to
change.

c.

On the Edit VPIM Location page, modify the Display Name value, and select Save.

Step 8

If there are any remaining Display Name conflicts, repeat Step 5 as necessary to resolve each conflict.

Step 9

If the SMTP domain of a server conflicts with that of another location, change one of the domain names:

Step 10

Step 11

To change the SMTP Domain of a Connection location, do Step 10.

To change the SMTP Domain Name of a VPIM location, do Step 11.

To change the SMTP Domain of a Connection location:

a.

Expand System Settings > SMTP Configuration, then select Server.

b.

On the SMTP Server Configuration page, select Change SMTP Domain, change the value of the
SMTP Domain field, and select Save.

c.

Select OK to confirm the change.

To change the SMTP Domain Name of a VPIM location:

a.

On the server on which the VPIM location is homed, expand Networking, then select VPIM.

Networking Guide for Cisco Unity Connection Release 9.x

2-6

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

b.

Select the Display Name of the VPIM location for which you want to change the SMTP Domain
Name.

c.

On the Edit VPIM Location page, change the value of the SMTP Domain Name field, and select
Save.

Caution

Step 12

Changing the SMTP Domain Name of a VPIM location may disrupt messaging with the
remote voice messaging system.

If there are any remaining SMTP domain conflicts, repeat Step 9 as necessary to resolve each conflict.

Linking Cisco Unity Connection Servers with an Intrasite Link

To create a Cisco Unity Connection site, you start by linking two servers together via an intrasite link.
Each server becomes a location in the new site. (When a Connection cluster is linked to a site, the cluster
counts as one location in the site.)
When you add a Connection server to an existing Connection site of two or more locations, you link the
server to a single location in the site; the server that you are adding receives a list of all the other
locations in the site, exchanges information with each location, and begins replicating directory
information with each location.
This section contains two procedures. We recommend that you start by doing the first procedure; if
Cisco Unity Connection Administration does not indicate that the servers have successfully been linked
in the first procedure, do the second procedure. Then, repeat the process for each additional server that
you are adding to the site.

Note

To Automatically Join Two Cisco Unity Connection Servers, page 2-7

To Manually Join Two Cisco Unity Connection Servers, page 2-8

You can use these procedures to join two Connection 9.x servers or to join a Connection 9.x server with
a Connection 7.x server. The names of the pages and fields changed between 7.x and 8.x; the 7.x names
appear in parenthesis at the end of each step where the terminology differs.
To Automatically Join Two Cisco Unity Connection Servers

Step 1

In Cisco Unity Connection Administration (on either server), expand Networking, expand Links, then
select Intrasite Links. (In Cisco Unity Connection 7.x, expand Networking, then select Connection
Locations.)

Step 2

Select Join Site. (In Connection 7.x, select Join Connection Network.)

Step 3

On the Join Site page, select Automatically Join the Site. (In Connection 7.x, on the Join Connection
Network page, select Automatically Join the Network.)

Step 4

In the Remote Location field, enter the IP address or fully-qualified domain name (FQDN) of the
Connection server to connect to in order to create the site.

Step 5

In the Remote User Name field, enter the user name of an administrator at the location specified in the
Remote Location field. The administrator user account must be assigned the System Administrator role.

Step 6

In the Remote Password field, enter the password for the administrator specified in the Remote User
Name field.

Networking Guide for Cisco Unity Connection Release 9.x

2-7

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

Step 7

Select Auto Join Site. (In Connection 7.x, select Auto Join Network.)

Step 8

When prompted, select OK to confirm. If the status message indicates that you have successfully joined
the network and need to activate and start the Connection Digital Networking Replication Agent,
continue with Step 9. Otherwise, skip the rest of this procedure and continue with the To Manually Join
Two Cisco Unity Connection Servers procedure on page 2-8.

Step 9

On either server, in Cisco Unity Connection Serviceability, select Tools > Service Management. (For
information on using Cisco Unity Connection Serviceability, see the Administration Guide for
Cisco Unity Connection Serviceability Release 9.x, at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/serv_administration/guide/9xcucser
vagx.html.)

Step 10

In the Server list, select the Connection server, and select Go.

Step 11

Under Optional Services, locate the Connection Digital Networking Replication Agent and select
Activate.

Step 12

Repeat Step 9 through Step 11 on the other server.

To Manually Join Two Cisco Unity Connection Servers

Step 1

In Cisco Unity Connection Administration (on either server), expand Networking, expand Links, then
select Intrasite Links. This server is referred to as the first server for the remainder of the procedure,
and the other server is referred to as the second server. (In Connection 7.x, expand Networking, then
select Connection Locations.)

Step 2

Select Join Site. (In Connection 7.x, select Join Connection Network.)

Step 3

On the Join Site page, select Manually Join the Site. (In Connection 7.x, select Manually Join the
Network.)

Step 4

Select Download and save the first server configuration file to a location on your hard drive, or on media
that you can use to copy the file to the second server.

Step 5

Browse to Connection Administration on the second server.

Step 6

In Connection Administration on the second server, expand Networking, expand Links, then select
Intrasite Links. (In Connection 7.x, expand Networking, then select Connection Locations.)

Step 7

Select Join Site. (In Connection 7.x, select Join Connection Network.)

Step 8

On the Join Site page, select Manually Join the Site. (In Connection 7.x, select Manually Join the
Network.)

Step 9

Select Download, and save the second server configuration file to a location on your hard drive, or on
media that you can use to copy the file to the second server.

Step 10

In the Select the Remote Configuration File to Upload field, select Browse and browse to the copy of
the configuration file that you downloaded from the first server in Step 4.

Step 11

Select Upload.

Step 12

In Connection Administration on the first server, in the Select the Remote Configuration File to Upload
field, select Browse and browse to your local copy of the configuration file that you downloaded from
the second server in Step 9.

Step 13

Select Upload.

Step 14

On either server, in Cisco Unity Connection Serviceability, select Tools > Service Management.

Step 15

In the Server list, select the Connection server, and select Go.

Networking Guide for Cisco Unity Connection Release 9.x

2-8

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

Step 16

Under Optional Services, locate the Connection Digital Networking Replication Agent and select
Activate.

Step 17

Repeat Step 14 through Step 16 on the other server.

Configuring a Smart Host

SMTP is used to transmit both directory information and messages between Cisco Unity Connection
locations in a site.
If any pair of locations in the site cannot transmit and receive SMTP messages directly (for example,
because a firewall separates the servers), you must configure these locations to route these messages
through an SMTP smart host.
In addition, for each Connection cluster that you add to the site, you must configure all other network
locations to route to the cluster through a smart host in order for message traffic to reach the cluster
subscriber server in the event that the publisher server is down, and configure the smart host to resolve
the SMTP domain of the cluster to the IP addresses of both the publisher and subscriber servers. For
example, a network has a single smart host and the following three locations:

ServerA, which is not a cluster member

Cluster 1, which is made up of ServerB, a publisher, and ServerC, a subscriber

Cluster 2, which is made up of ServerD, a publisher, and ServerE, a subscriber

In order to create a Connection site, you would join ServerA, ServerB and ServerD together to form the
site. Note the following:

On ServerA, you would configure the Connection locations for ServerB (which represents cluster 1)
and ServerD (which represents cluster 2) to route through the smart host.

On Server B (the cluster 1 publisher), you would configure the Connection location for ServerD
(which represents cluster 2) to route through the smart host.

On ServerD (the cluster 2 publisher), you would configure the Connection location for ServerB
(which represents cluster 1) to route through the smart host.

On the smart host, you would configure the SMTP domain name of cluster 1 to resolve to the IP
addresses of both ServerB and ServerC (for example, by using DNS MX records). You would also
configure the SMTP domain name of cluster 2 to resolve to both ServerD and ServerE.

Do the following tasks for each server that requires routing to other locations through a smart host:
1.

Configure the SMTP smart host to accept messages from the Connection server. If your site includes
Connection clusters, also configure the smart host to resolve the SMTP domain of the cluster to the
IP addresses of both the publisher and subscriber servers. See the documentation for the SMTP
server application that you are using.

2.

Configure the Connection server to relay messages to the smart host. See the To Configure the
Cisco Unity Connection Server to Relay Messages to a Smart Host procedure on page 2-10.

3.

Configure the Connection server to route messages to the other Connection locations through the
smart host. See the To Configure the Cisco Unity Connection Server to Route Inter-Location
Messages through the Smart Host procedure on page 2-10.

Networking Guide for Cisco Unity Connection Release 9.x

2-9

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

To Configure the Cisco Unity Connection Server to Relay Messages to a Smart Host
Step 1

In Cisco Unity Connection Administration, expand System Settings > SMTP Configuration, then
select Smart Host.

Step 2

In the Smart Host field, enter the IP address or fully qualified domain name of the SMTP smart host
server. (Enter the fully qualified domain name of the server only if DNS is configured.)

Step 3

Select Save.

To Configure the Cisco Unity Connection Server to Route Inter-Location Messages through the Smart Host
Step 1

In Cisco Unity Connection Administration, expand Networking, then select Locations.

Step 2

Select the name of a location that requires routing through a smart host.

Step 3

Check the Route to This Remote Location Through SMTP Smart Host check box.

Step 4

Select Save.

Step 5

Repeat Step 1 through Step 4 for each additional location that requires routing through the smart host.

Configuring SMTP Access for Cluster Subscriber Servers

When you create a site that includes a Cisco Unity Connection cluster server pair, you join only the
publisher server of the pair to the site. In order for all locations on the network to communicate directly
with the cluster subscriber server in the event that it has Primary status, you must configure all network
locations (except for the publisher server that is clustered with the subscriber server) to allow SMTP
connections from the subscriber server.
Direct SMTP connectivity is needed so that locations can continue to receive user message traffic from
the cluster while the publisher server does not have Primary status, in cases where routing from the
cluster to other locations is not done via a smart host. Direct SMTP connectivity with the subscriber
server does not impact directory updates, because directory updates are only replicated from the
publisher server.
For example, a network has the following three locations:

ServerA, which is not a cluster member

Cluster 1, which is made up of ServerB, a publisher, and ServerC, a subscriber

Cluster 2, which is made up of ServerD, a publisher, and ServerE, a subscriber

In order to create a site, you would join ServerA, ServerB and ServerD together. For direct SMTP access,
the following steps are required:

On ServerA, you would need to add the IP addresses of both ServerC and ServerE (the two
subscriber servers) to the IP address access list so that ServerA can communicate with either
subscriber server if it has Primary status.

On ServerB (the cluster 1 publisher), you would add the IP address of ServerE (the cluster 2
subscriber) to the IP address access list; and on ServerD (the cluster 2 publisher), you would add the
IP address of ServerC (the cluster 1 subscriber) to the IP address access list.

Networking Guide for Cisco Unity Connection Release 9.x

2-10

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

Alternatively, you can configure each cluster location to route messages to every other location through
a smart host; when you do this, the other Connection locations do not need to accept SMTP connections
directly from the cluster subscriber in the event that it has Primary status, because the cluster subscriber
will establish the SMTP connection with the smart host rather than directly with every other location. In
the example above, the alternate configuration would entail the following:

On ServerB (the cluster1 publisher), you would configure a smart host, and configure the
Connection locations for ServerA and ServerD (the cluster 2 publisher) to route through the smart
host.

On ServerD (the cluster 2 publisher), you would configure a smart host, and configure the
Connection locations for ServerA and ServerB (the cluster 1 publisher) to route through the smart
host.

For instructions on configuring routing through a smart host, see the Configuring a Smart Host section
on page 2-9. Note that when more than one cluster is joined to a single site, you should have already
configured each cluster to route messages to other clusters through the smart host; in this case, all you
need do in addition is to configure the cluster to route through the smart host to any servers that are not
configured as clusters.
To Configure Direct SMTP Access for Cluster Subscriber Servers
Step 1

On a network location, in Cisco Unity Connection Administration, expand System Settings > SMTP
Configuration, then select Server.

Step 2

On the Edit menu, select Search IP Address Access List.

Step 3

Select Add New.

Step 4

On the New Access IP Address page, enter the IP address of a cluster subscriber server at another
location on the network.

Note

Do not enter the IP address of the subscriber server on the publisher server that it is paired with.

Step 5

Select Save.

Step 6

On the Access IP Address page, check the Allow Connection check box.

Step 7

Select Save.

Step 8

Repeat Step 2 through Step 7 for each additional subscriber server on the network (other than the
subscriber server that is paired with the server you are configuring).

Step 9

Repeat Step 1 through Step 8 on each network location.

Checking Replication Status Within a Site

When initial replication begins among locations, it can take a few minutes to a few hours for data to be
fully replicated between all locations, depending on the size of your directory.
The Connection Intrasite Links and Locations pages in Cisco Unity Connection Administration can
provide information about the status of replication between locations. Do the following procedure to
check replication status in Connection Administration.

Networking Guide for Cisco Unity Connection Release 9.x

2-11

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

Tip

On Connection 9.x locations, you can also use the Voice Network Map tool in Cisco Unity Connection
Serviceability to check replication status. With the tool, you can quickly locate replication problems in
a site, and get information about the status of replication between any two locations in the site. For more
details, select Help > This Page from within the tool, or see the Understanding the Voice Network Map
Tool in Version 9.x chapter of the Cisco Unified Serviceability Administration Guide Release 9.x at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/serv_administration/guide/9xcucser
vagx.html.
To Check Replication Status Within a Site by Using Cisco Unity Connection Administration

Step 1

In Cisco Unity Connection Administration on a server that is joined to the network, expand
Networking > Links, then select Intrasite Links. (In Connection 7.x, expand Networking, then select
Connection Locations.)

Step 2

On the Search Intrasite Links page, in the Intrasite Links table, the Push Directory column indicates
whether a directory push to the remote location from the location you are accessing is in progress. The
Pull Directory column indicates whether a directory pull from the remote location is in progress.
For example, if an administrator initiates a Push Directory To request from ServerA to ServerB, the
Connection Administration on ServerA shows that a directory push to ServerB is in progress, and the
Connection Administration on ServerB shows that a directory pull from ServerA is in progress.

Caution

Note

Initial replication happens automatically. Do not initiate a directory push or pull while initial
replication is in progress.

Once initial replication is complete, changes are automatically synchronized between locations
as they occur, even when the Push Directory and Pull Directory columns display a status of Idle.

Step 3

To get more information about the status of replication with a particular remote location, under
Networking, select Locations, then select the display name of the location. (In Connection 7.x, on the
Search Connection Locations page, select the display name of the location.)

Step 4

On the Edit Location page, the Last USN Sent, Last USN Received, and Last USN Acknowledged fields
indicate the sequence numbers of replication messages sent to and from the remote location. If the Last
USN Sent value is higher than the Last USN Acknowledged value, the remote location is not currently
fully synchronized with this location; in this case, the Last USN Acknowledged value should continue
to increase periodically. (Note that the Last USN Sent value may also increase periodically.)

Configuring Search Spaces for Cisco Unity Connection Sites

When you initially set up a site between locations, users who are homed on one location are not able to
address messages to users at other locations, because the users on each location are in separate partitions
and use search spaces that do not contain the partitions of users on the other locations. After initial
replication completes between the locations, you can reconfigure your search spaces to include partitions
that are homed on other servers, and you can change the search scope of users, routing rules, call

Networking Guide for Cisco Unity Connection Release 9.x

2-12

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

handlers, directory handlers, and VPIM locations to use a search space that is homed on a remote
location. (Note that while both partitions and search spaces are replicated between locations, you cannot
assign users or other objects to a partition that is homed on another location.)
At a minimum, if you have not made any changes to the default partitions and search spaces on any
server, at each location you can add the default partition of each remote Cisco Unity Connection location
to the search space that local users are using. For example, in a network of three servers named ServerA,
ServerB, and ServerC with no changes to the system defaults, in Cisco Unity Connection Administration
on ServerA you would add the ServerB Partition and ServerC Partition default partitions as members
of the ServerA Search Space default search space; in Connection Administration on ServerB you
would add ServerA Partition and ServerC Partition to ServerB Search Space, and so on.
For instructions on adding partitions to search spaces, see the Managing Search Spaces in Cisco Unity
Connection 9.x section in the Managing Partitions and Search Spaces in Cisco Unity Connection 9.x
chapter of the System Administration Guide for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx.htm
l.

Securing the Cisco Unity Connection Site

No user credentials are transmitted as part of intrasite communications. However, in order to protect the
security of SMTP addresses that are contained in the messages, make sure that any smart hosts that are
involved in SMTP message transmission between Connection locations are configured to route messages
properly, as it may be possible to extract SMTP addresses from the messages. See the documentation for
the SMTP server application that you are using for instructions.

Testing the Intrasite Setup

To test the site configuration, create test user accounts or use existing user accounts on each Cisco Unity
Connection location. When setting up user accounts in Cisco Unity Connection Administration to be
used in the tests, be sure to do the following for each account:

Record a voice name.

Record and enable an internal greeting.

On the User Basics page, for Search Scope, select a search space that includes the partitions of
remote users.

On the User Basics page, check the List in Directory check box.

On the Playback Message Settings page, check the Before Playing Each Message, Play the Sender's
Information check box.

Optionally, if you plan to enable and test cross-server live reply, ensure that the account belongs to
a class of service for which the Users Can Reply to Messages from Other Users by Calling Them
check box is checked on the Edit Class of Service > Message Options page. (The check box is not
checked by default.)

Do the following tests to confirm that the site is functioning properly:

To Verify Messaging Between Users on Different Cisco Unity Connection Locations, page 2-14

To Verify Call Transfers From the Automated Attendant to Users on Other Cisco Unity Connection
Locations, page 2-14

To Verify Call Transfers from a Directory Handler to Users on Other Cisco Unity Connection
Locations, page 2-14

Networking Guide for Cisco Unity Connection Release 9.x

2-13

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

To Verify Identified User Messaging Between Networked Users (When Identified User Messaging
Is Enabled), page 2-14

To Verify Live Reply Between Users on Different Cisco Unity Connection Locations, page 2-15

To Verify Messaging Between Users on Different Cisco Unity Connection Locations

Step 1

Sign in to a Cisco Unity Connection location as a user.

Step 2

Follow the prompts to record and send messages to users who are associated with other Connection
locations.

Step 3

Sign in to the applicable Connection location as the recipient user to verify that the message was
received.

Step 4

Repeat Step 1 through Step 3 in the opposite direction.

To Verify Call Transfers From the Automated Attendant to Users on Other Cisco Unity Connection Locations
Step 1

From a non-user phone, call a Connection location that has been configured to handle outside callers,
and enter the extension of a user who is associated with another Connection location.

Step 2

Verify that you reach the correct user phone.

To Verify Call Transfers from a Directory Handler to Users on Other Cisco Unity Connection Locations
Step 1

From a non-user phone, call a Connection location that has been configured to handle outside callers,
and transfer to a directory handler.

Step 2

Verify that you can find a user who is associated with another Connection location in the phone directory,
and that the directory handler transfers the call to the correct user phone.

To Verify Identified User Messaging Between Networked Users (When Identified User Messaging Is Enabled)
Step 1

Step 2

Verify that Connection plays an internal greeting for users who leave messages, by doing the following
sub-steps:
a.

From a user phone, call a user who is associated with another Connection location, and allow the
call to be forwarded to Connection.

b.

Verify that the internal greeting plays.

c.

Leave a test message.

Verify that users are identified when the recipient listens to a message, by doing the following sub-steps:
a.

Sign in to the applicable Connection location as the recipient user and listen to the test message that
you recorded in Step 1.

b.

Verify that the user conversation announces who the message is from by playing the recorded voice
name of the sending user.

Networking Guide for Cisco Unity Connection Release 9.x

2-14

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Setting Up a Cisco Unity Connection 9.x Site

c.

After listening to the message, verify that the user conversation allows you to reply to the message.

To Verify Live Reply Between Users on Different Cisco Unity Connection Locations
Step 1

From a user phone, call a user who is associated with another Connection location, and allow the call to
be forwarded to voicemail.

Step 2

Leave a message.

Step 3

Sign in to the applicable Connection location as the recipient user and listen to the test message that you
recorded in Step 2.

Step 4

After listening to the message, verify that the user conversation allows you to live reply to the message
by saying Call sender or by using the applicable key presses for the user conversation type. (To find
the key presses for a particular conversation, see the Cisco Unity Connection Phone Menus and Voice
Commands chapter of the User Guide for the Cisco Unity Connection Phone Interface, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/user/guide/phone/b_9xcucugphone.h
tml.)

Step 5

Verify that the live reply call is correctly transferred to the phone of the user who left the message.

Creating a Site-Wide All Voicemail Users Distribution List

If you would like to create a master distribution list that includes all users on all servers in the site, do
the following tasks:

Tip

1.

On each location in the site, rename the All Voicemail Users list with a unique name (for example
All Voicemail Users on <Location Name>). For instructions, see the Modifying System
Distribution Lists in Cisco Unity Connection 9.x section in the Managing System Distribution
Lists in Cisco Unity Connection 9.x chapter of the System Administration Guide for Cisco Unity
Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx
.html.

2.

Create a new All Voicemail Users system distribution list on one location to use as the master list.

3.

Add the lists from all locations as members of the master list.

4.

Put all lists except the master list in partitions that do not belong to a search space that users use, so
that they cannot address to any list except the master. For example, on each location, create a new
partition called Hidden DLs on <Location Name> and put the list homed at that location in that
partition. (By default, new partitions are not a member of any search space.)

To avoid having users generate large amounts of voice message traffic by using reply-all to reply to
messages sent to the master list, we strongly recommend that you use search spaces to restrict access to
the master list to a small subset of users. These users can use a search space that is essentially identical
to the search space that other users use, except for the addition of the partition containing the master list.

Networking Guide for Cisco Unity Connection Release 9.x

2-15

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

Cleaning Up Unused Cisco Unity Connection VPIM Locations and Contacts

After migrating a Cisco Unity Connection server from VPIM Networking to being a member of a site,
you should delete the VPIM location for the server on any other servers in the site that were previously
using VPIM Networking to exchange messages with the server. Likewise, you should delete any VPIM
locations on the server that represent other Connection locations in the site. In order to successfully
delete the VPIM locations, you must first delete all contacts that are associated with the location.
Note that when you delete the VPIM contacts that represent Connection users, the contacts are removed
from distribution lists; consider reviewing and updating distribution list membership on each server to
include remote users as applicable. Also consider notifying users that they need to update the
membership of any private lists that include contacts on the server being migrated.
For instructions on deleting a VPIM location and the associated VPIM contacts, see the Removing a
VPIM Location in Cisco Unity Connection 9.x section on page 4-15.

Mapping Users to Their Home Locations

Each server or cluster handles a distinct group of users. In large organizations, it is possible that more
than one server or cluster is in use at the same physical location. In this case, you need to determine
which user accounts to create on each of the servers (the home server or location for each user), and
keep a record of the mapping. This record is needed for the following reasons:

User phones must forward calls to the system on which the users are homed.

If user phones have a Messages or a speed-dial button that dials the number to access voicemail,
the buttons must be configured to call the system on which the users are homed.

If you do not configure cross-server sign-in, users must dial the pilot number of the server or cluster
that they are associated with to check their messages; in this case, you need to tell users the correct
number to dial when calling their home server.

To create a record of the mapping, run the Users report on each Connection location. The information in
this report includes the user name and primary location. For more information, see the Reports in
Cisco Unity Connection 9.x chapter in the System Administration Guide for Cisco Unity Connection
Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx.htm
l.

Linking Two Cisco Unity Connection 9.x Sites

Cisco Unity Connection 9.x supports linking up to two sites with an intersite link. In order to link sites,
all servers in each site must be running Connection version 9.x.
You can link up to 10 Connection servers and/or clusters in a single site, and link two sites together.
(Only one intersite link is supported per site.) If either site will consist of more than one server or cluster,
set up the sites before linking them. For procedures, see the Setting Up a Cisco Unity Connection 9.x
Site section on page 2-1.
See the following sections:

Prerequisites, page 2-17

Task List for Linking Cisco Unity Connection Sites, page 2-17

Procedures for Linking Cisco Unity Connection Sites, page 2-18

Networking Guide for Cisco Unity Connection Release 9.x

2-16

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

Prerequisites

If either or both sites will consist of more than one server or cluster, set up the sites according to the
Setting Up a Cisco Unity Connection 9.x Site section on page 2-1.

Verify that each server is running Connection version 9.x.

Check the size of your directory against the limits in the System Requirements for Cisco Unity
Connection.

The two locations (one in each site) that will act as the gateways between the sites must be able to
route directly to each other through TCP/IP port 25 (SMTP), or SMTP messages must be routable
through an SMTP smart host. In addition, both gateways must be able to route to each other via
HTTP on port 80 or HTTPS on port 443.

Identify an account that you will use to access Cisco Unity Connection Administration. The account
must have the Manage Servers privilege. (The System Administrator and Technician roles each have
this privilege.)

Task List for Linking Cisco Unity Connection Sites

Use this task list to set up an intersite link between two Cisco Unity Connection sites (referred to as an
intersite link). The cross-references take you to detailed procedures.
If you have a Connection cluster, do the tasks only on the publisher server.
1.

Decide which location in each site will be the site gateway, and determine how messages will be
routed between the gateways. See the Determining the Site Gateway Locations and SMTP Routing
Between Gateways section on page 2-18.

2.

Check the display name of each server in each site, and modify it if it is not unique among all the
locations in both sites, or if you want to choose a more descriptive name. Also check the SMTP
domain of each server, and modify it if it is not unique. For a procedure, see the Verifying That
Each Cisco Unity Connection Server Has a Unique Display Name and SMTP Domain section on
page 2-5.

3.

Create the link. See the Creating the Intersite Link section on page 2-18.

4.

Verify that replication is complete between the sites. See the Checking the Status of
Synchronization Between Cisco Unity Connection Sites And Configuring Task Schedules section
on page 2-21.

5.

Configure search spaces between sites. See the Configuring Search Spaces Between Cisco Unity
Connection Sites section on page 2-23.

6.

Optionally, if you chose to synchronize system distribution lists in either or both directions between
the gateways, configure individual distribution lists to allow or prevent replication. See the
Configuring Individual System Distribution Lists for Synchronization section on page 2-23.

7.

Optionally, set up an organization-wide All Users distribution list. See the Creating an
Organization-Wide All Voicemail Users Distribution List section on page 2-23.

8.

Optionally, set up cross-server features between the locations. See theCross-Server Sign-In,
Transfers, and Live Reply in Cisco Unity Connection 9.x chapter.

9.

For each site, if any servers in the remote site were previously configured as VPIM locations on
other servers in the local site, clean up the unused VPIM locations. See the Cleaning Up Unused
Cisco Unity Connection VPIM Locations and Contacts section on page 2-16.

Networking Guide for Cisco Unity Connection Release 9.x

2-17

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

Procedures for Linking Cisco Unity Connection Sites

See the following sections:

Determining the Site Gateway Locations and SMTP Routing Between Gateways, page 2-18

Creating the Intersite Link, page 2-18

Checking the Status of Synchronization Between Cisco Unity Connection Sites And Configuring
Task Schedules, page 2-21

Configuring Search Spaces Between Cisco Unity Connection Sites, page 2-23

Configuring Individual System Distribution Lists for Synchronization, page 2-23

Creating an Organization-Wide All Voicemail Users Distribution List, page 2-23

Determining the Site Gateway Locations and SMTP Routing Between Gateways
To create an intersite link, you choose a single location on each site to act as a gateway to the other site.
All intersite communications (both for directory synchronization and for message exchange) pass
between the two gateways, thereby limiting the connectivity requirements and bandwidth usage to the
link between those two locations. In order for directory synchronization and message exchange to occur
between the two sites, the gateways you select must have the following connectivity with each other:

HTTPS (if you choose to encrypt the connection) or HTTP connectivity, for directory
synchronization.

SMTP connectivity, for message exchange.

Once you have chosen the gateway locations, determine how to route SMTP messages between them. In
each direction, you can route messages directly or use an SMTP smart host. Use an SMTP smart host in
the following situations:

The gateways are separated by a firewall that blocks SMTP transmissions.

Either or both of the gateways are Cisco Unity Connection clusters.

When a gateway is a cluster, you must configure the opposite gateway to route to the cluster through a
smart host in order for message traffic to reach the cluster subscriber server in the event that the publisher
server is down, and configure the smart host to resolve the SMTP domain of the cluster to the IP
addresses of both the publisher and subscriber servers. In this case, we recommend that you route traffic
in both directions through the smart host.

Creating the Intersite Link

This section contains two procedures:

Note

If your Cisco Unity Connection site gateways will route SMTP messages directly with each other,
do the To Automatically Link Two Cisco Unity Connection Site Gateways procedure on
page 2-19.

When you automatically link two gateways, the settings that you select are configured for both
gateways. After creating the link, you can change most settings on either gateway. Or, you can
use the manual procedure to configure the settings differently on each gateway.

Networking Guide for Cisco Unity Connection Release 9.x

2-18

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

If your Connection site gateways require a smart host for routing SMTP messages (for example,
because they are separated by a firewall, or because either or both gateways are clusters), do the To
Manually Link Two Cisco Unity Connection Site Gateways procedure on page 2-20.

To Automatically Link Two Cisco Unity Connection Site Gateways

Step 1

In Cisco Unity Connection Administration (on either server), expand Networking, expand Links, then
select Intersite Links.

Step 2

On the Search Intersite Links page, select Add.

Step 3

On the New Intersite Link page, select Link to Cisco Unity Connection Site by Using Automatic
Configuration Exchange Between Servers.

Step 4

In the SMTP routing warning message window, select OK.

Step 5

In the Hostname field, enter the IP address or fully-qualified domain name (FQDN) of the remote
Connection site gateway to link to.

Step 6

In the Username field, enter the user name of an administrator at the location specified in the Hostname
field. The administrator account must be assigned to a role that has the Manage Servers privilege. (The
System Administrator and Technician roles have this privilege.)

Step 7

In the Password field, enter the password for the administrator specified in the Username field.

Step 8

For Transfer Protocol settings, decide whether you want to enable SSL to encrypt directory
synchronization traffic between the sites.

Step 9

For Synchronization Settings, check the Include Distribution Lists When Synchronizing Directory
Data check box to pull information about remote system distribution lists to the local site so that users
can address messages to them. (Note that only the list name and other information used in addressing
are replicated.)

Step 10

Note

When you enable system distribution list synchronization, you cannot disable it after the link is
created except by removing and recreating the intersite link.

Note

In order for local system distribution lists to be offered to the remote site for synchronization,
they must also be marked to allow synchronization. By default, Connection system distribution
lists are marked to allow synchronization, although this setting may have been changed. The task
list alerts you when and how to enable lists for synchronization.

To convert recorded names from this site to a different encoding when synchronizing them with the
remote site, check the Convert Outgoing Recorded Names to check box, and select the codec to use.

Note

If you select a codec at this step, the same codec is configured on both gateways, which means
that recorded names will be sent in a format that differs from the recording format for at least
one of the two gateways. If this is not your intention, do not change the setting now. You can
change the setting later on the Edit Intersite Link page on either gateway.

Networking Guide for Cisco Unity Connection Release 9.x

2-19

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

Step 11

By default, two tasks that each run on their own schedule for data and recorded name directory
synchronization from the remote site are enabled immediately after you create the intersite link. To
disable either type of directory synchronization until you manually edit and enable the applicable
synchronization task, uncheck the Enable Task to Synchronize Directory Data After the Join or
Enable Task to Synchronize Recorded Names After the Join check boxes.

Step 12

Select Link.

Step 13

When prompted, select OK to confirm.

To Manually Link Two Cisco Unity Connection Site Gateways

Step 1

In Cisco Unity Connection Administration (on either site gateway), expand Networking, expand Links,
then select Intersite Links. This server is referred to as the first site gateway for the remainder of the
procedure, and the other gateway is referred to as the second site gateway.

Step 2

On the Search Intersite Links page, select Add.

Step 3

On the New Intersite Link page, select Link to Cisco Unity Site or Cisco Unity Connection Site by
Manually Exchanging Configuration Files.

Step 4

Select Download and save the first site gateway configuration file to a location on your hard drive, or
on media that you can use to copy the file to the second site gateway.

Step 5

Browse to Connection Administration on the second site gateway.

Step 6

In Connection Administration on the second site gateway, expand Networking, expand Links, then
select Intersite Links.

Step 7

On the Search Intersite Links page, select Add.

Step 8

On the New Intersite Link page, select Link to Cisco Unity Site or Cisco Unity Connection Site by
Manually Exchanging Configuration Files.

Step 9

Select Download, and save the second site gateway configuration file to a location on your hard drive,
or on media that you can use to copy the file to the second site gateway.

Step 10

In the Remote Site Configuration File field, select Browse and browse to the copy of the configuration
file that you downloaded from the first site gateway in Step 4.

Step 11

For Transfer Protocol settings, decide whether you want to enable SSL to encrypt the data passed
between the site gateways when the local reader service synchronizes with the remote gateway (local
reader requests and remote feeder responses).

Step 12

For Synchronization Settings, check the Include Distribution Lists When Synchronizing Directory
Data check box to pull information about remote system distribution lists to the local site so that users
can address messages to them. (Note that only the list name and other information used in addressing
are replicated.)

Note

When you enable system distribution list synchronization, you cannot disable it after the link is
created except by removing and recreating the intersite link.

Networking Guide for Cisco Unity Connection Release 9.x

2-20

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

Note

In order for local system distribution lists to be offered to the remote site for synchronization,
they must also be marked to allow synchronization. By default, Connection system distribution
lists are marked to allow synchronization, although this setting may have been changed. The task
list alerts you when and how to enable lists for synchronization.

Step 13

To convert recorded names from this site to a different encoding when synchronizing them with the
remote site, check the Convert Outgoing Recorded Names to check box, and select the codec to use.

Step 14

By default, two tasks that each run on their own schedule for data and recorded name directory
synchronization from the remote site are enabled immediately after you create the intersite link. To
disable either type of directory synchronization until you manually edit and enable the applicable
synchronization task, uncheck the Enable Task to Synchronize Directory Data After the Join or
Enable Task to Synchronize Recorded Names After the Join check boxes.

Step 15

For Intersite Routing, select the appropriate option:

Route to this Remote Site ThroughEnter the specific IP address or fully-qualified domain name
of a smart host that can properly route messages sent to addresses at the SMTP domain of the remote
site gateway.

Route to this Remote Site Through SMTP Smart Host (If One Is Defined)Routes outgoing
messages to the host defined on the System Settings > SMTP Configuration > Smart Host page. If
you select this option, the smart host must be defined, and must be able to properly route messages
sent to addresses at the SMTP domain of the remote site gateway. If the smart host is not defined, a
non-delivery receipt (NDR) is sent to the message sender.

Route to this Remote Site Through the Remote Site GatewayRoutes outgoing messages directly
to the remote site gateway SMTP server. Do not use this option if the remote gateway is a cluster,
or if the gateways are separated by a firewall.

Step 16

Select Link.

Step 17

In Connection Administration on the first site gateway, in the Select the Remote Configuration File to
Upload field, select Browse and browse to your local copy of the configuration file that you downloaded
from the second server in Step 9.

Step 18

Repeat Step 11 through Step 15 on the first site gateway.

Step 19

Select Link.

Checking the Status of Synchronization Between Cisco Unity Connection Sites And Configuring
Task Schedules
When initial synchronization begins between site gateways, it can take a few minutes to a few hours for
data to be fully replicated to each gateway, and from there to all locations in the site, depending on the
size of your directory.
On each site gateway, there are two tasks which control the schedule on which the Reader polls the
remote Feeder for directory data, and the schedule on which it polls for recorded names. By default, the
tasks run every 15 minutes. If you unchecked the Enable Task to Synchronize Directory Data After the
Join or Enable Task to Synchronize Recorded Names After the Join check boxes while linking the sites,
you must configure the schedule and enable the task before synchronization can begin.

Networking Guide for Cisco Unity Connection Release 9.x

2-21

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

You can use the Edit Intersite Link page and the Task Schedule page in Cisco Unity Connection
Administration to determine whether synchronization is progressing successfully or has completed. Do
the following procedure to check synchronization status between sites, and to configure schedules for
the two synchronization tasks.
To Check the Status of Synchronization Between Cisco Unity Connection Sites And Configure Task Schedules
Step 1

In Cisco Unity Connection Administration on a site gateway, expand Networking > Links, then select
Intersite Links.

Step 2

On the Search Intersite Links page, select the Display Name of the intersite link.

Step 3

On the Edit Intersite Link page, check the values of the following fields:

Step 4

Time of Last SynchronizationIndicates the timestamp of the last time the local reader service
attempted to poll the remote site gateway feeder service for directory changes on the remote site,
regardless of whether a response was received.

Time of Last ErrorIndicates the timestamp of the last time the local reader service encountered an
error while attempting to poll the remote site gateway feeder service. If the value of this field is 0,
or if the Time of Last Synchronization value is later than the Time of Last Error value, replication
is likely to be progressing without problems.

Object CountIndicates the number of objects (users, system distribution lists if applicable,
partitions, search spaces and Connection locations) that the local site gateway has synchronized
from the remote site.

View the Remote Site Directory Synchronization Task, and enable it or change the schedule, if
necessary:
a.

From the Edit Intersite Link page, in the Related Links box in the upper right corner of the page,
select Remote Site Directory Synchronization Task and select Go.

b.

On the Task Schedule page, enable the task if it has not yet been enabled, and modify the schedule
so that the task runs at the desired interval or time.

c.

Select Save.

d.

To view the task execution history, select Edit > Task Definition Basics. On this page you can
determine whether the task has not started, is in progress, or has completed. If the task has completed
you can select either the Time Started or Time Completed to view the detailed task results.

Step 5

From the Task Definition Basics page, select Task Definition > Task Definitions to go to the list of all
tasks.

Step 6

View the Synchronize Voice Names With Remote Network task, and enable it or change the schedule, if
necessary:
a.

On the Task Definitions page, select Synchronize Voice Names With Remote Network.

b.

Select Edit > Task Schedules.

c.

On the Task Schedule page, enable the task if it has not yet been enabled, and modify the schedule
so that the task runs at the desired interval or time.

d.

Select Save.

e.

To view the task execution history, select Edit > Task Definition Basics. On this page you can
determine whether the task has not started, is in progress, or has completed. If the task has completed
you can select either the Time Started or Time Completed to view the detailed task results.

Networking Guide for Cisco Unity Connection Release 9.x

2-22

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Linking Two Cisco Unity Connection 9.x Sites

Configuring Search Spaces Between Cisco Unity Connection Sites

When you initially set up a link between the sites, users who are homed on a location in one site are not
able to address messages to users at locations in the other site, because the users are in separate partitions
and use search spaces that do not contain the partitions of users on the locations in the other site. After
initial replication completes between the sites, you can reconfigure your search spaces to include
partitions that are homed on the remote site, and you can change the search scope of users, routing rules,
call handlers, directory handlers, and VPIM locations to use a search space that is homed on a location
in the remote site. (Note that while both partitions and search spaces are replicated between locations,
you cannot assign users or other objects to a partition that is homed on another location.)
At a minimum, if you have not made any changes to the default partitions and search spaces on any
server, at each location you can add the default partition of each remote site location to the search space
that local users are using. For example, in an organization where site 1 contains ServerA, ServerB, and
ServerC and site 2 contains serverD, with no changes to the system defaults, in Cisco Unity Connection
Administration on ServerA, ServerB, and ServerC you would add the ServerD Partition default
partition as a member of the ServerA Search Space, ServerB Search Space, and ServerC Search
Space default search spaces, respectively; in Connection Administration on ServerD you would add
ServerA Partition, ServerB Partition, and ServerC Partition to ServerD Search Space, and so on.
For instructions on adding partitions to search spaces, see the Managing Search Spaces in Cisco Unity
Connection 9.x section in the Managing Partitions and Search Spaces in Cisco Unity Connection 9.x
chapter of the System Administration Guide for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx.htm
l.

Configuring Individual System Distribution Lists for Synchronization

If you checked the Include Distribution Lists When Synchronizing Directory Data check box in Step 9
of the To Automatically Link Two Cisco Unity Connection Site Gateways procedure on page 2-19 or
Step 12 of the To Manually Link Two Cisco Unity Connection Site Gateways procedure on page 2-20,
information about system distribution lists created on the remote site can be pulled to the local site.
However, in order for information about an individual list to be offered to another site, the Replicate to
Remote Sites Over Intersite Links check box must be checked on the Edit Distribution List Basics page
for a list. By default, Replicate to Remote Sites Over Intersite Links is checked, so individual Connection
system distribution lists are marked for synchronization by default. However, in order to allow contacts
as members of a system distribution list, you must uncheck Replicate to Remote Sites Over Intersite
Links, so if you have lists that have been configured to allow contacts as members, they will not be
offered for replication to the remote site.
To disable synchronization for an individual list, uncheck Replicate to Remote Sites Over Intersite
Links. To enable synchronization for an individual list, remove any contacts that have been added as
members and check the Replicate to Remote Sites Over Intersite Links check box. To enable or disable
synchronization for multiple lists at once, you can use either Bulk Edit or the Bulk Administration Tool.

Creating an Organization-Wide All Voicemail Users Distribution List

If you would like to create a master distribution list that includes all users on all servers in both sites, do
the following tasks:
1.

On each location in each site, if you have not done so already, rename the All Voicemail Users list
with a unique name (for example All Voicemail Users on <Server Name>). For instructions, see the
Modifying System Distribution Lists in Cisco Unity Connection 9.x section in the Managing
System Distribution Lists in Cisco Unity Connection 9.x chapter of the System Administration

Networking Guide for Cisco Unity Connection Release 9.x

2-23

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Notable Behavior in Networked Cisco Unity Connection 9.x Servers

Guide for Cisco Unity Connection Release 9.x, available at

http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx
.html.
2.

Select one location in the organization to host the master list. Create a new All Voicemail Users
system distribution list on one location to use as the master list.

3.

Add the lists from all locations in both sites as members of the master list.

Note

4.

In order to add lists from the remote site, the gateway of the site on which the master list is
homed must have the Include Distribution Lists When Synchronizing Directory Data check box
checked on the Edit Intersite Link page, and the lists from each location in the remote site must
have the Replicate to Remote Sites Over Intersite Links check box checked on the Edit
Distribution List Basics page.
Put all lists except the master list in partitions that do not belong to a search space that users use, so
that they cannot address to any list except the master. For example, on each location, create a new
partition called Hidden DLs on <Server Name> and put the list homed at that location in that
partition. (By default, new partitions are not a member of any search space.)

Notable Behavior in Networked Cisco Unity Connection 9.x

Servers
See the following sections:

Intersite Networking: No Results Are Found When a Directory Handler Search Scope is Set to a
Remote System Distribution List, page 2-24

Intersite Networking: Users May Receive Multiple Copies of a Message Sent to Multiple
Distribution Lists, page 2-25

Networked Broadcast Messages Are Not Supported, page 2-25

Networked Dispatch Messages Are Not Supported, page 2-25

Manual Resynchronization Runs Both Directory and Voice Name Synchronization Tasks, page 2-25

Replication with Cisco Unity Connection Clusters, page 2-25

Users Can Add Remote Users as Private Distribution List Members, page 2-25

Intersite Networking: No Results Are Found When a Directory Handler Search

Scope is Set to a Remote System Distribution List
If you set the Search Scope of a directory handler to System Distribution List and select a list that is
homed on the remote site, no results are returned when callers reach the handler and attempt a search.
This happens because list membership is not replicated across intersite links. (This behavior does not
apply to voice-enabled directory handlers, which do not have the option to use a system distribution list
as the search scope.)

Networking Guide for Cisco Unity Connection Release 9.x

2-24

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Notable Behavior in Networked Cisco Unity Connection 9.x Servers

Intersite Networking: Users May Receive Multiple Copies of a Message Sent to

Multiple Distribution Lists
When a message is sent to multiple distribution lists, under some circumstances, when the message
traverses an intersite link, users who are members of more than one of the lists may receive multiple
copies of the message.

Networked Broadcast Messages Are Not Supported

Broadcast messages cannot be sent to multiple locations within a site or between sites.

Networked Dispatch Messages Are Not Supported

Dispatch messaging is not supported across locations. Dispatch messages addressed to recipients at other
locations within a site are delivered to remote users as regular messages. Dispatch messages addressed
to remote site recipients are not delivered. We recommend that you configure dispatch messaging only
when the message recipient is a system distribution list that does not include users on other networked
locations.

Manual Resynchronization Runs Both Directory and Voice Name

Synchronization Tasks
The Resync All button on the Search Intersite Links page starts the Synchronize Directory With Remote
Network task. When that task completes, it automatically starts the Synchronize Voice Names With
Remote Network task. These tasks normally run independently on separate schedules.

Replication with Cisco Unity Connection Clusters

When you add a Cisco Unity Connection cluster to a site or link two sites, you create the intrasite or
intersite link only on the publisher server of the pair. Directory updates made on a cluster subscriber
server are replicated only from the cluster publisher server. If all locations in the site (and all intersite
gateways, if applicable) are properly configured, voice messages continue to be sent to and from the
cluster even when the subscriber server has Primary status or the publisher server is shut down. However,
in order to keep the directory current on the publisher server, the publisher server should not remain shut
down for an extended period of time.

Users Can Add Remote Users as Private Distribution List Members

When creating private lists, users can add members from other locations if allowed by their search scope,
in which case the same set of users who are reachable when addressing a message or placing a call can
also be added as members of a private list. Private lists are not replicated to other locations; when a user
addresses a message to a private list, the home location of the user expands the distribution list and
addresses messages to each individual recipient on the list.
Consider notifying users in the event that the following members are inadvertently removed from their
lists:

Networking Guide for Cisco Unity Connection Release 9.x

2-25

Chapter 2

Setting Up Networking Between Cisco Unity Connection 9.x Servers

Notable Behavior in Networked Cisco Unity Connection 9.x Servers

When you delete a Cisco Unity Connection location, remote users at that location are removed from
all private lists.

When a VPIM contact becomes a Connection user, the contact is removed from all private lists.

Networking Guide for Cisco Unity Connection Release 9.x

2-26

CH A P T E R

Setting Up Networking Between Cisco Unity and

Cisco Unity Connection 9.x Servers
See the following sections:

Setting Up an Intersite Link Between Cisco Unity and Cisco Unity Connection 9.x Gateways,
page 3-1

Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways, page 3-4

Notable Behavior in Networking Cisco Unity and Cisco Unity Connection 9.x, page 3-18

Setting Up an Intersite Link Between Cisco Unity and

Cisco Unity Connection 9.x Gateways
This section describes the prerequisites for setting up an intersite link to connect a Cisco Unity server,
failover pair, or Digital Network to a Cisco Unity Connection server, cluster, or site, and provides a
high-level task list of all of the tasks that you need to complete for the setup in the order in which they
should be completed. If you are unfamiliar with intersite link concepts, you should first read the
Overview of Networking Concepts in Cisco Unity Connection 9.x chapter and then review the task list
and procedures before beginning the setup.
See the following sections:

PrerequisitesCisco Unity, page 3-1

PrerequisitesCisco Unity Connection, page 3-2

Task List for Setting Up an Intersite Link Between Cisco Unity and Cisco Unity Connection
Gateways, page 3-2

PrerequisitesCisco Unity

At least one Cisco Unity release 9.x server is already installed and connected to the network as
applicable for your installation. You can link a single Cisco Unity server or a single Cisco Unity
Digital Network to Cisco Unity Connection.

Networking Guide for Cisco Unity Connection Release 9.x

3-1

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Setting Up an Intersite Link Between Cisco Unity and Cisco Unity Connection 9.x Gateways

Your Cisco Unity and Microsoft Exchange environment must be meet the requirements listed in the
Cisco Unity Connection Networking Requirements section of the Networking Options
Requirements, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.ht
ml.

The Cisco Unity server that will act as the gateway to the Cisco Unity Connection site must be able
to route directly to the Connection site gateway via HTTP on port 80 or HTTPS on port 443.

PrerequisitesCisco Unity Connection

You can link a single Cisco Unity Connection 9.x server or cluster or a single Connection site to a
single Cisco Unity server, failover pair, or Digital Network. To link a Connection site, all servers in
the site must be running version 9.x.

If you are linking a Connection site, the site has been set up according to the Setting Up a
Cisco Unity Connection 9.x Site section on page 2-1.

The Connection site must meet the requirements listed in the Requirements for Intersite
Networking section in the System Requirements for Cisco Unity Connection Release 9.x at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/requirements/9xcucsysreqs.html
.

You have access to an account that has the Manage Servers privilege on the Connection server that
will serve as the gateway. (The System Administrator and Technician roles each have this privilege.)

The Connection server that will act as the gateway to the Cisco Unity site must be able to route
directly to the Cisco Unity site gateway via HTTP on port 80 or HTTPS on port 443.

Task List for Setting Up an Intersite Link Between Cisco Unity and Cisco Unity
Connection Gateways
1.

Make decisions about your network topology and gather information needed to configure the
intersite link. See the Making Deployment Decisions and Gathering Important Information
section on page 3-4.

2.

Determine the Cisco Unity domain name that will be used for messaging with Cisco Unity
Connection. See the Determining the Cisco Unity Interoperability Domain Name section on
page 3-4.

3.

Prepare the Cisco Unity gateway by configuring settings on the primary location page, checking
permissions, and extending the Active Directory schema. See the Preparing the Cisco Unity
Gateway section on page 3-5.

4.

If you have previously installed the Cisco Unity Voice Connector on an Exchange 2000 or Exchange
2003 server to handle VPIM Networking, uninstall it. See the Uninstalling the Cisco Unity Voice
Connector section of the Upgrading and Uninstalling Networking Options chapter in the
Networking Guide for Cisco Unity Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/9x/networking/guide/9xcunetx.html.
If you still require the Voice Connector to handle Bridge Networking and/or AMIS Networking, you
will reinstall it with only those options configured later in the task list.

5.

If you have previously installed the Interoperability Gateway for Microsoft Exchange, do one of the
following to ensure that it is properly configured:

Networking Guide for Cisco Unity Connection Release 9.x

3-2

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Setting Up an Intersite Link Between Cisco Unity and Cisco Unity Connection 9.x Gateways

If the Interoperability Gateway is installed on Exchange 2010 or 2007, check the foreign

connector configuration and configure a Send Connector and a Receive Connector. See the
Configuring a Previously Installed Interoperability Gateway for Cisco Unity Connection
Interoperability on Exchange 2010 or 2007 section on page 3-7.
If the Interoperability Gateway is installed on Exchange 2003, update your SMTP connector,

adding the UCI address space. See the Configuring a Previously Installed Interoperability
Gateway for Cisco Unity Connection Interoperability on Exchange 2003 section on page 3-10.
6.

If you have not previously installed the Interoperability Gateway for Microsoft Exchange, install
and configure it. (If you are currently using or plan to use VPIM Networking or Trusted Internet
locations on Cisco Unity, configure the Interoperability Gateway to handle these types of
networking as well as Cisco Unity Connection interoperability.) See the Setting Up the
Interoperability Gateway for Microsoft Exchange section in the Installing and Configuring the
Interoperability Gateway for Microsoft Exchange chapter of the Networking Guide for Cisco Unity
Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/9x/networking/guide/9xcunetx.html.

7.

If you uninstalled the Cisco Unity Voice Connector in task 4. and you still require the Voice
Connector to handle Bridge Networking and/or AMIS Networking, reinstall it with only those
options configured. See the Installing the Voice Connector section of the applicable Release Notes
for Cisco Unity Voice Connector for Microsoft Exchange, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_release_notes_list.html.

8.

Configure the Cisco Unity Connection gateway to accept SMTP connections from the Exchange
server that will deliver messages from Cisco Unity. See the Configuring SMTP Access on the
Cisco Unity Connection Gateway section on page 3-11.

9.

Download the Cisco Unity gateway configuration file. See the Downloading the Cisco Unity
Gateway Configuration File section on page 3-12.

10. On the Cisco Unity site gateway, set up a template to use when importing Connection users into

Cisco Unity. See the Setting Up a Template for Cisco Unity Connection Users on the Cisco Unity
Gateway section on page 3-12.
11. Begin linking the gateways by creating the intersite link in Cisco Unity Connection Administration

on the Cisco Unity Connection gateway. See the Creating the Intersite Link on the Cisco Unity
Connection Gateway section on page 3-13.
12. Finish linking the gateways by creating the intersite link on the Cisco Unity gateway. See the

Creating the Intersite Link on the Cisco Unity Gateway section on page 3-15.
13. Configure partitions and search spaces so that Cisco Unity Connection users can address to

Cisco Unity users and vice versa. See the Configuring Partitions and Search Spaces for Cisco Unity
and Cisco Unity Connection Interoperability section on page 3-16.
14. Optionally, if you chose to synchronize system distribution lists in either or both directions between

the gateways, configure individual distribution lists to allow or prevent replication. See the
Configuring Individual System Distribution Lists for Synchronization section on page 3-17.
15. Optionally, extend identified subscriber messaging on the Cisco Unity servers to include

Connection Networking subscribers. See the Extending Cisco Unity Identified Subscriber
Messaging to Include Connection Networking Subscribers section on page 3-18.
16. Optionally, set up cross-server sign-in, transfers, and live reply. See the Cross-Server Sign-In,

Transfers, and Live Reply in Cisco Unity Connection 9.x chapter.

Networking Guide for Cisco Unity Connection Release 9.x

3-3

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Procedures for Linking Cisco Unity and Cisco Unity Connection

9.x Gateways
Making Deployment Decisions and Gathering Important Information
Before you begin setting up Cisco Unity-Cisco Unity Connection interoperability, be sure to plan for the
following, and gather the applicable information:

If you have configured VPIM on your Cisco Unity servers by using the Cisco Unity Voice Connector
and its associated transport event sink, you must migrate your VPIM configuration to use the
Interoperability Gateway for Microsoft Exchange rather than the Voice Connector. The
Interoperability Gateway and the Voice Connector transport event sink cannot coexist when
Cisco Unity is configured for interoperability with Cisco Unity Connection. If you are installing the
Interoperability Gateway for the first time, be sure to configure it for both VPIM and Cisco Unity
Connection Networking. The task list will tell you when to uninstall the Voice Connector. (If you
still require the Voice Connector to handle Bridge Networking and/or AMIS Networking, you will
reinstall it to handle those options.)

Select a single location on each site to act as a gateway to the other site. The gateways you select
must have HTTP or HTTPS connectivity in order for directory synchronization to occur.
When selecting the Cisco Unity site gateway, if possible, choose the server with the highest

resources, lowest user count, and smallest amount of call activity. In particular, Platform
Overlay 1 servers have CPU, memory, disk and MSDE/SQL Express limits that lower the ability
of the server to handle synchronization overhead.
When selecting the Cisco Unity location, consider that all locations from the Connection site

will belong to the same Dialing Domain as the Cisco Unity site gateway.

Determining the Cisco Unity Interoperability Domain Name

In order for messages to be exchanged between Cisco Unity Connection and Cisco Unity, you will need
to decide on the domain name that Connection will use when addressing messages to Cisco Unity users.
The domain name uniquely identifies the messaging system. The domain name will be configured as
follows:

On the SMTP Domain Name field on the Network > Primary Location page in the Cisco Unity
Administrator on the Cisco Unity gateway.

On the Interop Domain FQDN field in the Interoperability Gateway Administrator.

Additionally, based on the Interop Domain FQDN, the domain name is configured as follows:

If you install the Interoperability Gateway on an Exchange 2010 or 2007 server:

As the SMTP AddressSpace domain on the Interoperability Gateway Foreign Connector. (This

value is set automatically, based on the Interop Domain FQDN, when the Interoperability
Gateway Foreign Connector is created or modified by using the Interoperability Gateway
Administrator.)
As the DomainName on the Interoperability Gateway Accepted Domain. (This value is set

automatically, based on the Interop Domain FQDN, when the Interoperability Gateway
Accepted Domain is created or modified by using the Interoperability Gateway Administrator.)

If you install the Interoperability Gateway on an Exchange 2003 server:

Networking Guide for Cisco Unity Connection Release 9.x

3-4

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

As the SMTP Address Space domain in the Interoperability Gateway SMTP Connector.
As the SMTP Email Address Policy on the Interoperability Gateway Recipient Policy.

If you have previously installed the Interoperability Gateway for Microsoft Exchange to handle VPIM
or Trusted Internet subscribers on Cisco Unity, use the interoperability domain that was chosen during
that process, unless it matches the Cisco Unity Connection gateway SMTP domain.
If you have not previously installed the Interoperability Gateway to handle other networking features,
the interoperability domain name can be whatever you would like it to be. As a best practice, however,
we recommend that you use a name that follows the format <Name>.<DomainName>, where <Name>
is a descriptive term and <DomainName> is the domain name of your organization, for example,
interop.mydomain.com. Note however that the interoperability domain name that you choose must meet
the following requirements:

It should not match any SMTP domain used in the Exchange organization to which Cisco Unity
belongs for any purpose other than for routing messages through the Interoperability Gateway for
Microsoft Exchange.

It must not match the SMTP domain of the Connection site gateway. (You can check the SMTP
domain on the System Settings > SMTP Configuration > Server page in Cisco Unity Connection
Administration on the Connection gateway.)

Preparing the Cisco Unity Gateway

Do the procedures in the following sections to prepare the Cisco Unity gateway:

Configuring the Primary Location Profile Page on the Cisco Unity Gateway, page 3-5

Checking Cisco Unity Permissions to Create Cisco Unity Connection Users, page 3-6

Extending the Active Directory Schema, page 3-6

Configuring the Primary Location Profile Page on the Cisco Unity Gateway
To Configure the Primary Location Profile Page on the Cisco Unity Gateway
Step 1

In the Cisco Unity Administrator on the Cisco Unity gateway, go to the Network > Primary Location >
Profile page.

Step 2

Enter a meaningful name for the location.

Step 3

If a Dial ID has not been entered, enter one. The Dial ID identifies this location to Cisco Unity and is
required to save changes to the page.

Step 4

For the Dialing Domain name:

If your installation consists of only one Cisco Unity server, create a dialing domain name.

If your installation consists of multiple Cisco Unity servers networked via Digital Networking, and
if this server is integrated with the same phone system as other networked Cisco Unity servers, you
may have already added this server to a dialing domain. If not, enter the dialing domain name, or
select it from the available list. The list contains names of dialing domain names already configured
on at least one other Cisco Unity server in the network.
Note that the dialing domain name is case sensitive and must be entered exactly the same on all of
the servers. To ensure that all servers are correctly added to the same dialing domain, enter the
dialing domain name on one Cisco Unity server and wait for the name to replicate to the other

Networking Guide for Cisco Unity Connection Release 9.x

3-5

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Cisco Unity servers. By doing so, you also confirm that replication is working correctly among the
servers. The time that it takes for the primary location data from other Cisco Unity servers to be
reflected on the local server depends on your network configuration and replication schedule.
Step 5

In the SMTP Domain Name field, enter the interoperability domain name that you previously chose in
the Determining the Cisco Unity Interoperability Domain Name section on page 3-4.

Step 6

Select the Save icon.

Checking Cisco Unity Permissions to Create Cisco Unity Connection Users

During Cisco Unity installation, when you ran the Cisco Unity Permissions wizard to grant the
necessary permissions to the installation and service accounts, if you did not check the Set Permissions
Required by AMIS, Cisco Unity Bridge, and VPIM check box on the Choose Whether to Enable Voice
Messaging Interoperability page, do the To Set Permissions to Create Cisco Unity Connection Users on
Cisco Unity procedure on page 3-6.

Tip

If you do not know whether you checked the check box, run the Permissions wizard in report mode. For
more information, see the Report Mode Help file, PWReportHelp_<language>.htm, in the directory in
which the Permissions wizard is installed.
For more information on running the Permissions wizard, see the Permissions wizard Help file,
PWHelp_<language>.htm, in the directory in which the Permissions wizard is installed.
To Set Permissions to Create Cisco Unity Connection Users on Cisco Unity

Step 1

Sign in to the gateway server by using an account that:

Is a member of the Domain Admins group in the domain that the Cisco Unity server belongs to, or
that has permissions equivalent to the default permissions for the Domain Admins group.

Is either an Exchange Full Administrator or a member of the Domain Admins group in the domain
that contains all of the domains from which you want to import Cisco Unity subscribers.

Step 2

Re-run the Permissions wizard, and follow the on-screen prompts until the Choose Whether to Enable
Voice Messaging Interoperability page appears.

Step 3

Check the Set Permissions Required by AMIS, Cisco Unity Bridge, and VPIM check box.

Step 4

Follow the on-screen prompts to complete the Permissions wizard.

Extending the Active Directory Schema

Before Cisco Unity is installed, the Active Directory schema is extended to store Cisco Unity-specific
information. To support interoperability with Cisco Unity Connection, the schema must be further
extended.
To see the schema changes that need to be made to support Cisco Unity Connection interoperability,
browse to the directory Schema\LdifScripts on Cisco Unity Disc 1, and view the file vpimgateway.ldf.
(The extensions needed for Cisco Unity Connection interoperability are the same as those needed for
VPIM Networking.)

Networking Guide for Cisco Unity Connection Release 9.x

3-6

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Do the following procedure only if you did not already modify the Active Directory schema to support
VPIM Networking. You can verify whether the schema has already been modified by examining the log
file that is generated each time the schema is updated. A shortcut to the directory where the log file is
located is placed on the Windows desktop.
To Extend the Active Directory Schema for Cisco Unity Connection Interoperability and VPIM Networking
Step 1

Confirm that all domain controllers are on line before making the schema updates. Schema replication
will occur only when all domain controllers are on line.

Step 2

On the domain controller that is the schema master, sign in by using an account that is a member of the
Schema Administrators group.

Step 3

On Cisco Unity DVD 1 or CD 1, or from the location to which you saved the downloaded Cisco Unity
CD 1 image files, browse to the directory ADSchemaSetup, and double-click ADSchemaSetup.exe.

Step 4

In the dialog box, double-click a row to choose the language in which you will view ADSchemaSetup.

Step 5

Check the Exchange VPIM and Connection Networking Connector check box, uncheck the other
check boxes, and then select OK.

Step 6

When the LDAP Data Interchange Format (LDIF) scripts have finished running, select OK.

Step 7

When the schema extension has finished, Ldif.log and LDif.err files are saved to the desktop. View the
contents of the files to confirm that the extension completed successfully.

Step 8

Wait for the changes to the schema to replicate throughout the forest before adding information to the
primary location and to delivery locations. Changes to the schema may take 15 minutes or more to
replicate.

Configuring a Previously Installed Interoperability Gateway for Cisco Unity

Connection Interoperability on Exchange 2010 or 2007
In order for messages to be exchanged between Cisco Unity and Cisco Unity Connection via the
Interoperability Gateway for Microsoft Exchange, a valid Foreign Connector must be present on the
Exchange 2010 or 2007 server to properly route messages through the Interoperability Gateway. In
addition, the Exchange organization to which your Cisco Unity servers belong must be allowed to send
mail to and receive mail from the SMTP bridgehead servers in the remote network. In the case where the
remote network is a Cisco Unity Connection site, depending on your configuration, mail may be sent
and received directly with the Connection site gateway or with a smart host or other relay outside of the
Exchange organization that handles SMTP connections on behalf of the Connection gateway.
In this section, first do the To Configure a Previously Installed Interoperability Gateway for
Cisco Unity Connection Interoperability (Exchange 2010 or 2007 Only) procedure on page 3-8.
If you are already familiar with how to configure the Exchange organization to allow messages to be sent
and received with the Cisco Unity Connection gateway, smart host, or relay, skip the remaining
procedures and handle the message delivery configuration based on rules and practices established in
your organization. Otherwise, do the remaining two procedures:

To Configure a Send Connector for a Remote Voice Messaging System (Exchange 2010 or 2007
Only), page 3-8

To Configure a Receive Connector for a Remote Voice Messaging System (Exchange 2010 or 2007
Only), page 3-9

Networking Guide for Cisco Unity Connection Release 9.x

3-7

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

To Configure a Previously Installed Interoperability Gateway for Cisco Unity Connection Interoperability
(Exchange 2010 or 2007 Only)
Step 1

Open the Interoperability Gateway Administrator. (In the Windows Start Menu, browse to Start >
Programs > Cisco > IGE Admin.)
If the Interoperability Gateway is installed on Exchange 2010, the Interoperability Gateway
Administrator prompts you to enter account credentials. Use an account that has Full Exchange
Administrator privileges.

Step 2

In the top pane of the Administrator, under Address Spaces, confirm whether the UCI
(Cisco Unity-Connection Interoperability) check box is checked. If it is already checked, close the
Interoperability Gateway Administrator and continue with the next task in the task list. If it is not
checked, check it.

Step 3

In the tree control at left in the Interoperability Gateway Administrator, select Foreign Connector.

Step 4

If a Foreign Connector has not previously been created that covers the interoperability domain and the
UCI feature address space that you checked in Step 2, a warning message displays in red at the top of
the Foreign Connector pane.
If you do not see this warning, and a valid Foreign Connector is displayed in the list box on the upper
left side of the pane, close the Interoperability Gateway Administrator and continue with the next task
in the task list.
If you do see the warning, you can modify the existing Foreign Connector that was created when the
Interoperability Gateway for Microsoft Exchange was initially installed. To do so, do the following
substeps:

Step 5

a.

In the list of Foreign Connectors that are homed on the server and contain at least one address space
that pertains to Cisco Unity networking (at the upper left), select the existing Foreign Connector.

b.

Select Modify below the list box.

c.

On the Execute Shell Command screen, select Run.

Close the Interoperability Gateway Administrator.

To Configure a Send Connector for a Remote Voice Messaging System (Exchange 2010 or 2007 Only)
Step 1

On the Exchange server on which the Interoperability Gateway is installed, open the Exchange
Management Shell.

Step 2

In the left-hand pane, expand Organization Configuration and select Hub Transport.

Step 3

In the main Hub Transport pane, select the Send Connectors tab.

Step 4

In the Actions pane, under Hub Transport, select New Send Connector.

Step 5

In the New SMTP Send Connector wizard, on the Introduction page, enter a Name for the new connector.

Step 6

Under Select the Intended Use for this Send Connector, select Custom, then select Next.

Step 7

On the Address space page, select Add.

Step 8

For Address, enter the SMTP domain of the remote network, then select OK.

Step 9

Select Next.

Step 10

On the Network settings page, select Route Mail through the Following Smart Hosts.

Step 11

Select Add.

Networking Guide for Cisco Unity Connection Release 9.x

3-8

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Step 12

For IP Address, enter the IP address of the Cisco Unity Connection gateway if messages will route
directly to the gateway, or of a smart host or other relay if one is configured to deliver messages from
the Exchange organization to the Connection gateway.

Step 13

Select OK.

Step 14

Select Next to continue to the next page.

Step 15

On the Configure Smart Host Authentication Settings Page, select the type of authentication to use when
sending mail between the Exchange organization and the Connection gateway.

Step 16

Select Next to continue to the next page.

Step 17

On the Source Server page, the local Exchange server should be listed by default. Select Next to
continue.

Step 18

Confirm the settings on the New Connector page and select New to add the new connector.

Step 19

Select Finish to exit the wizard.

Step 20

On the Send Connectors tab, right-click the connector that you created and select Properties.

Step 21

Set the Protocol Logging Level to Verbose.

Step 22

Select OK to close the properties window.

To Configure a Receive Connector for a Remote Voice Messaging System (Exchange 2010 or 2007 Only)
Step 1

On the Exchange server on which the Interoperability Gateway is installed, open the Exchange
Management Shell.

Step 2

In the left-hand pane, expand Server Configuration and select Hub Transport.

Step 3

In the upper Hub Transport pane, select the local Exchange server from the list of servers.

Step 4

In the lower pane, confirm that the title of the pane is the name of the local Exchange server, then select
the Receive Connectors tab.

Step 5

In the Actions pane, under the local server name, select New Receive Connector.

Step 6

In the New SMTP Send Connector wizard, on the Introduction page, enter a name for the new connector.

Step 7

Under Select the Intended Use for this Send Connector, select Custom, then select Next.

Step 8

On the Local Network settings page enter the fully qualified domain name of the local server in the
Specify the FQDN this Connector Will Provide in Response to HELO or EHLO: field.

Step 9

Select Next to continue to the next page.

Step 10

On the Remote Network settings page, in the list box, select 0.0.0.0-255.255.255.255, then select Edit.

Step 11

If messages will be received directly from the Cisco Unity Connection gateway, enter the IP address of
the gateway as both the Start Address and End Address value. If a smart host or other relay external to
the Exchange organization will deliver messages on behalf of the Connection gateway, enter the IP
address of the smart host or relay as both the Start Address and End Address value.

Step 12

Select OK.

Step 13

Select Next to continue to the next page.

Step 14

Confirm the settings on the New Connector page, then select New to add the new connector.

Step 15

Select Finish to exit the wizard.

Step 16

On the Receive Connectors tab, right-click the connector that you created and select Properties.

Networking Guide for Cisco Unity Connection Release 9.x

3-9

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Step 17

Set the Protocol Logging Level to Verbose.

Step 18

Select the Permission Groups tab.

Step 19

Check the Anonymous Users check box.

Step 20

Select OK to close the properties window.

Configuring a Previously Installed Interoperability Gateway for Cisco Unity

Connection Interoperability on Exchange 2003
To Check the SMTP Connector Configuration on a Previously Installed Interoperability Gateway for Cisco Unity
Connection Interoperability (Exchange 2003 Only)
Step 1

Open the Interoperability Gateway Administrator. (In the Windows Start Menu, browse to Start >
Programs > Cisco > IGE Admin.)

Step 2

In the top pane of the Administrator, under Address Spaces, check the UCI (Cisco Unity-Connection
Interoperability) check box if it is not checked.

Step 3

In the tree control at left in the Interoperability Gateway Administrator, select SMTP Connector.

Step 4

If an SMTP Connector has not previously been created that covers the interoperability domain and the
UCI feature address space, a warning message displays in red at the top of the SMTP Connector pane.

If you do not see this warning, and a valid SMTP Connector is displayed in the list box on the upper
left side of the pane, close the Interoperability Gateway Administrator and continue with the next
task in the task listno further SMTP Connector configuration is necessary.

If you do see the warning, and an SMTP Connector is displayed in the list box on the upper left side
of the pane, note the name of the SMTP Connector, then continue with the To Update the
Interoperability Domain SMTP Connector (Exchange 2003 Only) procedure on page 3-10.

To Update the Interoperability Domain SMTP Connector (Exchange 2003 Only)

Step 1

On the Exchange server on which the Interoperability Gateway for Microsoft Exchange is installed, open
the Exchange System Manager.

Step 2

In Exchange System Manager, in the left pane, navigate to and expand Connectors. (Depending on the
configuration, you may need to expand the Administrative Groups and/or Routing Group trees that
include the server on which the Interoperability Gateway will be installed.)

Step 3

Right-click the SMTP Connector that you noted in Step 4 of the To Check the SMTP Connector
Configuration on a Previously Installed Interoperability Gateway for Cisco Unity Connection
Interoperability (Exchange 2003 Only) procedure on page 3-10 and select Properties.

Step 4

On the Address Space tab, select Add to add a new address space.

Step 5

In the Add Address Space window, select Other, then select OK.

Step 6

For Type, enter UCI. In the Cost field, enter 1. In the Address field, enter * and select OK.

Step 7

On the Address Space tab, for the Connector scope, select Entire Organization.

Step 8

Select OK to save the SMTP Connector settings.

Networking Guide for Cisco Unity Connection Release 9.x

3-10

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Tip

To double-check the SMTP Connector configuration, return to the Interoperability Gateway

Administrator. If the SMTP Connector pane is still open, select any other item in the tree control
at left and then select SMTP Connector to refresh the pane. The warning message should no
longer display.

Configuring SMTP Access on the Cisco Unity Connection Gateway

The Cisco Unity Connection SMTP server running on each system has an IP access list that controls
which IP addresses are allowed to establish connections to it. Incoming SMTP connections are
automatically accepted from some servers, such as the systemwide smart host that is defined on the
System Settings > SMTP Configuration > Smart Host page, and any Connection or Cisco Unity
locations that are part of the same site or Cisco voicemail organization.
If messages from Cisco Unity users will be delivered to the Connection gateway by one or more servers
that are not already defined either as the systemwide smart host or as a Cisco Unity location (this would
be the case, for example, in a very simple configuration with a single Cisco Unity server that also hosts
the Interoperability Gateway for Microsoft Exchange and the entire Exchange organization) or in the IP
access list, do the following procedure to add the IP address of the delivery servers to the Connection
gateway IP access list.

Note

If you are unsure whether adding the IP address of the delivery servers to the Connection gateway IP
access list is necessary, do the procedure. Explicitly adding the address of a server for which SMTP
connections are automatically accepted does not negatively impact the SMTP server.
To Configure SMTP Access on the Cisco Unity Connection Gateway

Step 1

In Cisco Unity Connection Administration on the Cisco Unity Connection gateway, expand System
Settings > SMTP Configuration, then select Server.

Step 2

On the Edit menu, select Search IP Address Access List.

Step 3

Select Add New.

Step 4

On the New Access IP Address page, enter the IP address of the server that will deliver messages on
behalf of the Cisco Unity site.

Step 5

Select Save.

Step 6

On the Access IP Address page, check the Allow Connection check box.

Step 7

Select Save.

Step 8

Repeat Step 2 through Step 7 for each additional server that will deliver messages on behalf of the
Cisco Unity site.

Networking Guide for Cisco Unity Connection Release 9.x

3-11

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Downloading the Cisco Unity Gateway Configuration File

When linking Cisco Unity and Cisco Unity Connection gateways, you download the configuration file
for each gateway and load it on the other gateway. Start by downloading the Cisco Unity configuration
file to a location where you will be able to access it from Cisco Unity Connection Administration on the
Connection gateway.
To Download the Cisco Unity Gateway Configuration File
Step 1

In the Cisco Unity Administrator on the Cisco Unity site gateway, browse to Network and select
Connection Networking.

Step 2

Select Download to download the local site configuration file.

Step 3

Save the file to a location on your hard drive, or on media that you can use to copy the file to the
Cisco Unity gateway. Note that the file contains a public key certificate and should be treated as sensitive
data.

Setting Up a Template for Cisco Unity Connection Users on the Cisco Unity
Gateway
While creating an intersite link on the Cisco Unity gateway, you must select the template that the
Cisco Unity gateway uses to create directory objects for Cisco Unity Connection users. We recommend
that you review existing templates or create a new template specifically for Connection users prior to
creating the link.
The template that you select affects a number of important settings, such as:

Public distribution list membershipConnection users are added as list members in any
Cisco Unity public distribution lists that are configured for the template.

Show Subscriber in Email Server Address BookControls whether Connection users are listed in
the Outlook address book.

Class of ServiceAlthough most of the class of service settings do not affect the Connection users
directly, the Connection users are considered members of the class of service and therefore can
affect search results in cases where the class of service is used as the search scope of an object such
as a directory handler.

You can review existing templates in the Cisco Unity Administrator by going to any Subscribers >
Subscriber Template page and selecting the Find icon. To create a new template, do the following
procedure.
To Create a New Template for Cisco Unity Connection Users on the Cisco Unity Gateway
Step 1

In the Cisco Unity Administrator, go to any Subscribers > Subscriber Template page.

Step 2

Select the Add icon.

Step 3

In the Add a Subscriber Template dialog box, enter a name.

Step 4

Select New Template or Based on Existing Template. If you select Based on Existing Template, select
the applicable template in the Based On field.

Networking Guide for Cisco Unity Connection Release 9.x

3-12

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Step 5

Select Add.

Step 6

On the Profile page, select a Class of Service and check or uncheck the Show Subscriber in Email
Server Address Book check box, as applicable.

Step 7

Select the Distribution Lists page.

Step 8

On the Distribution Lists page, to assign all new users based on this template to a public distribution list,
select the list in the Public Distribution Lists box, then select >>.
To remove a distribution list from those to which new users are added, select the list, then select <<.

Step 9

Select the Save icon.

Creating the Intersite Link on the Cisco Unity Connection Gateway

Do the following procedure to create the intersite link on the Cisco Unity Connection gateway.
If the site gateway is a Connection cluster, do the procedure only on the publisher server. The publisher
server must be acting primary when you do the procedure.
To Create an Intersite Link on the Cisco Unity Connection Gateway
Step 1

In Cisco Unity Connection Administration on the Cisco Unity Connection gateway, expand
Networking, expand Links, then select Intersite Links.

Step 2

Select Add.

Step 3

On the New Intersite Link page, select Link to Cisco Unity Site or Cisco Unity Connection Site by
Manually Exchanging Configuration Files.

Step 4

Select Download and save the Cisco Unity Connection site configuration file to a location on your hard
drive, or on media that you can use to copy the file to the Cisco Unity gateway. Note that the file contains
a public key certificate and should be treated as sensitive data.

Step 5

Select Browse and upload the Cisco Unity configuration file that you downloaded in the To Download
the Cisco Unity Gateway Configuration File procedure on page 3-12.

Step 6

For Transfer Protocol settings, decide whether you want to enable SSL to encrypt directory
synchronization traffic between Cisco Unity and Cisco Unity Connection.

Caution

Step 7

To enable SSL, you must configure the Cisco Unity server to use SSL, which affects multiple
applications that access the Cisco Unity server. See the applicable version of the Security
Guide for Cisco Unity at
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_maintenance_guides_list.ht
ml.

For Synchronization Settings, check the Include Distribution Lists When Synchronizing Directory
Data check box to have system distribution lists that are created on the Cisco Unity site replicated to
Connection so that Connection users can address messages to them. (Note that only the list name and
other information used in addressing are replicated.)

Networking Guide for Cisco Unity Connection Release 9.x

3-13

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

In order for individual system distribution lists to be offered for synchronization by the
Cisco Unity gateway, they must also be marked to allow synchronization. By default, individual
Cisco Unity system distribution lists are not marked to allow synchronization. The task list alerts
you when and how to enable individual lists for synchronization.

Note

Step 8

To convert recorded names from this site to a different encoding when synchronizing them with the
remote site, check the Convert Outgoing Recorded Names To check box, and select the codec to use.

Verify that the codec you select is the correct one for the Cisco Unity site gateway. If you need
to change the recording format after creating the intersite link, you must clear all recorded names
and then resynchronize all directory data and names by using the Clear Recorded Names and
Resync All buttons on the Networking > Intersite Links > Search Intersite Links page in
Cisco Unity Connection Administration.This can have a heavy performance impact and should
only be performed during non-business hours.

Note

Caution

Step 9

By default, two tasks that each run on their own schedule to pull directory data and recorded names from
Cisco Unity to Connection are enabled immediately after you create the intersite link. To disable either
type of directory synchronization until you manually edit and enable the applicable synchronization task,
uncheck the Enable Task to Synchronize Directory Data After the Join or Enable Task to
Synchronize Recorded Names After the Join check boxes.

Caution

Step 10

Step 11

Do not select G711 a-law format when setting up an intersite link to a Cisco Unity site
gateway.

We strongly recommend that you perform the initial synchronization outside of normal
business hours to avoid peak traffic times. In particular, if your Cisco Unity site gateway is a
Platform Overlay 1 server, the synchronization activity can cause noticeable delays in the user
conversation.

For Intersite Routing, select the appropriate option:

Route to this Remote Site ThroughEnter the specific IP address or fully-qualified domain name
of a Microsoft Exchange server in your organization that can accept SMTP messages and route them
to the Interoperability Gateway for Microsoft Exchange. The host must be able to accept SMTP
messages sent from the Cisco Unity Connection gateway to addresses at the interoperability domain.

Route to this Remote Site Through SMTP Smart Host (If One Is Defined)Routes outgoing
messages to the host that is defined on the System Settings > SMTP Configuration > Smart Host
page. If you choose this option, the smart host must be defined, and must be able to accept SMTP
messages sent from the Cisco Unity Connection gateway to addresses at the interoperability domain.
If the smart host is not defined, a non-delivery receipt (NDR) is sent to the message sender.

Route to this Remote Site Through the Remote Site GatewayRoutes outgoing messages to the
Cisco Unity gateway. Use this option only if Microsoft Exchange is installed on the Cisco Unity
server and the server is able to accept SMTP messages sent from the Cisco Unity Connection
gateway to addresses at the interoperability domain.

Select Link.

Networking Guide for Cisco Unity Connection Release 9.x

3-14

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Creating the Intersite Link on the Cisco Unity Gateway

Do the following procedure to create the intersite link on the Cisco Unity gateway.
If the site gateway is a failover pair, do the procedure only on the primary server. The primary server
must be active when you do the procedure.

Caution

When you do Step 12 in the following procedure, synchronization of Cisco Unity Connection objects to
Cisco Unity begins automatically. We strongly recommend that you do this step outside of normal
business hours to avoid peak traffic times. In particular, if your Cisco Unity site gateway is a Platform
Overlay 1 server, the synchronization activity can cause noticeable delays in the user conversation.
To Create an Intersite Link on the Cisco Unity Gateway

Step 1

In the Cisco Unity Administrator on the Cisco Unity site gateway, browse to Network and select
Connection Networking.

Step 2

On the Connection Networking page, in the Remote Configuration File field, select Browse and upload
the Cisco Unity Connection configuration file that you downloaded in Step 4 of the To Create an
Intersite Link on the Cisco Unity Connection Gateway procedure on page 3-13.

Step 3

Select Add.

Step 4

For Template, select the template that you chose or created in the Setting Up a Template for Cisco Unity
Connection Users on the Cisco Unity Gateway section on page 3-12. The template is used to create
Cisco Unity directory objects for Connection users so that Cisco Unity users can address messages to
them. You must choose a template before you can create the intersite link.

Step 5

Optionally, enter a Display Name Suffix. When the Cisco Unity site gateway creates directory objects
for Connection users and any replicated system distribution lists, this suffix is placed at the end of the
display names of the objects. This can help Cisco Unity users locate the proper contact to use for
addressing messages in Microsoft Outlook or other clients that access the directory, particularly if
Connection users already have Active Directory accounts prior to creating the intersite link.

Tip

Step 6

Check the Synchronize Distribution Lists check box to have system distribution lists that are created
on the Connection site replicated to Cisco Unity so that Cisco Unity users can address messages to them.
(Note that only the list name and other information used in addressing are replicated.)

Note

Step 7

If you do not want to append a suffix to Connection user and system distribution list objects,
delete the default text in the Display Name Suffix field and leave the field blank.

In order for individual system distribution lists to be offered for synchronization by the
Connection gateway, they must also be marked to allow synchronization. By default, individual
Connection system distribution lists are marked to allow synchronization, although this setting
may have been changed. The task list alerts you when and how to enable individual lists for
synchronization.

Check the Synchronize Voice Names check box to have Cisco Unity synchronize voice names for
Connection users and system distribution lists.

Networking Guide for Cisco Unity Connection Release 9.x

3-15

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

Step 8

If you enabled SSL in Step 6 of the To Create an Intersite Link on the Cisco Unity Connection
Gateway procedure on page 3-13, check the Use Secure Sockets Layer (SSL) check box. If the
Connection site gateway is using a self-signed certificate (the default for Connection), also check the
Use Self-Signed Certificates check box.

Step 9

For Outbound Audio Conversion, if you want to convert voice names to a different format before sending
them to the Connection site gateway, select a codec in the Voice Names field.

Note

Verify that the codec you select is the correct one for the Connection site gateway. If you need
to change the recording format after creating the intersite link, you must clear all recorded names
and then resynchronize all directory data and names by using the Clear Voice Names and Total
Sync buttons on the Networking > Connection Networking > Profile page in the Cisco Unity
Administrator. This can have a heavy performance impact and should only be done during
non-business hours.

Step 10

Review and continue entering settings, as applicable.

Step 11

When you have finished entering settings, select the Save icon.

Step 12

Select Join.

Configuring Partitions and Search Spaces for Cisco Unity and Cisco Unity
Connection Interoperability
When you initially set up the intersite link between Cisco Unity Connection and Cisco Unity,
Connection users are not able to address messages to Cisco Unity users, because the Cisco Unity users
are placed in newly-created partitions (based on their home Cisco Unity server) that are not a member
of any Connection search spaces.
After initial replication completes between the gateways and Cisco Unity objects are replicated
throughout the Connection site, you can reconfigure your search spaces to include the Cisco Unity
partitions. (Note that you cannot assign Cisco Unity Connection users or other objects to a partition that
was created for Cisco Unity users.)
In addition, for each Connection location, you can specify the Local Partition That Cisco Unity Users
Can Address To By Extension. Only extensions belonging to this partition will be replicated to
Cisco Unity. These extensions can be used for message addressing as well as auto-attendant dialing at
the Cisco Unity site. Replicated extensions will be added to the Dialing Domain of the Cisco Unity site
gateway. Because extensions within a Dialing Domain must be unique, the collection of all partitions
chosen across the Connection site should not contain duplicates of any extension. When the collection
includes duplicate extensions, or extensions that already exist in the Cisco Unity site gateway Dialing
Domain, one or more extensions will be omitted from the Cisco Unity directory. Warnings will appear
in the Cisco Unity application event log indicating the owner of each omitted extension. After remedying
any conflicts, you may need to do a manual resynchronization on the Cisco Unity site gateway (by
selecting Total Sync on the Network > Connection Networking Profile page in Cisco Unity
Administrator) in order to update the extensions.
It is possible for a Connection user to not have any extensions belonging to the Local Partition That
Cisco Unity Users Can Address To By Extension configured on the server on which the user is homed.
In this case, Cisco Unity users will need to use dial-by-name for addressing messages to such
Connection users. Also, callers at the Cisco Unity site will only be able to reach the user via
dial-by-name Directory Handlers.

Networking Guide for Cisco Unity Connection Release 9.x

3-16

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Procedures for Linking Cisco Unity and Cisco Unity Connection 9.x Gateways

To configure the Local Partition That Cisco Unity Users Can Address To By Extension, do the following
procedure on each Connection server.

Note

By default, for each Connection location, the default <Server Name> Partition is used as the Local
Partition That Cisco Unity Users Can Address To By Extension. Cisco Unity users cannot address
messages by extension to any Connection users who do not have an extension in this partition.
To Configure the Partition that Cisco Unity Users Can Address To for a Cisco Unity Connection Location

Step 1

In Cisco Unity Connection Administration (on any location), expand Networking, then select
Locations.

Step 2

Expand Local Site and select the display name of the local location (the location on which you are
accessing Connection Administration).

Step 3

Under Local Partition That Cisco Unity Users Can Address To By Extension, for Partition, select the
name of the partition to use.

Step 4

Select Save.

Step 5

Repeat Step 1 through Step 4 on each Connection location in the site.

Configuring Individual System Distribution Lists for Synchronization

If you checked the Include Distribution Lists When Synchronizing Directory Data check box in Step 7
of the To Create an Intersite Link on the Cisco Unity Connection Gateway procedure on page 3-13,
system distribution lists created on Cisco Unity can be replicated to Cisco Unity Connection so that
Connection users can address to them. However, by default, individual Cisco Unity system distribution
lists are not marked for synchronization. To mark them, use the Public Distribution List Builder tool,
located in the Cisco Unity Tools Depot. (The option to set or unset synchronization for lists is referred
to as Configuring distribution lists for Connection Networking.)
If you checked the Synchronize Distribution Lists check box in Step 6 of the To Create an Intersite Link
on the Cisco Unity Gateway procedure on page 3-15, system distribution lists created on Connection
can be replicated to Cisco Unity. However, in order for information about an individual list to be offered
to the Cisco Unity site, the Replicate to Remote Sites Over Intersite Links check box must be checked
on the Edit Distribution List Basics page for a list. By default, Replicate to Remote Sites Over Intersite
Links is checked, so individual Connection system distribution lists are marked for synchronization by
default. However, in order to allow contacts as members of a system distribution list, you must uncheck
Replicate to Remote Sites Over Intersite Links, so if you have lists that have been configured to allow
contacts as members, they will not be offered for replication to the remote site.
To disable synchronization for an individual list, uncheck Replicate to Remote Sites Over Intersite
Links. To enable synchronization for an individual list, remove any contacts that have been added as
members and check the Replicate to Remote Sites Over Intersite Links check box. To enable or disable
synchronization for multiple lists at once, you can use either Bulk Edit or the Bulk Administration Tool.

Networking Guide for Cisco Unity Connection Release 9.x

3-17

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Notable Behavior in Networking Cisco Unity and Cisco Unity Connection 9.x

Extending Cisco Unity Identified Subscriber Messaging to Include Connection

Networking Subscribers
When a user on the Cisco Unity Connection site calls a Cisco Unity user and leaves a message, by default
Cisco Unity will not identify the message as being from the Connection user. For Cisco Unity to identify
callers whose calling number matches the extension or alternate extension of a Connection user,
identified subscriber messaging (ISM) must be extended to networking contacts. (If you are also using
other types of networking, such as VPIM, you may already have enabled ISM for networking contacts.)
Enabling ISM to include Connection Networking subscribers and other networking contacts requires the
following:

The automated attendant search scope on each server must be set to the dialing domain. On each
server, verify that the Set Auto Attendant Search Scope field is set to Dialing Domain on the
Network > Primary Location > Profile page in Cisco Unity Administrator.

Identified subscriber messaging must be enabled on each server. (ISM is enabled for regular
subscribers by default.) On each server, verify that the Disable Identified Subscriber Messaging
check box is unchecked on the System > Configuration > Settings page in Cisco Unity
Administrator. (This setting is stored in the registry. If the system is using failover, verify the setting
on both the primary and secondary servers.)

To Extend Identified Messaging to Include Connection Networking Subscribers

Step 1

On the Cisco Unity server desktop, double-click the Cisco Unity Tools Depot icon. (If the location is
using failover, start the procedure on the primary server.)

Step 2

In the left pane, under Administrative Tools, double-click Advanced Settings Tool.

Step 3

In the Unity Settings pane, click Networking - Enable Identified Subscriber Messaging (ISM) for
AMIS, Bridge, VPIM and Trusted Internet Subscribers.

Step 4

In the New Value list, click 1, then click Set.

Step 5

When prompted, click OK.

Step 6

Click Exit.

Step 7

Restart Cisco Unity for the registry setting to take effect.

Step 8

If the location is using failover, repeat Step 1 through Step 7 on the secondary server.

Step 9

Repeat Step 1 through Step 8 on each Cisco Unity location in the site.

Notable Behavior in Networking Cisco Unity and Cisco Unity

Connection 9.x
This section provides information about notable expected behavior associated with Cisco Unity and
Cisco Unity Connection networking.
See the following sections:

Changes to Configuration Settings in the Cisco Unity Administrator Do Not Take Effect
Immediately on the Interoperability Gateway for Microsoft Exchange, page 3-19

Networking Guide for Cisco Unity Connection Release 9.x

3-18

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Notable Behavior in Networking Cisco Unity and Cisco Unity Connection 9.x

Cisco Unity Connection Users Are Not Listed in the Directory in Exchange 2010 or 2007
Organizations, page 3-19

Differences in User Experience Between Cisco Unity and Cisco Unity Connection 9.x, page 3-20

Display of Cisco Unity User Address Information, page 3-20

Feature Support Limitations, page 3-20

Manual Resynchronization on the Cisco Unity Connection Site Gateway Runs Both Directory and
Voice Name Synchronization Tasks, page 3-20

No Results Are Found When a Cisco Unity Connection 9.x Directory Handler Search Scope is Set
to a Remote System Distribution List, page 3-21

Outbound SMTP Authentication, page 3-21

Users May Receive Multiple Copies of a Message Sent to Multiple Distribution Lists, page 3-21

ViewMail for Microsoft Outlook and Body Text in Voice Messages, page 3-21

Changes to Configuration Settings in the Cisco Unity Administrator Do Not Take

Effect Immediately on the Interoperability Gateway for Microsoft Exchange
The Interoperability Gateway for Microsoft Exchange gets information about Cisco Unity networking
locations by communicating with the web services resource on a server running Cisco Unity 8.x. For
example, when evaluating an outgoing secure message, the Interoperability Gateway looks up the
configuration for the destination to determine whether the message should be decrypted and sent or
returned as undeliverable. In the Cisco Unity Administrator, you configure this and other
location-specific settings on the Connection Networking profile for a Cisco Unity Connection site.
To understand how your topology dictates when changes to configuration settings made in the
Cisco Unity Administrator will take effect in the Interoperability Gateway, and for information on how
to expedite the process, see the The Interoperability Gateway for Microsoft Exchange with Cisco Unity
8.x section in the Troubleshooting Networking in Cisco Unity 8.x chapter of the Troubleshooting
Guide for Cisco Unity Release 8.x at
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/8x/troubleshooting/guide/8xcutsgx.html.

Cisco Unity Connection Users Are Not Listed in the Directory in Exchange 2010
or 2007 Organizations
When Cisco Unity is installed in an Active Directory forest that does not contain any servers running
Exchange 2003 or earlier, public distribution lists and contact objects created by the Cisco Unity server
do not have a value written to the showInAddressBook attribute. As a result, those objects are not
available in an address book that is accessed through a mail client, such as Microsoft Outlook. In a
Cisco Unity Connection Networking deployment, this affects all users and distribution lists that are
replicated from Connection.
For instructions on how to update address lists to include Connection objects, see the Public
Distribution Lists and Networking Subscribers Created by Cisco Unity Are Not Listed in the Directory
section in the applicable 8.x or later version of the Release Notes for Cisco Unity at
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_release_notes_list.html.

Networking Guide for Cisco Unity Connection Release 9.x

3-19

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Notable Behavior in Networking Cisco Unity and Cisco Unity Connection 9.x

Differences in User Experience Between Cisco Unity and Cisco Unity

Connection 9.x
When you network Cisco Unity and Cisco Unity Connection, and particularly when you migrate users
from Cisco Unity to Cisco Unity Connection, users may notice differences in behavior between the two
products, including the following:

Cisco Unity Connection turns on the message waiting indicator (MWI) for new receipts;
Cisco Unity does not.

Display of Cisco Unity User Address Information

Cisco Unity Connection users who use applications such as Cisco Unity Connection ViewMail for IBM
Lotus Notes, Cisco Unity Connection ViewMail for Microsoft Outlook, and Visual Voicemail may see
system-generated SMTP addresses for Cisco Unity users. For example, when viewing a message
received by a Cisco Unity user, the sender is identified by display name, and the system-generated
address is displayed along with the display name.

Feature Support Limitations

The following features are not supported across intersite links between Cisco Unity and Cisco Unity
Connection sites:

License pooling

Relay of messages to or from VPIM, AMIS, Bridge, or system contacts, including blind addressing
to such contacts

Broadcast messages

Dispatch messages

Message recall

Manual Resynchronization on the Cisco Unity Connection Site Gateway Runs

Both Directory and Voice Name Synchronization Tasks
The Resync All button on the Search Intersite Links page in Cisco Unity Connection Administration
starts the Synchronize Directory With Remote Network task. When that task completes, it automatically
starts the Synchronize Voice Names With Remote Network task. These tasks normally run independently
on separate schedules.

Networking Guide for Cisco Unity Connection Release 9.x

3-20

Chapter 3

Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Notable Behavior in Networking Cisco Unity and Cisco Unity Connection 9.x

No Results Are Found When a Cisco Unity Connection 9.x Directory Handler
Search Scope is Set to a Remote System Distribution List
If you set the Search Scope of a Cisco Unity Connection directory handler to System Distribution List
and select a list that is homed on the Cisco Unity site, no results are returned when callers reach the
handler and attempt a search. This happens because list membership is not replicated across intersite
links. (This behavior does not apply to voice-enabled directory handlers, which do not have the option
to use a system distribution list as the search scope.)

Outbound SMTP Authentication

Cisco Unity Connection does not support outbound SMTP authentication. If the Exchange environment
in use by Cisco Unity requires authentication, you must configure the Connection site gateway to route
messages.

Users May Receive Multiple Copies of a Message Sent to Multiple Distribution

Lists
When a message is sent to multiple distribution lists, under some circumstances, when the message
traverses an intersite link, users who are members of more than one of the lists may receive multiple
copies of the message.

ViewMail for Microsoft Outlook and Body Text in Voice Messages

When Cisco Unity ViewMail for Microsoft Outlook users type text in the body of a voice message, the
text is not received by Cisco Unity Connection users. Likewise, when Cisco Unity Connection ViewMail
for Microsoft Outlook users type text in the body of a message, the text is not received by Cisco Unity
users. However, recipients on the same type of system do receive the text (Cisco Unity users receive text
sent by other Cisco Unity users, and Connection users receive text sent by other Connection users).

Networking Guide for Cisco Unity Connection Release 9.x

3-21

Chapter 3 Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
Notable Behavior in Networking Cisco Unity and Cisco Unity Connection 9.x

Networking Guide for Cisco Unity Connection Release 9.x

3-22

CH A P T E R

VPIM Networking in Cisco Unity Connection 9.x

Revised January 8, 2013

Cisco Unity Connection supports the Voice Profile for Internet Mail (VPIM) protocol, which is an
industry standard that allows different voice messaging systems to exchange voice and text messages
over the Internet or any TCP/IP network. VPIM is based on the Simple Mail Transfer Protocol (SMTP)
and the Multi-Purpose Internet Mail Extension (MIME) protocols.
VPIM Networking can be used for messaging between Cisco Unity Connection 2.x and later servers, or
between Connection 2.x and later servers and other VPIM-compatible voice messaging systems such as
Cisco Unity 4.0 and later. Note that additional server discovery and directory synchronization
functionality is available when you use Digital Networking rather than VPIM to connect multiple
Connection 2.x and later servers.
VPIM Networking is a licensed feature. For more information on obtaining licenses for Connection
features, see the Managing Licenses in Cisco Unity Connection 9.x chapter of the System
Administration Guide for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx.htm
l.
See the following sections:

Setting Up Cisco Unity Connection 9.x to Use VPIM Networking, page 4-1

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking, page 4-3

Deleting VPIM Contacts in Cisco Unity Connection 9.x, page 4-15

Removing a VPIM Location in Cisco Unity Connection 9.x, page 4-15

VPIM Concepts in Cisco Unity Connection 9.x, page 4-16

Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

This section describes the prerequisites for setting up VPIM Networking, and provides a task list
containing a high-level view of all of the tasks you need to complete for the setup, and the order in which
they should be completed. If you are unfamiliar with VPIM Networking, you should first read the VPIM
Concepts in Cisco Unity Connection 9.x section on page 4-16 and then review the task list and
procedures before beginning the setup.
See the following sections:

Prerequisites, page 4-2

Task List: Setting Up Cisco Unity Connection to Use VPIM Networking, page 4-2

Networking Guide for Cisco Unity Connection Release 9.x

4-1

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Prerequisites
Revised January 8, 2013

Before starting the setup, verify that the following prerequisites have been met:

Cisco Unity Connection is already installed and connected to the network.

The remote voice messaging system that Connection will be networked with is listed in the
Requirements for VPIM Networking section of the applicable system requirements document:
System Requirements for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/requirements/9xcucsysreqs.html
or System Requirements for Cisco Unity Connection in Cisco Unified CMBE Release 9.x, available
at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/requirements/9xcucmbesysreqs.
html.

Task List: Setting Up Cisco Unity Connection to Use VPIM Networking

Use the task list that follows to set up VPIM Networking in Cisco Unity Connection. The links take you
to detailed procedures for the setup.
1.

Make decisions about your numbering plan and gather information needed to configure VPIM
Networking. See the Making Design Decisions and Gathering Needed Information section on
page 4-3.

2.

Determine the domain name that is used for messaging between the remote voice messaging system
and Connection. See the Determining the Domain Name section on page 4-4.

3.

As applicable, configure DNS files. See the Resolving Names with IP Addresses section on
page 4-4.

4.

Verify network and SMTP connectivity with the remote voice messaging system. See the Verifying
Connectivity with the Remote Voice Messaging System section on page 4-5.

5.

Create the VPIM locations for each remote voice messaging system. See the Creating VPIM
Locations section on page 4-6.

6.

Create VPIM contacts for each VPIM location. See the Creating VPIM Contacts section on
page 4-7.

7.

Optionally, customize the contact creation settings for each VPIM location. See the Customizing
VPIM Contact Directory Update Settings section on page 4-11.

8.

Optionally, add an alternate name for each VPIM location. See the Adding Alternate Names for
Each VPIM Location section on page 4-14.

9.

Set up the remote voice messaging system for VPIM. Precisely how this is done depends on the
voice messaging system. However, you need to provide the remote system with information about
Connection. See the Gathering Information About Cisco Unity Connection to Configure Another
Voice Messaging System for VPIM section on page 4-15.

10. Test the setup to verify that Connection can exchange messages with the remote voice messaging

system.

Networking Guide for Cisco Unity Connection Release 9.x

4-2

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Procedures for Setting Up Cisco Unity Connection 9.x to Use

VPIM Networking
This section contains all of the procedures necessary to set up Cisco Unity Connection for VPIM
Networking. See the following sections:

Making Design Decisions and Gathering Needed Information, page 4-3

Determining the Domain Name, page 4-4

Resolving Names with IP Addresses, page 4-4

Verifying Connectivity with the Remote Voice Messaging System, page 4-5

Creating VPIM Locations, page 4-6

Customizing VPIM Locations, page 4-6

Creating VPIM Contacts, page 4-7

Customizing VPIM Contact Directory Update Settings, page 4-11

Adding Alternate Names for Each VPIM Location, page 4-14

Gathering Information About Cisco Unity Connection to Configure Another Voice Messaging
System for VPIM, page 4-15

For detailed explanations of VPIM Networking concepts, see the VPIM Concepts in Cisco Unity
Connection 9.x section on page 4-16.

Making Design Decisions and Gathering Needed Information

Before you begin setting up Cisco Unity Connection for VPIM Networking, be sure to plan for the
following, and gather the applicable information:

Review your numbering plan strategy to determine whether you need to enter prefixes on the VPIM
location and to determine which numbers to assign as Dial IDs for the VPIM locations.
We recommend the following policies:
Establish a fixed length for Dial IDs and, if possible, a fixed length for extensions.
Assign unique Dial IDs. Dial IDs should not be the same as other Dial IDs or extensions.
Assign Dial IDs that have at least three digits.
Use a different number range for Dial IDs than for extensions. Do not use Dial IDs that conflict

with extensions, such as 001 or 002.

If you use variable-length Dial IDs, the first digits of each ID should be unique with respect to

other Dial IDs.

Review your partition and search space configuration to determine the partition and search scope
you use for each VPIM location. For more information, see the Search Spaces and VPIM
Locations section in the Managing Partitions and Search Spaces in Cisco Unity Connection 9.x
chapter of the System Administration Guide for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsagx
.html.

Networking Guide for Cisco Unity Connection Release 9.x

4-3

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Decide for each remote voice messaging system whether to allow Connection to automatically
create, modify, and delete VPIM contact records for users on that system, based on information
received from incoming VPIM messages. Also decide how to map the source information to VPIM
contact display names and extensions.

Decide for each remote voice messaging system whether to allow Connection users to blind address
messages to recipients at the location.

Make note of the following information about the remote voice messaging system: the mailbox
range, the server name, the domain name, and the IP address.

Determining the Domain Name

VPIM messages are addressed in the format <Mailbox Number>@<Domain Name>. In order for
messages to be exchanged between the remote voice messaging system and Cisco Unity Connection, you
need to decide on the domain name that the remote voice messaging system uses when addressing
messages to Connection users. The domain name is configured as follows:

On the remote voice messaging system, the domain name is configured on the location or node
profile that corresponds to Connection. (For additional information, see the documentation for the
remote voice messaging system.)

In the SMTP Domain field, on the System Settings > SMTP Configuration > SMTP Server
Configuration page in Cisco Unity Connection Administration.

If the remote voice messaging system location or node profile that corresponds to Connection has
already been configured with a domain name, use that domain name in the procedures in this section.

Domain Name Requirements

The domain name uniquely identifies the voice messaging system. When choosing domain names used
by Connection and the remote voice messaging system, keep the following in mind:

Caution

Connection and the remote voice messaging system cannot use the same domain name. Each system
must use a unique domain name.

The complete domain name used by Connection cannot be a subset of the domain name used by the
remote voice messaging system. For example, if Connection is using the domain name cisco.com,
the remote voice messaging system cannot use names like london.cisco.com, paris-cisco.com, or
romecisco.com. However, you could use europe.cisco.com for Connection, and then use the names
london.cisco.com, paris-cisco.com, and romecisco.com for the remote voice messaging systems.

Choosing a domain name that does not meet these requirements will result in message delivery failure.

Resolving Names with IP Addresses

VPIM messages are sent over the Internet or any TCP/IP network via SMTP. Therefore, a mechanism
for name resolution is required for the remote voice messaging server. The supported method for name
resolution is through a Domain Name System (DNS).
You need to know the fully qualified domain name (FQDN) and IP address of the remote voice
messaging server. The FQDN is displayed on the System Settings > SMTP Configuration > Server page.

Networking Guide for Cisco Unity Connection Release 9.x

4-4

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Add a host address resource (A) record and a mail exchange (MX) record in DNS for the remote voice
messaging server, if they do not already exist.
For more information about adding A and MX records in DNS, see the documentation for the DNS
server.

Verifying Connectivity with the Remote Voice Messaging System

Verify that the servers that handle outgoing and incoming SMTP messages have network connectivity
with the remote voice messaging server, and vice versa.
For networking with another voice messaging server, you may need to install and configure an SMTP
service or gateway on that server. See the documentation of the other voice messaging system for
information on installing the SMTP service or gateway. Before proceeding, verify that the SMTP service
or gateway has been installed on the other voice messaging server.
To Verify Network Connectivity with the Remote Voice Messaging Server
Step 1

By using a computer on the same local network segment as the Connection server, open a command
prompt window.

Step 2

Enter ping <IP address>, where <IP address> is the IP address of the remote voice messaging server,
then press Enter.
If you receive no reply, troubleshoot the network connectivity problem until the problem is resolved.
Then continue with Step 3.

Step 3

Enter ping <Domain name> where <Domain name> is the domain name that is used to address
messages to the remote voice messaging server. The domain name in this step is the domain name that
is entered for the VPIM location in Cisco Unity Connection Administration when setting up VPIM
Networking.

Step 4

If you received a reply when pinging the IP address in Step 2, but no replies when pinging the domain
name in Step 3, see the Resolving Names with IP Addresses section on page 4-4. When the problem
is resolved, continue with Step 5.

Step 5

Test network connectivity in the opposite direction. For systems other than Connection, see the
documentation for information on how to conduct the test, and continue with Step 6. Note that the
remaining steps in this procedure may not exactly match the steps necessary for your system, so you may
need to make adjustments.

Step 6

On the remote server, ping the IP address of the local server that handles incoming SMTP messages.
If you receive no reply, troubleshoot the network connectivity problem until the problem is resolved.
Then continue with Step 7.

Step 7

On the remote server, ping the domain name, where the domain name is the one that is discussed in the
Determining the Domain Name section on page 4-4.

Step 8

If pinging by domain name fails, see the Resolving Names with IP Addresses section on page 4-4.

Note

Optionally, you can verify network connectivity by using the utils network ping CLI command.

Networking Guide for Cisco Unity Connection Release 9.x

4-5

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

To Verify SMTP Connectivity with the Remote Voice Messaging Server

Step 1

By using a computer on the same local network segment as the Connection server, open a command
prompt window

Step 2

Enter telnet <servername> 25, where <servername> is the IP address or the FQDN of the SMTP server
using TCP port 25.

Step 3

Press ENTER after each command.

Step 4

If remote messaging server is connected to SMTP, you receive 220 response with the FQDN of the server
and the version of SMTP.

Step 5

If the telnet test was successful, enter quit to end the telnet session.

Creating VPIM Locations

Create a VPIM location on Cisco Unity Connection for each remote voice messaging system to which
users send messages. If Connection will message with a large number of voice messaging systems, you
may prefer to configure only a few VPIM locations at this time and proceed with the rest of the setup.
After verifying that messaging works correctly between Connection and the voice messaging systems
for which VPIM locations have been configured, you can create the rest of the VPIM locations.
To Create VPIM Locations
Step 1

In Cisco Unity Connection Administration, expand Networking, then select VPIM.

Step 2

On the Search VPIM Locations page, select Add New.

Step 3

On the New VPIM Location page, enter basic settings, as applicable. (For field information, on the Help
menu, select This Page.)

Note

Fields marked with * (an asterisk) are required.

Step 4

Select Save.

Step 5

On the Edit VPIM Location page, continue entering applicable settings.

Step 6

When you have finished entering settings on the Edit VPIM Location page, select Save.

Customizing VPIM Locations

You can customize a VPIM location by using Cisco Unity Connection Administration for each remote
voice messaging system to which users send messages.
To Customize VPIM Locations
Step 1

In Cisco Unity Connection Administration, expand Networking, then select VPIM.

Networking Guide for Cisco Unity Connection Release 9.x

4-6

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Step 2

On the Search VPIM Locations page, select the display name for the VPIM location that you want to
customize.

Step 3

On the Edit VPIM Location page, change settings, as applicable. (For field information, on the Help
menu, select This Page.)

Step 4

When you have finished changing settings on the Edit VPIM Location page, select Save.

Creating VPIM Contacts

You may prefer to create only a few VPIM contacts at this point, for testing purposes, until you verify
that Cisco Unity Connection and the remote voice messaging system can successfully exchange
messages. After you have confirmed that messaging between Connection and the remote voice
messaging system is working correctly, you can finish creating the VPIM contacts. Note that you must
first create VPIM locations before creating VPIM contacts, and the VPIM contacts must be created on
the same Connection server on which you created the VPIM locations.
You can create VPIM contacts by using the Bulk Administration Tool or by using Cisco Unity
Connection Administration. See the following sections:

Using the Bulk Administration Tool to Create Multiple VPIM Contacts, page 4-7

Correcting CSV Errors, page 4-9

Using Cisco Unity Connection Administration to Create VPIM Contacts, page 4-9

After Creating VPIM Contacts, page 4-11

Using the Bulk Administration Tool to Create Multiple VPIM Contacts

The Bulk Administration Tool (BAT) allows you to create multiple VPIM contacts at the same time by
importing contact data from a comma-separated value (CSV) file. CSV is a common text file format for
moving data from one data store to another.
Use the following procedure to prepare your CSV file.
To Prepare a CSV File for Creating VPIM Contacts
Step 1

Save the data that you will use to create VPIM Contacts as a CSV file.
As a best practice, do not include more than 7,500 records in a single CSV file, as you may encounter
unexpected results when the Bulk Administration Tool imports the data.

Step 2

Copy the CSV file to the applicable directory.

Step 3

Open the CSV file in a spreadsheet application or another application with which you can edit and
reorganize the data. Do the following:

Confirm that the data is separated by commas, and that no tabs, spaces, or semicolons separate the
data in the file.

If any data includes a space, quotation marks, or commas, contain the characters within quotation
marks.

Networking Guide for Cisco Unity Connection Release 9.x

4-7

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Step 4

Rearrange the data so that the columns are in the same order as the column headers that you will add in
Step 5. The order of the column headers does not matter, though it is good practice to set up your CSV
file as indicated here. For example, the columns of data in this sample are sorted so that the alias of the
contact is followed by the last name, the first name, the extension, the remote mailbox ID
(RemoteMailAddress), and then by VPIM location (DeliveryLocationDisplayName):
aabade,Abade,Alex,2001,3000,Chicago VMS VPIM Location
kbader,Bader,Kelly,2002,3100,Chicago VMS VPIM Location
tcampbell,Campbell,Terry,2003,3200,Chicago VMS VPIM Location
lcho,Cho,Li,2004,3300,Chicago VMS VPIM Location

Note

Step 5

The only required column headers for creating contacts are Alias and Extension. However, in
order to create VPIM contacts you must also include columns for the remote mailbox ID and the
VPIM location.

Enter the column headers above the first row of data. Column headers must be separated by commas,
and spelled as indicated below:
Alias,LastName,FirstName,Extension,RemoteMailAddress,DeliveryLocationDisplayName

Step 6

If applicable, add optional column headers to the first row, and the corresponding data that you want to
import in the subsequent rows below. As you do so, confirm the following:

Column headers and data are separated by commas. Note that every row does not have to contain
data for optional column headers.

Any data that includes a space, quotation marks, or commas is contained within quotation marks.

Tip

Include a column with the ListInDirectory header and a value of 1 for each contact if you would
like users to be able to address messages to VPIM contacts the same way that they address
messages to regular Connection usersby extension or by spelling the name of the recipient.
For a list of optional column headers, see the Required and Optional CSV Fields for Contacts
table in the Using the Cisco Unity Connection 9.x Bulk Administration Tool appendix of the
User Moves, Adds, and Changes Guide for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/user_mac/guide/9xcucmacx.
html.

Step 7

If your CSV file contains columns of data that you do not want to import, delete the columns.
Alternatively, you can title one column NOTES. The BAT ignores data beneath any NOTES column
header, but it does not support more than one NOTES column in a CSV file.

Step 8

Confirm that each row contains the appropriate data corresponding to each column header.

Step 9

Save the file as a CSV file.

Step 10

Continue with the following To Create VPIM Contacts by Using the Bulk Administration Tool
procedure.

To Create VPIM Contacts by Using the Bulk Administration Tool

Step 1

In Cisco Unity Connection Administration, expand Tools, then select Bulk Administration Tool.

Step 2

On the Bulk Administration Tool page, under Select Operation, select Create.

Networking Guide for Cisco Unity Connection Release 9.x

4-8

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Step 3

Under Select Object Type, select System Contacts.

Step 4

Under Select File, select Browse.

Step 5

In the Choose File dialog box, browse to the directory where you saved the CSV file that you created in
the To Prepare a CSV File for Creating VPIM Contacts procedure on page 4-7 and select Open.

Step 6

In the Failed Objects File Name field, enter the path and the name of the file in which you want errors
recorded.

Step 7

Select Submit.

Correcting CSV Errors

The failed objects file contains data that failed to create a VPIM contact. The Bulk Administration Tool
reports the first error it detects in a row in a CSV file. When you have corrected that error, the BAT may
detect additional errors in the same row when the data is imported again. Thus, you may need to repeat
the correction processrunning the BAT and correcting an errorseveral times to find and correct all
errors.
The failed objects file contains all the records that failed to create a VPIM contact. You can save the file
as a CSV file, and use it when you run the BAT again. Note that each time you run the BAT, the failed
objects file is overwritten.
To Correct CSV Errors That Occurred When Creating VPIM Contacts
Step 1

If the Bulk Administration Tool operation results in any failures, you can immediately inspect the failed
objects report file by selecting Download the Failed Objects File.

Step 2

Open the file and correct all problems with the data, as indicated by the information in the FailureReason
column for each record.

Step 3

Remove the FailureReason column or change the heading to JUNK.

Step 4

When you have finished modifying the data, save the file as a CSV file with a new name.

Step 5

Run the BAT again with the CSV file that you saved in Step 4 as the input file.
Note that each time that you run BAT, the failed objects file is overwritten (unless you specify a new
name for the file each time you run the tool).

Step 6

Repeat this procedure until all VPIM contact accounts are created without error, and then proceed to the
After Creating VPIM Contacts section on page 4-11.

Using Cisco Unity Connection Administration to Create VPIM Contacts

You can create VPIM contacts one at a time by using Cisco Unity Connection Administration.
To Create VPIM Contacts by Using Cisco Unity Connection Administration
Step 1

In Cisco Unity Connection Administration, expand Contacts, then select Contacts.

Step 2

On the Search Contacts page, on the Contact menu, select New Contact.

Step 3

On the New Contact page, enter the following settings and select Save.

Networking Guide for Cisco Unity Connection Release 9.x

4-9

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Table 4-1

Step 4

Settings for the New Contact Page

Field

Setting

Alias

Enter the alias of the VPIM contact.

First Name

Enter the first name of the VPIM contact.

Last Name

Enter the last name of the VPIM contact.

Display Name

Enter the display name of the VPIM contact.

Contact Template

Select the template on which to base the VPIM contact.

On the Edit Contact Basics page, enter the following settings and select Save.
Table 4-2

Settings for the Edit Contact Basics Page

Field

Setting

Voice Name

Select Play/Record to record a name for the VPIM contact.

List in Directory

Check this check box to list the VPIM contact in the Connection directory.

Partition

Select the partition to which the VPIM contact belongs. Partitions are
grouped together into search spaces, which are used to define the scope of
objects (for example, users and distribution lists) that a user or outside caller
can reach while interacting with Connection. A VPIM contact can belong to
only one partition. A partition can belong to more than one search space.

Transfer Enabled

(Optional) Check this check box if you want Connection to transfer incoming
calls to a phone number that is associated with the VPIM contact instead of
sending a message to the remote mailbox for the VPIM contact.

Transfer Extension

(Optional) Enter the phone number that the phone system uses to transfer
calls to the VPIM contact, including any outdial access codes, if necessary.
This field works together with the Transfer Enabled field.

Delivery Location

Select the VPIM location for the VPIM contact.

VPIM Remote Mailbox Enter the mailbox number for the VPIM contact on the remote voice
messaging system.
Number
Local Extension

(Optional) For VPIM contacts, you can assign a local extension that fits into
the Connection extension numbering scheme. A local extension allows
callers to address messages to the VPIM contact by using an extension, rather
than having to know the location ID and the remote mailbox number of the
contact.
In addition, if you set the Transfer Enabled and Transfer Extension fields,
callers are able to identify and be transferred to the VPIM contact.

Networking Guide for Cisco Unity Connection Release 9.x

4-10

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Table 4-2

Settings for the Edit Contact Basics Page (continued)

Field

Setting

Phone Numbers to Call (Optional) Use the Dialed Work Phone, Dialed Home Phone, and Dialed
Contact by Using Voice Mobile Phone fields when you want voice recognition users to be able to call
Commands
the VPIM contact by specifying a specific phone type for the contact.
For dialed phone numbers, include any additional numbers necessary to dial
outside calls (for example 9) and for long-distance dialing (for example, 1).
Phone Numbers to
Identify Contact for
Personal Call Transfer
Rules
Step 5

(Optional) Use the Work Phone, Home Phone, Mobile Phone, Other
Number 1, and Other Number 2 fields to enter phone numbers that
Connection uses when matching the personal call transfer rules of a user
against incoming phone calls from system contacts.

Repeat Step 2 through Step 4 for all remaining VPIM contacts that you want to create.

After Creating VPIM Contacts

After creating VPIM contacts, consider the following:

It takes a few minutes for the newly-created VPIM contact to be available to receive messages.

You can make changes to settings for individual VPIM contacts in Cisco Unity Connection
Administration.

When you want to modify unique VPIM contact settingssuch as the extensionfor multiple
contacts at once, you can rerun the Bulk Administration Tool.

When a VPIM contact no longer needs a Connection account, you can delete the VPIM contact. For
details, see the Deleting VPIM Contacts in Cisco Unity Connection 9.x section on page 4-15.

Customizing VPIM Contact Directory Update Settings

In addition to manually creating, modifying, and deleting VPIM contacts, you can configure Cisco Unity
Connection to automatically update records in the VPIM contact directory based on information that is
contained in incoming VPIM messages. The settings that control whether the creation, modification, and
deletion actions occur automatically, and how the incoming information is used to create or modify a
record, can be individually configured for each VPIM location. By default, no automatic directory
updates occur for any VPIM locations.
Depending on the Contact Creation settings that you select for each VPIM location, Connection uses
information from the header of an incoming VPIM message. If a VPIM message is received from a
sender on a VPIM location that is configured to allow automatic VPIM contact creation, and no existing
VPIM contact matches the information of the sender, a new VPIM contact record is created, provided
that the VPIM message contains:

A phone number

A text name

A domain name

A recorded name (when required, based on the VPIM location configuration)

Networking Guide for Cisco Unity Connection Release 9.x

4-11

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Additional Contact Creation settings allow you to specify how to map the parsed text name of the VPIM
contact to a first name, last name, and display name, and how to map the phone number to an extension.

Note

Changes to the Map VPIM Contact Extensions setting on the Contact Creation page for a VPIM location
affect only VPIM contacts that are created after the setting is saved. VPIM contacts that already existed
before the Map VPIM Contact Extensions setting is changed are not automatically updated. You must
manually change the extension for each previously existing VPIM contact for that VPIM location.
If a VPIM message is received from a sender on a VPIM location that is configured to allow automatic
VPIM contact modification, and an existing VPIM contact matches the sender information, the VPIM
contact can be updated. You can choose whether VPIM contact information is updated each time a
message is received from a VPIM contact, or only when a message is received from a VPIM contact
whose text name has changed since the directory entry was created. You can also decide whether or not
to allow an update to the display name when a modification is made.
If a message from a Connection user to a VPIM contact results in a non-delivery receipt (NDR),
indicating that the message was undeliverable because the intended recipient does not exist
(SMTP 5.1.1), and if the VPIM location is configured to allow automatic VPIM contact deletion, the
VPIM contact is deleted.
You can update the VPIM location contact creation settings by using Cisco Unity Connection
Administration. See the following sections:

Before Configuring VPIM Contact Creation Settings, page 4-12

Using Cisco Unity Connection Administration to Configure VPIM Contact Creation Settings,
page 4-13

Before Configuring VPIM Contact Creation Settings

Before configuring the VPIM location contact creation settings, consider the following:

If you have pre-populated VPIM contacts with specific display names that should not be changed,
but want to allow automatic modification of other fields in the contact record, you can choose to
keep the Allow VPIM Contact Display Name Updates check box unchecked. In this case, the first
name, last name, and spoken name of a contact may be modified during an automatic update. This
may result in a mismatch if the spoken name is updated and the display name is not.

When the Allow VPIM Contacts Without Recorded Voice Names check box is not checked, new
VPIM contacts are not created for incoming messages that do not contain an
Originator-Spoken-Name attachment. In addition, if automatic modification of VPIM contacts is
enabled, and if the sender of an incoming message matches an existing VPIM contact, the VPIM
contact is deleted if the attachment is not present in the message.

When the Allow VPIM Contacts Without Recorded Voice Names check box is checked, and
automatic modification of VPIM contacts is enabled, if the sender of an incoming message that does
not include an Originator-Spoken-Name attachment matches an existing VPIM contact, the existing
recorded name is deleted.

If the phone number in an incoming message cannot be successfully mapped to an extension by

using the option selected for the Map VPIM Contact Extensions To field, a VPIM contact is not
created for the sender.

Networking Guide for Cisco Unity Connection Release 9.x

4-12

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Using Cisco Unity Connection Administration to Configure VPIM Contact Creation Settings
After you create a VPIM location, you can configure the settings that control automatic directory updates
for that specific VPIM location by using Cisco Unity Connection Administration.
To Configure VPIM Contact Creation Settings by Using Cisco Unity Connection Administration
Step 1

In Cisco Unity Connection Administration, expand Networking, then select VPIM Locations.

Step 2

On the Search VPIM Locations page, select the name of the VPIM location for which you want to
configure contact creation settings.

Step 3

On the Edit VPIM Location page, on the Edit menu, select Contact Creation.

Step 4

On the Contact Creation page, check the Automatically Create VPIM Contacts check box to enable
automatic creation of a VPIM contact record for this location when a VPIM message arrives and the
sender does not already have a corresponding VPIM contact record.

Step 5

If you checked the Automatically Create VPIM Contacts check box in Step 4, in the Contact Template
list, select the template on which to base the automatically created contacts.

Step 6

In the Automatically Modify VPIM Contact field, select one of the following to apply to VPIM contacts
for this location:

No Automatic Update of ContactsThe VPIM contact record is not updated with the sender
information in a VPIM message when an incoming message has changed sender information.

Only When the Text Name ChangesThe VPIM contact record is updated only when the text
name received in the VPIM message does not match the name of the VPIM contact.

With Each VPIM MessageEvery incoming VPIM message from a VPIM contact at this location
results in an update to the corresponding VPIM contact record.

Step 7

Check the Automatically Delete VPIM Contact check box to enable automatic deletion of a VPIM
contact for this location when a VPIM message is returned as undeliverable.

Step 8

Check the Allow VPIM Contact Display Name Updates check box to enable automatic updates to the
VPIM contact display name when an incoming message from this location has a changed display name
for the sender.

Step 9

Check the Allow VPIM Contacts Without Recorded Voice Names check box to enable automatic
updates for this location to records for VPIM contacts that do not have a recorded name.

Step 10

In the Mapping Text Names field, select one of the following options to indicate how text names in
incoming messages from this location are mapped to the display names for automatically created VPIM
contact records:

Step 11

Directly to VPIM Contact Display NamesThe display names for VPIM contacts match the
corresponding text names.

CustomEnter the rule that defines how text names are mapped to display names for VPIM
contacts. You can enter the tokens <FN>, <LN>, or <TN> (respectively first name, last name, or text
name) in any combination, along with any additional text. Always precede <FN>, <LN>, or <TN>
with a space, comma, or semicolon unless it appears at the beginning of the rule. In addition, always
follow one of these tokens with a space, comma or semicolon unless it appears at the end of the rule.
No additional characters are required at the beginning or end of a rule.

In the Map VPIM Contact Extensions To field, select one of the following settings to indicate how the
phone number on incoming messages from this location is mapped to the extension for automatically
created VPIM contact records:

Networking Guide for Cisco Unity Connection Release 9.x

4-13

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Procedures for Setting Up Cisco Unity Connection 9.x to Use VPIM Networking

Phone NumberExtensions are the same as the phone numbers that are parsed from incoming
VPIM messages.

Phone Number - Remote Phone PrefixExtensions are formed by removing the remote phone
prefix from the beginning of the phone numbers.

Location Dial ID + Phone NumberExtensions are formed by adding the location Dial ID in front
of the phone numbers.

Location Dial ID + Phone Number - Remote Phone PrefixExtensions are formed by removing
the remote phone prefix from the beginning of the phone number, and adding the location Dial ID
in front of the resulting number.

Step 12

Select Save.

Step 13

On the VPIM Location menu, select Search VPIM Locations.

Step 14

Repeat Step 2 through Step 13 for all remaining VPIM locations.

Adding Alternate Names for Each VPIM Location

When the Cisco Unity Connection system uses the voice-recognition option, you can also specify
alternate names for the display name that you give a VPIM location. Users say the display name when
they use voice commands to blind address to a mailbox number at a VPIM location (for example, to
address to extension 55 at a VPIM location named Seattle, a user would say five five at Seattle) or to
address a message to a VPIM contact name at a VPIM location (for example, Robin Smith in Chicago).
Consider specifying alternate names if the VPIM location display name contains administrative
information that users are not likely to know, or if it is not pronounced the way it would be read, as may
be the case with acronyms and abbreviations. Also consider adding alternate names if users tend to refer
to a location in multiple ways. For example, if users at one site refer to a location as Seattle branch
and users at another site refer to the same location as Seattle office, you could add both Seattle
branch and Seattle office as alternate names.
To Add an Alternate Name for VPIM Locations
Step 1

In Cisco Unity Connection Administration, expand Networking, then select VPIM Locations.

Step 2

On the Search VPIM Locations page, select the name of the VPIM location for which you want to add
an alternate name.

Step 3

On the Edit VPIM Location page, on the Edit menu, select Alternate Names.

Step 4

On the Edit Alternate Names page, in the Display Name field, enter the alternate name you want for the
VPIM location, then select Add New.

Step 5

On the VPIM Location menu, select Search VPIM Locations.

Step 6

Repeat Step 2 through Step 5 for all remaining VPIM locations for which you want to add alternate
names.

Networking Guide for Cisco Unity Connection Release 9.x

4-14

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

Deleting VPIM Contacts in Cisco Unity Connection 9.x

Gathering Information About Cisco Unity Connection to Configure Another

Voice Messaging System for VPIM
Configuring another voice messaging system to exchange VPIM messages with Cisco Unity Connection
may require the following information:

The server name and domain name of the SMTP server that handles incoming SMTP messages.

The Connection phone prefix (if any) and Remote phone prefix (if any) entered on the corresponding
VPIM location page.

The mailbox number range for Connection users.

Incoming VPIM messages must be routed to the SMTP server. When defining a location for Connection
on the remote voice messaging system, use the domain name that you entered for the SMTP server.
Connection expects incoming VPIM messages to be formatted as follows:
<ConnectionPhonePrefix+ConnectionUserExtension@PrimaryLocationSMTPDomainName>
These specific properties are configured in Connection, but similar information needs to be configured
in the other voice messaging system.

Deleting VPIM Contacts in Cisco Unity Connection 9.x

To Delete VPIM Contacts
Step 1

In Cisco Unity Connection Administration, expand Contacts, then select Contacts.

Step 2

On the Search Contacts page, check the check boxes next to the VPIM contacts that you want to delete.

Step 3

Select Delete Selected.

Step 4

When prompted to confirm the deletion, select OK.

Removing a VPIM Location in Cisco Unity Connection 9.x

When you remove a VPIM location, you must remove (or reassign) any contacts and contact templates
that use the location before deleting the VPIM location object. Use the following task list to remove a
VPIM location.
1.

Use the Bulk Administration Tool to export a list of all administrator-defined contacts. See the
Exporting Contacts to a CSV File section in the Using the Cisco Unity Connection 9.x Bulk
Administration Tool appendix of the User Moves, Adds, and Changes Guide for Cisco Unity
Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/user_mac/guide/9xcucmacx.htm
l.

2.

Download the export file, and use a text editor to modify it to contain only the rows in which the
DeliveryLocationDisplayName matches the display name of the VPIM location that you are
removing. (If you plan to reassign the contacts to a different VPIM location, update the value in the
DeliveryLocationDisplayName column.)

Networking Guide for Cisco Unity Connection Release 9.x

4-15

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

VPIM Concepts in Cisco Unity Connection 9.x

3.

Use the Bulk Administration Tool to delete the list of contacts you generated in Task 2. See the
Deleting Contacts section in the Using the Cisco Unity Connection 9.x Bulk Administration
Tool appendix of the User Moves, Adds, and Changes Guide for Cisco Unity Connection Release
9.x.
Alternatively, to reassign the contacts to a different VPIM location, use the Update option. See the
Updating Contacts section in the Using the Cisco Unity Connection 9.x Bulk Administration
Tool appendix of the User Moves, Adds, and Changes Guide for Cisco Unity Connection Release
9.x.

4.

In Cisco Unity Connection Administration, expand Templates, then select Contact Templates. If a
contact template is configured to use the VPIM location as the delivery location, change the delivery
location, or delete the template. (You may need to select the display name of each template on the
Search Contact Templates page to verify or change the delivery location.)

5.

To delete the location, in Connection Administration, expand Networking, then select VPIM
Locations. On the Search VPIM Locations page, check the check box next to the display name of
the location that you want to delete, then select Delete Selected.

VPIM Concepts in Cisco Unity Connection 9.x

The following sections explain VPIM concepts in detail:

VPIM Messages, page 4-16

VPIM Addresses, page 4-17

Message Addressing Options, page 4-18

Messaging Similarities and Limitations, page 4-18

Audio Format Considerations, page 4-18

VPIM Messages
VPIM messages are made up of one or more MIME-encoded parts. The VPIM specification allows for
optional MIME parts for spoken name and for forwarded and text messages. Cisco Unity Connection
does not, however, support sending or receiving a vCard (an electronic business card that includes phone
number, text name, and email address). If a vCard is attached to an outgoing or incoming message,
Connection removes the vCard data. In addition, any attachments to messages other than the voice
message and embedded messages are removed from outgoing and incoming messages.
Connection allows you to specify whether the recorded name of the sender is sent with outgoing
messages. If incoming messages include a recorded name, it is played as part of the message. Connection
can also be configured to update the directory with information from the header from incoming
messages.
Outgoing messages to a VPIM location do not include any recipients other than those at the VPIM
location. Therefore, when a VPIM recipient replies to all addressees on a message, the reply will go only
to the sender and to any other recipients at the same VPIM location.
Figure 4-1 shows a sample VPIM message. Only a portion of the MIME encoding of the spoken name
and voice message parts are shown because they are very long.

Networking Guide for Cisco Unity Connection Release 9.x

4-16

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

VPIM Concepts in Cisco Unity Connection 9.x

Figure 4-1

Sample VPIM Message

Date: Fri, 09 Feb 2007 17:39:03 GMT

From: Kelly Bader <[email protected]>
To: [email protected]
MIME-Version: 1.0 (Voice 2.0)
Content-Type: Multipart/Voice-Message; Version=2.0
Boundary=MessageBoundary
Content-Transfer-Encoding: 7bit
Message-ID:123456789
Subject: Testing
Sensitivity: Private
Importance: High
--MessageBoundary
Content-Type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321

From Address
To Address

Spoken Name

glsfldslsertiflkTlpgkTportrpkTpfgTpoiTpdadasssdadasdasd
<< The rest of the MIME encoding of the spoken name has been deleted. >>
fghgddfkgpokpeowrit09==

Voice Message

u7wjOyRhws+krdns7Rju0t4tLF7cE0KoMxOTOnRWPn30c8uH9
<< The rest of the MIME encoding of the voice message has been deleted. >>
7/8e)Q==

191734

--MessageBoundary
Content-Type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Description: VPIM Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
Content-Duration: 25

VPIM Addresses
A VPIM address is in the same format as a typical SMTP email address: localpart@hostpart. The
right-hand side of the address is the domain name of the system on the TCP/IP network that handles
messages. The left-hand side of the address is a unique identifier for the user. Typically, the left-hand
side is the user mailbox number or the mailbox number with a prefix.
For example, an outgoing VPIM message to Terry Campbell with the remote mailbox ID 2233 could be
addressed:
To: [email protected]
If it is necessary to accommodate the numbering plan for your organization, the address can also contain
a prefix:
To: [email protected]
VPIM addresses are created by Cisco Unity Connection when sending VPIM messages; they are not
entered by users when addressing messages.

Networking Guide for Cisco Unity Connection Release 9.x

4-17

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

VPIM Concepts in Cisco Unity Connection 9.x

Message Addressing Options

Cisco Unity Connection provides the following ways to address messages to individuals on a remote
voice messaging system:

Connection directoryWhen the List in Directory check box is checked for VPIM contacts, the
Connection directory has the names and extensions for the VPIM contacts. Users can address
messages to VPIM contacts the same way that they address messages to regular Connection
usersby extension or by spelling the name of the recipient. Note that spoken name confirmation
is available when a recorded name exists for the VPIM contact; if the contact does not have a
recorded name, Connection uses Text to Speech to play the display name of the contact.

Blind addressingBlind addressing allows users to send messages to recipients at the VPIM
location even if the recipients are not defined as contacts in the Connection directory. If the Allow
Blind Addressing check box is checked on the VPIM Location page, users can address messages to
recipients at this location by entering a number that is made up of the VPIM location Dial 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).

Distribution listsUsers can address messages to a private or system distribution list that includes
VPIM contacts so that the VPIM contact receives the message.

Messaging Similarities and Limitations

For the most part, messaging between Cisco Unity Connection users and individuals on a remote voice
messaging system is the same as messaging among Connection users. For example:

Messages marked urgent when they are sent are marked urgent when they are retrieved by the
recipient.

Messages marked private when they are sent are marked private when they are retrieved by the
recipient.

Users can send messages to Connection distribution lists that include VPIM contacts.

Note the following exceptions:

Requests for read receipts and delivery receipts are both returned as delivery receipts.

In order for users on the remote voice messaging system to send messages to Connection distribution
lists, the Accept Messages From Foreign System check box must be checked on the Edit Distribution
List Basics page in Connection Administration. This check box is not checked by default.

Audio Format Considerations

The Audio Format Conversion settings for the VPIM location (on the Networking > Edit VPIM Location
page in Cisco Unity Connection Administration) allow you to control the audio format of outgoing and
incoming VPIM messages, as follows:

Incoming MessagesYou can set whether incoming VPIM messages are stored in the format in
which they were sent, or converted to the audio format that Cisco Unity Connection uses for
recording messages.

Outbound MessagesYou can set whether outbound VPIM messages are sent in the format in which
they were recorded, or converted to the G.726 codec.

Networking Guide for Cisco Unity Connection Release 9.x

4-18

Chapter 4

VPIM Networking in Cisco Unity Connection 9.x

VPIM Concepts in Cisco Unity Connection 9.x

To make decisions about these settings, consider the following:

The audio format that the local Connection server uses for recording and playing voice messages.

The audio format in which the remote voice messaging system can send and receive VPIM
messages. Some voice messaging systems support only the G.726 format for VPIM messages, but
you must consult the documentation of the remote voice messaging server to be sure.

The network bandwidth.

We recommend that incoming VPIM messages be stored in the same audio format that the local
Connection server uses for recording and playing messages.

Networking Guide for Cisco Unity Connection Release 9.x

4-19

Chapter 4
VPIM Concepts in Cisco Unity Connection 9.x

Networking Guide for Cisco Unity Connection Release 9.x

4-20

VPIM Networking in Cisco Unity Connection 9.x

CH A P T E R

Making Changes to the Networking

Configuration in Cisco Unity Connection 9.x
See the following sections:

Removing a Location From a Cisco Unity Connection 9.x Site, page 5-1

Making Changes to a Cisco Unity Connection 9.x Site Gateway, page 5-3

Making Changes to a Cisco Unity Site Gateway, page 5-3

Removing an Intersite Link Between a Cisco Unity Connection 9.x Site and a Cisco Unity Site,
page 5-4

Removing an Intersite Link Between Two Cisco Unity Connection 9.x Sites, page 5-6

Removing a Location From a Cisco Unity Connection 9.x Site

When you remove a location from a Cisco Unity Connection site, it stops replicating directory
information with other locations, and all objects that are homed on the server are removed from other
locations. Likewise, all objects that are homed on other locations on the site are removed from the server
you are removing.
We recommend that you carefully consider the impacts of removing a location from the site prior to
doing so, particularly if you plan to add the location back to the site later. Consider the following
impacts:

Users on the server are removed from distribution lists that are homed on other locations in the site,
and users on other locations are removed from distribution lists that are homed on the server you
remove. If you later add the server back into the site, you need to update distribution list membership
on the re-added server to include any remote users, and update distribution list membership on all
other locations in the site to include users on the re-added server.

System call handlers and interview handlers on other locations that are configured to send messages
to a user or distribution list that is homed on the server you remove are reconfigured to send
messages to the undeliverable messages list of the location. Likewise, system call handlers and
interview handlers on the server you remove that are configured to send messages to a user or
distribution list that is homed on another location are reconfigured to send messages to the local
undeliverable messages list. If you later add the server back into the site, you need to update the
recipients for these handlers to use the correct remote object. (Even if you do not plan to add the
server back into the site, you should make sure that someone is checking messages that are sent to
the undeliverable messages list, or reassign handlers that use it as a recipient.)

Networking Guide for Cisco Unity Connection Release 9.x

5-1

Chapter 5

Making Changes to the Networking Configuration in Cisco Unity Connection 9.x

Removing a Location From a Cisco Unity Connection 9.x Site

Partitions that are homed on the server are removed from search spaces that are homed on other
locations in the site, and partitions that are homed on other locations are removed from search spaces
that are homed on the server you remove. If you later add the server back into the site, you need to
review the partition membership of search spaces on the re-added server and on all other locations
in the site. Depending on the version of Connection on the server and the search space configuration,
you may need to manually re-add remote partitions to each search space, or you may need to reorder
the partitions within the search space to match the configuration that you had prior to removing the
location.

One location in the site retains a copy of search spaces that are homed on the server being removed,
and the copy continues to be replicated amongst remaining locations in the site. Likewise, the server
being removed makes a copy of remote search spaces that are homed on other locations. The copies
replace the original search spaces on any objects that reference them. If you later add the server back
into the site, Connection will automatically attempt to resolve the ownership of the search space
copies to their original location and will then delete the copies. If you do not plan to add the server
back into the site, you can reassign object references that use the search space copies to use other
search spaces, and then delete the copies.

One location in the site retains a copy of search spaces that are homed on the server being removed,
and the copy continues to be replicated amongst remaining locations in the site. Likewise, the server
being removed makes a copy of remote search spaces that are homed on other locations. The copies
replace the original search spaces on any objects that reference them. If you later add the server back
into the site, Connection will automatically attempt to resolve the ownership of the search space
copies to their original location and will then delete the copies. If you do not plan to add the server
back into the site, you can reassign object references that use the search space copies to use other
search spaces, and then delete the copies.

On each location in the site, there are configuration settings specific to other locations (for example,
the fields related to cross-server transfers and SMTP routing). When you remove a server from the
site, the settings for all locations in the site are deleted from the server that you remove, and the
settings for the server that you remove are deleted from all other locations in the site. If you later
add the server back into the site, you need to update the settings for the re-added server on all other
locations in the site, and configure the settings for all other locations on the re-added server.

If the location is part of a Cisco Voicemail Organization, all of the impacts listed above also apply
for those objects and object properties that are replicated to and from the remote site.

Do the following procedure to remove a location from the site. You can remove only one Connection
location from a site at a time.
Depending on the size of the directory, removing a Connection location can take a few minutes to a few
hours. Even though the operation may have completed on the local location, it may continue to be in
progress on remote locations. We recommend that you wait for the removal operation to complete on all
locations in the site before making additional changes to the site.
To Remove a Location From a Cisco Unity Connection Site
Step 1

In Cisco Unity Connection Administration on any location in the site, expand Networking, select Links
and then select IntraSite Links.

Step 2

Check the check box to the left of the Display Name of the location that you want to remove.

Step 3

Select Remove Selected.

Step 4

Select OK to confirm the removal.

Networking Guide for Cisco Unity Connection Release 9.x

5-2

Chapter 5

Making Changes to the Networking Configuration in Cisco Unity Connection 9.x

Making Changes to a Cisco Unity Connection 9.x Site Gateway

Caution

Until Connection Administration returns a status message indicating that the removal is
complete, avoid making other changes on the site (for example, removing another location,
joining a new location to the site, creating an intersite link to another site, or initiating a
directory push or pull).

Making Changes to a Cisco Unity Connection 9.x Site Gateway

The following changes are not supported on a Cisco Unity Connection site gateway unless you unlink
the gateway from the remote site, remove the gateway from the local site, make the change, add the
gateway back to the local site, and relink the sites:

Replacing the site gateway server or hard disks.

Changing the IP address of the site gateway.

Renaming the site gateway.

To make any of these changes, do the following tasks:

1.

Remove the intersite link. Depending on the type of site the gateway is linked to, see either the
Removing an Intersite Link Between Two Cisco Unity Connection 9.x Sites section on page 5-6
or the Removing an Intersite Link Between a Cisco Unity Connection 9.x Site and a Cisco Unity
Site section on page 5-4.

2.

If there are other locations in the Connection site, remove the site gateway from the site. See the
Removing a Location From a Cisco Unity Connection 9.x Site section on page 5-1.

3.

Make the change on the site gateway server according to the instructions in the Reconfiguration and
Upgrade Guide for Cisco Unity Connection Release 9.x, available at
http://www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/upgrade/guide/9xcucrugx.html.

4.

If there are other locations in the Connection site, add the Connection site gateway back into the site.
See the Setting Up a Cisco Unity Connection 9.x Site section on page 2-1.

5.

Relink the sites. Depending on the type of site the gateway was linked to, see either the Linking
Two Cisco Unity Connection 9.x Sites section on page 2-16 or the Setting Up an Intersite Link
Between Cisco Unity and Cisco Unity Connection 9.x Gateways section on page 3-1.

Making Changes to a Cisco Unity Site Gateway

The following changes are not supported on a Cisco Unity site gateway unless you unlink the gateway
from the Cisco Unity Connection site, make the change, and relink the sites:

Renaming the site gateway or moving it to another domain.

Changing the IP address of the site gateway.

Replacing the site gateway server or upgrading it to Windows 2003.

Converting the primary or secondary server in a failover pair to a server without failover.

To make these changes, first follow the steps in the Removing an Intersite Link Between a Cisco Unity
Connection 9.x Site and a Cisco Unity Site section on page 5-4. Then, make the change according to
the instructions in the Reconfiguration and Upgrade Guide for Cisco Unity Release 9.x, available at

Networking Guide for Cisco Unity Connection Release 9.x

5-3

Chapter 5 Making Changes to the Networking Configuration in Cisco Unity Connection 9.x
Removing an Intersite Link Between a Cisco Unity Connection 9.x Site and a Cisco Unity Site

http://www.cisco.com/en/US/docs/voice_ip_comm/unity/9x/upgrade/guide/9xcurugx.html. Finally,
relink the sites according to the instructions in the Setting Up an Intersite Link Between Cisco Unity
and Cisco Unity Connection 9.x Gateways section on page 3-1.

Removing an Intersite Link Between a Cisco Unity Connection

9.x Site and a Cisco Unity Site
The process of removing an intersite link between a Cisco Unity Connection site and a Cisco Unity site
involves the following general steps:

On the Cisco Unity site gateway, unjoin the link. This stops synchronization with the Cisco Unity
Connection site and removes all Connection objects from the Cisco Unity directory.

On the Cisco Unity site gateway, remove the intersite link. This removes all configuration
information about the Connection site gateway from the Cisco Unity site gateway.

On the Cisco Unity Connection site gateway, remove the intersite link. This stops synchronization
with the Cisco Unity site, removes all Cisco Unity objects from the Connection directory, and
removes all configuration information about the Cisco Unity site gateway from the Connection site
gateway.

On the Cisco Unity site gateway, the deletion of remote site objects begins as soon as you unjoin the link.
On the Connection site gateway, the deletion of objects begins when the Remove Objects Associated
With Deleted Remote Sites task runs (by default, the operation runs at 10:00 p.m. daily).
We recommend that you carefully consider the impacts of removing an intersite link prior to doing so,
particularly if you plan to relink the sites later. Consider the following impacts:

Users and system distribution lists on each site are removed from distribution lists that are homed
on the other site. If you later relink the sites, you need to update distribution list membership to
include any remote users and distribution lists.

System call handlers and interview handlers that are configured to send messages to a remote site
user or distribution list are reconfigured according to the user deletion rules of the server.
(Cisco Unity locations do the replacement based on the Substitute Objects configuration on the
System > Configuration > Settings page in the Cisco Unity Administrator. Connection locations
replace the object with the local undeliverable messages list.) If you later relink the sites, you need
to update the recipients for these handlers to use the correct remote object. (Even if you do not plan
to relink the sites, you should make sure that someone is checking messages that are sent to a
Connection undeliverable messages list, or reassign handlers that use it as a recipient.)

Partitions that were created for Cisco Unity locations are removed from search spaces in the
Connection site. If you later relink the sites, you need to review the partition membership of the
search spaces that are owned on each Connection location. Depending on the version of Connection
on the server and the search space configuration, you may need to manually re-add the Cisco Unity
partitions to each search space, or you may need to reorder the partitions within the search space to
match the configuration that you had prior to removing the intersite link.

On each location in the site, there are cross-server configuration settings specific to other locations.
When you unlink the sites, these settings are removed. If you later relink the sites, you need to
reconfigure all location-specific settings in both sites.

All intersite messaging, addressing between sites, and intersite auto-attendant features will be
unavailable after the link is removed.

Networking Guide for Cisco Unity Connection Release 9.x

5-4

Chapter 5

Making Changes to the Networking Configuration in Cisco Unity Connection 9.x

Removing an Intersite Link Between a Cisco Unity Connection 9.x Site and a Cisco Unity Site

Do the following procedure to remove an intersite link between a Cisco Unity Connection 9.x site and a
Cisco Unity site. If you have a Cisco Unity failover pair, do the steps applicable to Cisco Unity only on
the primary server. If you have a Connection cluster, do the steps applicable to Connection only on the
publisher server.

Caution

Because server performance can be impacted by large deletion activities, we strongly recommend that
you remove the intersite link on the Cisco Unity site gateway (Step 2 in the procedure) during
non-business hours, and allow the Remove Objects Associated With Deleted Remote Sites task to run
on the default schedule (or at another time during non-business hours) on the Connection site gateway.
To Remove an Intersite Link Between a Cisco Unity Connection 9.x Site and a Cisco Unity Site

Step 1

Step 2

On the Cisco Unity site gateway, unjoin the link. This stops synchronization with the Cisco Unity
Connection site and removes all Connection objects from the Cisco Unity directory.
a.

In the Cisco Unity Administrator, select Network > Connection Networking.

b.

On the Connection Networking Profile page, in the Link section, select Unjoin.

c.

At the unjoin warning, select OK.

d.

Select OK to continue.

On the Cisco Unity site gateway, remove the intersite link. This removes all configuration information
about the Connection site gateway from the Cisco Unity site gateway.
a.

Tip
b.
Step 3

Step 4

On the Connection Networking Profile page, check the Delete check box next to the name of the
remote site gateway.

If the Delete check box is not available, wait for a minute and refresh the page.
Select the Save icon.

On the Cisco Unity Connection site gateway, remove the intersite link. This stops synchronization with
the Cisco Unity site, removes all Cisco Unity objects from the Connection directory, and removes all
configuration information about the Cisco Unity site gateway from the Connection site gateway.
a.

In Cisco Unity Connection Administration, expand Networking, expand Links, then select
Intersite Links.

b.

On the Search Intersite Links page, check the check box next to the intersite link corresponding to
the Cisco Unity site.

c.

Select Remove Selected.

d.

At the warning about deleting associated objects, select OK.

Optionally, on the Cisco Unity Connection site gateway, review the schedule for the Remove Objects
Associated With Deleted Remote Sites task. By default, to avoid affecting system performance during
business hours, this task runs at once a day at 10:00 p.m., and the intersite link is not fully removed until
the task has run.
To review the schedule, either select the link to the task that is displayed in the Status message on the
Search Intersite Links page after you have removed the selected intersite link, or expand Tools and select
Task Management; on the Task Definitions page, select Remove Objects Associated With Deleted
Remote Sites.

Step 5

Do the following procedures to verify that the link has been removed on both site gateways:

Networking Guide for Cisco Unity Connection Release 9.x

5-5

Chapter 5 Making Changes to the Networking Configuration in Cisco Unity Connection 9.x
Removing an Intersite Link Between Two Cisco Unity Connection 9.x Sites

To Verify That an Intersite Link Has Been Removed on a Cisco Unity Site Gateway, page 5-6

To Verify That an Intersite Link Has Been Removed on a Cisco Unity Connection Site Gateway,
page 5-6

To Verify That an Intersite Link Has Been Removed on a Cisco Unity Site Gateway
Step 1

In the Cisco Unity Administrator, select Network > Connection Networking.

Step 2

On the Connection Networking Profile page, if the link has not yet been removed, it is displayed in the
table at the top of the page. If the link has been removed, no entry is displayed in the table.

To Verify That an Intersite Link Has Been Removed on a Cisco Unity Connection Site Gateway
Step 1

In Cisco Unity Connection Administration on the Cisco Unity Connection site gateway, expand
Networking, expand Links, and select Intersite Links.

Step 2

On the Search Intersite Links page, if the link has not yet been removed, it is displayed in the Intersite
Links table with (Link Removal Pending) listed after the Display Name. If the Remove Objects
Associated With Deleted Remote Sites task has run and the link has been removed, no entry is displayed
in the Intersite Links table.

Removing an Intersite Link Between Two Cisco Unity

Connection 9.x Sites
When you remove an intersite link between two Cisco Unity Connection sites, each site gateway stops
synchronizing directory information with the other site, removes all objects that are homed on the remote
site, and removes all configuration information about the remote site gateway.
We recommend that you carefully consider the impacts of removing an intersite link prior to doing so,
particularly if you plan to relink the sites later. Consider the following impacts:

Users and system distribution lists on each site are removed from distribution lists that are homed
on the other site. If you later relink the sites, you need to update distribution list membership to
include any remote users and distribution lists.

System call handlers and interview handlers that are configured to send messages to a remote site
user or distribution list are reconfigured to send messages to the undeliverable messages list of the
location on which the handler is configured. If you later relink the sites, you need to update the
recipients for these handlers to use the correct remote object. (Even if you do not plan to relink the
sites, you should make sure that someone is checking messages that are sent to the Connection
undeliverable messages list, or reassign handlers that use it as a recipient.)

Partitions that were created for remote site locations are removed from search spaces in each
Connection site. If you later relink the sites, you need to review the partition membership of the
search spaces that are owned on each location in each site. Depending on the version of Connection

Networking Guide for Cisco Unity Connection Release 9.x

5-6

Chapter 5

Making Changes to the Networking Configuration in Cisco Unity Connection 9.x

Removing an Intersite Link Between Two Cisco Unity Connection 9.x Sites

on the server and the search space configuration, you may need to manually re-add remote partitions
to each search space, or you may need to reorder the partitions within the search space to match the
configuration that you had prior to removing the intersite link.

On each location in the site, there are cross-server configuration settings specific to other locations.
When you unlink the sites, these settings are removed. If you later relink the sites, you need to
reconfigure all location-specific settings in both sites.

All intersite messaging, addressing between sites, and intersite auto-attendant features will be
unavailable after the link is removed.

Do the following procedure to remove an intersite link between two Cisco Unity Connection 9.x sites.
If either of the gateways is a Connection cluster, do the steps for that gateway only on the publisher
server.
To Remove an Intersite Link Between Two Cisco Unity Connection 9.x Sites
Step 1

Step 2

On either site gateway, remove the intersite link. This stops synchronization with the remote site and
removes all remote site objects from the local site directory.
a.

In Cisco Unity Connection Administration, expand Networking, expand Links, then select
Intersite Links.

b.

On the Search Intersite Links page, check the check box next to the intersite link corresponding to
the remote site.

c.

Select Remove Selected.

d.

At the warning about deleting associated objects, select OK.

Optionally, review the schedule for the Remove Objects Associated With Deleted Remote Sites task. By
default, to avoid affecting system performance during business hours, this task runs at once a day at
10:00 p.m., and the intersite link is not fully removed until the task has run.
To review the schedule, either select the link to the task that is displayed in the Status message on the
Search Intersite Links page after you have removed the selected intersite link, or expand Tools and select
Task Management; on the Task Definitions page, select Remove Objects Associated With Deleted
Remote Sites.

Caution

Step 3

Because server performance can be impacted by large deletion activities, we strongly

recommend that you allow the Remove Objects Associated With Deleted Remote Sites task
to run on the default schedule (or at another time during non-business hours).

To verify that the link has been removed, expand Networking, expand Links, and select Intersite Links.
On the Search Intersite Links page, if the link has not yet been removed, it is displayed in the Intersite
Links table with (Link Removal Pending) listed after the Display Name. If the Remove Objects
Associated With Deleted Remote Sites task has run and the link has been removed, no entry is displayed
in the Intersite Links table.

Step 4

Repeat Step 1 through Step 3 on the other site gateway.

Networking Guide for Cisco Unity Connection Release 9.x

5-7

Chapter 5 Making Changes to the Networking Configuration in Cisco Unity Connection 9.x
Removing an Intersite Link Between Two Cisco Unity Connection 9.x Sites

Networking Guide for Cisco Unity Connection Release 9.x

5-8

CH A P T E R

Cross-Server Sign-In, Transfers, and Live Reply

in Cisco Unity Connection 9.x
This chapter describes the cross-server sign-in, transfer, and live reply features that are available
between Cisco Unity Connection locations in a site, between Connection locations in different sites that
are linked by an intersite link, and between Cisco Unity and Cisco Unity Connection locations in sites
that are linked by an intersite link. Also included in this chapter are the procedures for turning on the
cross-server features.
See the following sections:

Overview of Cross-Server Sign-In, Transfer, and Live Reply in Cisco Unity Connection 9.x,
page 6-1

Cross-Server Sign-In in Cisco Unity Connection 9.x, page 6-3

Cross-Server Transfers in Cisco Unity Connection 9.x, page 6-9

Cross-Server Live Reply in Cisco Unity Connection 9.x, page 6-16

Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection
9.x, page 6-22

Overview of Cross-Server Sign-In, Transfer, and Live Reply in

Cisco Unity Connection 9.x
In order to limit replication traffic and keep the directory size manageable, only a subset of user
information is replicated from the home location of the user to other networked locations. For this
reason, only the home location of the user has information about call transfer settings, greetings, and
other specific details for the user. In order for the location to properly handle calls destined for a user on

Networking Guide for Cisco Unity Connection Release 9.x

6-1

Chapter 6 Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Overview of Cross-Server Sign-In, Transfer, and Live Reply in Cisco Unity Connection 9.x

a different location, it must hand off the call to the home location of the user. The purpose of the
cross-server features is to make the user experience in a networked environment almost the same as in a
single server environment, as shown in Table 6-1.
Table 6-1

Cross-Server Features

Feature

Description

Cross-server sign-in

Cross-server sign-in allows administrators to provide users who are homed

on different locations with one phone number that they can call to sign in.
When calling from outside the organization, usersno matter which is
their home servercall the same number and are transferred to the
applicable home server to sign in.

Cross-server transfer

Cross-server transfer enables calls from the automated attendant or from a

directory handler of one location to be transferred to a user on another
location, according to the call transfer and screening settings of the called
user.

Cross-server live reply

Cross-server live reply allows users who listen to their messages by phone
to reply to a message from a user on another location by transferring to the
user (according to the call transfer and screening settings of the called
user).

Although the cross-server features are distinct features, they all use the same underlying
functionalityan enhanced supervised call transfer:
1.

The location on which a sign-in, transfer, or live reply originates puts the caller on hold and calls
the receiving location by dialing a phone number designated as the cross-server dial string for the
receiving location.

2.

When the receiving location answers, the originating location sends a sequence of DTMF tones that
identify the call as a handoff request.

3.

The receiving location responds with a sequence of DTMF tones, and the originating location hands
off the call to the receiving location for processing.

At this point the functionality is the same as if the call had originated on the receiving location.
In this chapter, an originating location is defined as a server (or cluster) that calls other locations. A
receiving location is defined as a server (or cluster) that answers a cross-server call.
Cross-server dial strings are not synchronized between locations. Each originating location can be
configured with a dial string for each receiving location. Note that if an originating location is configured
for multiple phone system integrations, you must choose a dial string that all phone system integrations
can use to reach the receiving location.

Search Space Considerations for Cross-Server Sign-In, Transfers, and Live

Reply
When a user dials the pilot number of a Cisco Unity Connection location that is not his or her home
server, the answering location processes the call according to its call management plan. A search space
is assigned to the call by the first call routing rule that the call matches. At each subsequent processing
step, the search scope of the call may change. Connection uses the search space that is assigned to the
call at the point that the call reaches the Attempt Sign-In conversation to identify which user is trying to
sign in. If a user calls from an extension that is in a partition that is not a member of this search space,

Networking Guide for Cisco Unity Connection Release 9.x

6-2

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Sign-In in Cisco Unity Connection 9.x

the call is not identified as coming from the user. If the extension of the user overlaps with an extension
in another partition that also appears in this search space, the call is identified as coming from the first
object that Connection finds when searching the partitions in the order in which they appear in the search
space. Check the direct routing rules on each Connection location that handles incoming sign-in calls
from remote users to determine the search space that is set by the rule or other call management object
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.
Also note that for cross-server calls from one Connection location to another Connection location (either
in the same site or in a remote site), a mismatch between the search space that is applied to the call on
the originating location and the search space that is applied on the receiving location can cause problems
for cross-server sign-ins and cross-server transfers. A match could be made on the search scope on the
originating location that cannot be made on a different search scope on the receiving location. For this
reason, we recommend that you verify that the same search scope is configured on both originating and
receiving locations. For example, call routing rules can be used to direct cross-server calls on the
receiving location to the appropriate search space based on the cross-server dial string that is used to
reach that location.
For cross-server live reply, as with any live reply attempt, a Connection user can only call the sender if
the sender is in a partition that is a member of the search space configured for the user.

Cross-Server Sign-In in Cisco Unity Connection 9.x

The cross-server sign-in feature enables users who are calling from outside the organization to call the
same number regardless of which server they are homed on, and they are transferred to the applicable
home server to sign in. If you do not enable cross-server sign-in, users need to call the phone number of
their home server to sign in.
The process for a cross-server sign-in call is as follows:
1.

A user calls the server configured for cross-server sign-in. The user is identified by the calling
number or is asked to enter his or her ID.

2.

The server looks up the caller ID in the database to determine whether the account is homed on the
local server or on a networked server.
If the user account is homed on the local server, the sign-in proceeds as usual.
If the user account is homed on another server, the conversation plays a One moment please

prompt (if configured to do so), puts the user on hold, and calls the user home server by using
the same port that the user called in on. Note that if the user is calling from his or her primary
or alternate extension, the One moment please prompt is typically the first prompt that the
user hears.
When the receiving server answers, the originating server sends a sequence of DTMF tones that
identifies the call as a cross-server sign-in.
3.

The receiving location responds with a sequence of DTMF tones.

4.

The originating location hands off the call to the receiving server for processing. The conversation
on the receiving server prompts for the user password. At this point, the behavior is as though the
user had called the receiving server directly.

The intended use of this feature is limited to users calling in from outside your organization. Although
cross-server sign-in will transfer internal calls to the home server, doing so for a large number of users
will increase the load on the servers. Therefore, user phones should always be configured so that the
Messages or voicemail speed-dial button calls the home server of the user directly. When moving a
user account from one server to another, update the phone system configuration for the user accordingly.

Networking Guide for Cisco Unity Connection Release 9.x

6-3

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Sign-In in Cisco Unity Connection 9.x

Prerequisites: Enabling Cross-Server Sign-In

If your Cisco Voicemail Organization includes Cisco Unity servers, all of the networked
Cisco Unity servers that you configure as originating locations for cross-server sign-in must be
configured to be in the same dialing domain as the Cisco Unity site gateway. The dialing domain is
configured on the Network > Primary Location > Profile page in the Cisco Unity Administrator.

Task List: Enabling Cross-Server Sign-In

Whether you are configuring a single Cisco Unity Connection site, an organization that contains two
Connection sites, or an organization that contains a Connection site and a Cisco Unity site, the same
basic set of tasks applies. Use the following task list to enable cross-server sign-in. The cross references
take you to detailed procedures.
1.

Determine which locations will be originating locations and which will be receiving locations for
cross-server sign-in. Often a single location is designated as the originating location that all users
call into from outside the organization, and all other location are designated as receiving locations;
however, this does not have to be the case. A single location also may be both an originating location
and a receiving location.

2.

For each originating location, make a list of the phone numbers that the location must dial to reach
the receiving location servers.

Note

3.

You can enter only one dial string for each receiving location. If the originating location is
configured for multiple phone system integrations, you will need a dial string that all phone
system integrations can use to reach the receiving location.
Configure each receiving location so that it can handle incoming cross-server handoff requests.
If the receiving location is a Cisco Unity Connection server, see the Configuring a Cisco Unity

Connection Receiving Location to Accept Cross-Server Handoff Requests section on page 6-5.
If the receiving location is a Cisco Unity server, see the Verifying That a Receiving

Cisco Unity Location Routes Calls to the Opening Greeting section on page 6-5.
4.

If Cisco Unity Connection locations will receive cross-server handoff requests from Cisco Unity
servers, configure the Connection locations to allow cross-server DTMF sequences that begin with
#. See the Configuring a Cisco Unity Connection Receiving Location to Allow Cross-Server
DTMF Sequences from Cisco Unity Locations section on page 6-6.

5.

For each originating location, enable the cross-server sign-in feature and enter the pilot numbers of
the receiving locations from the list that you created in Task 2.
If the location is a Cisco Unity Connection server, see the Configuring a Cisco Unity

Connection Originating Location to Perform Cross-Server Sign-In Requests section on

page 6-7.
If the location is a Cisco Unity server, see the Configuring a Cisco Unity Originating Location

to Perform Cross-Server Sign-In Requests section on page 6-8.

6.

Test the cross-server sign-in functionality. See the Testing Cross-Server Sign-In section on
page 6-9.

Networking Guide for Cisco Unity Connection Release 9.x

6-4

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Sign-In in Cisco Unity Connection 9.x

Procedures: Enabling Cross-Server Sign-In

Configuring a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff Requests
By default, each Cisco Unity Connection server is configured to ignore cross-server handoff requests.
To enable cross-server features, you must configure the receiving location to accept requests and also
verify that the location routes incoming cross-server calls to a call handler. Do the following two
procedures to configure each receiving Connection location to accept handoffs. (Doing so allows the
location to receive handoffs of all typessign-in, transfer, and live reply.)

To Configure a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff

Requests, page 6-5

To Verify That Call Routing Rules Are Set to Route Calls to a Call Handler Greeting, page 6-5

To Configure a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff Requests
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server handoffs for users
who are homed on that location (the receiving location), expand System Settings > Advanced, then
select Conversations.

Step 2

Check the Respond to Cross-Server Handoff Requests check box.

Step 3

Repeat the procedure on all remaining Connection receiving locations.

To Verify That Call Routing Rules Are Set to Route Calls to a Call Handler Greeting
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server handoffs, expand
Call Management > Call Routing and select Direct Routing Rules.

Step 2

Select the display name of the routing rule that applies to incoming cross-server calls from originating
locations.

Step 3

Verify that calls that match the rule are routed to a call handler.

Step 4

Repeat the procedure on all remaining Connection receiving locations.

Verifying That a Receiving Cisco Unity Location Routes Calls to the Opening Greeting
In order to accept cross-server handoff requests, each Cisco Unity server must be configured to route
calls to the Opening Greeting call handler. (This is the default when Cisco Unity is initially installed.)
Do the following procedure on each of the receiving Cisco Unity servers to verify that the call routing
rules are set properly to accept handoffs.

Note

For failover systems, do the procedure on both the primary and secondary servers.

Networking Guide for Cisco Unity Connection Release 9.x

6-5

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Sign-In in Cisco Unity Connection 9.x

To Verify That Call Routing Rules Are Set to Route Calls to the Opening Greeting
Step 1

In the Cisco Unity Administrator, on a location that will accept cross-server sign-in handoffs, go to the
Call Routing > Direct Calls page.

Step 2

Verify that incoming cross-server calls from originating locations are routed to the Opening Greeting.
The Default Call Handler routing rule (which cannot be deleted or modified) sends calls to the Opening
Greeting. Therefore, if you have not added any routing rules, the server is already set to correctly process
cross-server calls.

Step 3

Repeat the procedure on all remaining Cisco Unity receiving locations.

Configuring a Cisco Unity Connection Receiving Location to Allow Cross-Server DTMF Sequences
from Cisco Unity Locations
The sequence of DTMF tones that an originating Cisco Unity location sends to the receiving location
begins with # (pound). By default, the Cisco Unity Connection opening greeting and other call handlers
are configured to ignore any additional caller input following a # key. In such a configuration, all
cross-server handoffs will fail.
You have a couple of options for changing the behavior on a Connection receiving location so that
cross-server handoffs are performed successfully:

Change the opening greeting (or other existing call handler that will receive the cross-server handoff
calls based on your routing rule configuration) to allow additional input following a # key.

Create a new call handler and direct-call routing rule specifically to handle cross-server calls. The
new call handler must allow additional input after the # key. The direct call routing rule should route
calls to the new call handler based on criteria that apply to cross-server callsthe calling number
of any originating Cisco Unity location, for example, or the cross-server dial string that the
originating locations dial to reach the receiving location. (If you do not want other calls to match
the routing rule, choose criteria that are unique to cross-server calls.)

Do the following procedure on each Connection receiving location to configure the opening greeting or
other call handler to allow additional input after the # key, and, optionally, to create a new direct-call
routing rule.
To Configure a Cisco Unity Connection Receiving Location to Allow Cross-Server DTMF Sequences from
Cisco Unity Locations
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server sign-in handoffs,
expand Call Management, then select System Call Handlers.

Step 2

On the Search Call Handlers page, select the display name of the opening greeting or other call handler
that you want to modify, or select Add New to create a new call handler specifically for cross-server
calls.

Step 3

If you created a new call handler in Step 2, on the New Call Handler page, enter basic settings, as
applicable. (For field information, on the Help menu, select This Page.)

Step 4

To configure the call handler to accept the cross-server DTMF sequence, do the following substeps:
a.

On the Edit menu, select Caller Input.

b.

On the Caller Input page, select #.

Networking Guide for Cisco Unity Connection Release 9.x

6-6

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Sign-In in Cisco Unity Connection 9.x

Step 5

Step 6

c.

Uncheck the Ignore Additional Input check box.

d.

Select Save.

If you did not create a new call handler in Step 2, skip to Step 6. If you created a new call handler in
Step 2, create a new direct-call routing rule to send calls from the Cisco Unity servers to the call handler
for processing by doing the following sub-steps:
a.

Expand Call Management > Call Routing, then select Direct Routing Rules.

b.

On the Direct Routing Rules page, select Add New.

c.

On the New Direct Rule page, enter the name of the new rule in the Display Name field.

d.

Select Save.

e.

On the Edit Direct Rule page, for Send Call To, select Call Handler, then select the name of the call
handler you added in Step 2.

f.

Select Save.

g.

Under Routing Rule Conditions, select Add New.

h.

Configure the routing rule condition to match cross-server calls from Cisco Unity servers. For
example, use the Calling Number field to match the phone numbers of the Cisco Unity ports that
answer user calls.

i.

Select Save.

j.

On the Edit menu, select Edit Direct Routing Rule.

k.

Repeat g. through j. for each additional number or number pattern that you need to match
cross-server calls.

Repeat the procedure on all remaining Connection receiving locations.

Configuring a Cisco Unity Connection Originating Location to Perform Cross-Server Sign-In

Requests
By default, a Cisco Unity Connection location will not attempt to perform a cross-server sign-in for users
homed on any other locations. Do the following procedure to enable cross-server sign-in on any
Connection originating locations.
To Configure a Cisco Unity Connection Originating Location to Perform Cross-Server Sign-In Requests
Step 1

In Cisco Unity Connection Administration, on a location that handles sign-in calls from remote users
(the originating location), expand Networking, then select Locations.

Step 2

On the Search Locations page, select the Display Name of a remote location that will accept cross-server
sign-in requests for users who are homed on this location (the receiving location).

Step 3

On the Edit Location page for the receiving location, do the following to initiate cross-server features to
this receiving location:
a.

To enable cross-server sign-in to the remote location, check the Allow Cross-Server Sign-In to this
Remote Location check box.

b.

Enter the dial string that this location will use to call the receiving location when performing the
handoff (for example, the pilot number of the home server).

Networking Guide for Cisco Unity Connection Release 9.x

6-7

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Sign-In in Cisco Unity Connection 9.x

Note

Step 4

Repeat Step 2 and Step 3 to configure each receiving location that accepts cross-server sign-in handoffs
from this location.

Tip

Step 5

You can enter only one dial string for each receiving location. If the originating location is
configured for multiple phone system integrations, enter a dial string that all phone system
integrations can use to reach the receiving location.

After you have saved the changes on a page, use the Next and Previous buttons to quickly
navigate through each location in the organization.

Repeat the procedure on all remaining Connection originating locations.

Configuring a Cisco Unity Originating Location to Perform Cross-Server Sign-In Requests

By default, a Cisco Unity originating location will not attempt to perform a cross-server sign-in for users
homed on any other locations. Do the following procedure to enable cross-server sign-in on any
Cisco Unity originating locations.

Note

If the system is using failover, do the procedure on both the primary and secondary server, because most
of the settings on the Network > Dialing Domain Options page are stored in the registry. (Registry
settings are not replicated to the secondary server.)
To Configure a Cisco Unity Originating Location to Perform Cross-Server Sign-In Requests

Step 1

In the Cisco Unity Administrator, go to the Network > Dialing Domain Options page.

Note

If the Dialing Domain Options link is unavailable on the system, you must first configure the
dialing domain on the Primary Location Settings page in the Cisco Unity Administrator.

Step 2

In the Cross Server Logon section, select the Subscribers Dial the Same Number to Log On to
Cisco Unity check box.

Step 3

In the Pilot Numbers for Cross-Server Logon, Transfer, and Live Reply section, enter the pilot number
in the Dial String field for each server that is displayed in the table. (Note that the pilot numbers that you
enter are stored in the SQL Server database UnityDb on the Cisco Unity server. Therefore, if the system
is using failover, the pilot numbers will be replicated to the secondary server.)

Step 4

Check the Play Prompt During Cross-Server Logon, Transfer, and Live Reply so That Callers
Know Something Is Happening check box. Although playing the One moment please prompt is
optional, we recommend that you check the check box because the cross-server process can take several
seconds before the receiving server prompts users to enter their passwords.

Step 5

Select Save.

Step 6

Repeat the procedure on all remaining Cisco Unity originating locations.

Networking Guide for Cisco Unity Connection Release 9.x

6-8

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Transfers in Cisco Unity Connection 9.x

Testing Cross-Server Sign-In

We recommend that you test cross-server sign-in before allowing users to use the feature.
For failover systems, first test that the primary destination servers answer cross-server calls. Then
manually fail over the destination servers to verify that the secondary server answers cross-server calls.
If the destination servers are properly configured for failover, the secondary server should answer
cross-server calls when the primary server is unavailable.
To Test Cross-Server Sign-In
Step 1

Create a new user account (or use an existing account) on each of the destination servers for testing
purposes. Be sure to verify that the user account information has replicated to all of the servers that you
will be testing. The time that it takes for the user data to replicate depends on your network configuration
and replication schedule.

Step 2

For each user account, call the pilot number for the server configured for cross-server sign-in, and
attempt to sign in. Verify that:

The One moment please prompt is played (if configured to do so).

You successfully sign in.

Cross-Server Transfers in Cisco Unity Connection 9.x

A cross-server transfer is a special kind of supervised transfer that passes control of a call from the
automated attendant or a directory handler to the home server of the called user.
1.

A caller calls a Cisco Unity or Cisco Unity Connection server on which an audio text application
has been configured.

2.

The caller does one of the following:

In a call handler (such as the opening greeting), enters the extension of a user on another server,

or
In a directory handler, spells the name of a user on another server.
3.

The server that is handling the call puts the caller on hold, and calls the home server of the user.

4.

When the receiving server answers, the originating server sends a sequence of DTMF tones that
identify the call as a cross-server transfer.

5.

The receiving server responds with a sequence of DTMF tones.

6.

The originating server hands off the call to the receiving server for processing. At this point, the
behavior is as though the caller had directly called the automated attendant or directory handler on
the receiving server.

When cross-server transfers have been configured, user call transfer, call screening, call holding, and
announce features are available.

Prerequisites: Enabling Cross-Server Transfers

If your Cisco Voicemail Organization includes networked Cisco Unity servers:

Networking Guide for Cisco Unity Connection Release 9.x

6-9

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Transfers in Cisco Unity Connection 9.x

All of the Cisco Unity servers that you configure as originating locations for cross-server

transfers must be configured to be in the same dialing domain as the Cisco Unity site gateway.
The dialing domain is configured on the Network > Primary Location > Profile page in the
Cisco Unity Administrator.
The addressing, directory handler, and automated attendant search scopes for each Cisco Unity

server must be set to the dialing domain or global directory. For details, see the Setting the
Addressing, Directory Handler, and Automated Attendant Search Scopes section in the
Digital Networking chapter of the applicable Networking Guide for Cisco Unity, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_feature_guides_list.html.

Task List: Enabling Cross-Server Transfers

Whether you are configuring a single Cisco Unity Connection site, an organization that contains two
Connection sites, or an organization that contains a Connection site and a Cisco Unity site, the same
basic set of tasks applies. Use the following task list to enable cross-server transfers. The cross
references take you to detailed procedures.
1.

Determine whether each location will be an originating location, a receiving location, or both.

2.

For each originating location, make a list of the phone numbers the location must dial to reach the
receiving location servers.

Note

3.

You can enter only one dial string for each receiving location. If the originating location is
configured for multiple phone system integrations, you will need a dial string that all phone
system integrations can use to reach the receiving location.
Configure each receiving location so that it can handle incoming cross-server handoff requests.
If the receiving location is a Cisco Unity Connection server, see the Configuring a Cisco Unity

Connection Receiving Location to Accept Cross-Server Handoff Requests section on

page 6-11.
If the receiving location is a Cisco Unity server, see the Verifying That a Receiving

Cisco Unity Location Routes Calls to the Opening Greeting section on page 6-12.
4.

If Cisco Unity Connection locations will receive cross-server handoff requests from Cisco Unity
servers, configure the Connection locations to allow cross-server DTMF sequences that begin
with #. See the Configuring a Cisco Unity Connection Receiving Location to Accept Cross-Server
Handoff Requests section on page 6-5.

5.

For each originating location, enable the cross-server transfer feature and enter the pilot numbers of
the receiving locations from the list that you created in Task 2.
If the location is a Cisco Unity Connection server, see the Configuring a Cisco Unity

Connection Originating Location to Perform Cross-Server Transfer Requests section on

page 6-14.
If the location is a Cisco Unity server, see the Configuring a Cisco Unity Originating Location

to Perform Cross-Server Transfer Requests section on page 6-14.

6.

Test the cross-server transfer functionality. See the Testing Cross-Server Transfer section on
page 6-15.

Networking Guide for Cisco Unity Connection Release 9.x

6-10

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Transfers in Cisco Unity Connection 9.x

Procedures: Enabling Cross-Server Transfers

Configuring Cross-Server Transfers through CLI Commands
Added June 5, 2013

To Configure Cross-Server Transfers through CLI Commands

Step 1

Create the configuration entry using the following command:

run cuc dbquery unitydirdb execute procedure
csp_ConfigurationCreate(pName='HandoffForwardRemoteForward'::lvarchar,
pParentFullName='System.Conversations.CrossBox'::lvarchar, pType=11, pValueBool=1,
pRequiresRestart=1)

Step 2

Enable the cross-server transfers using the following command:

run cuc dbquery unitydirdb execute procedure
csp_ConfigurationModify(pName='HandoffForwardRemoteForward'::lvarchar,
pParentFullName='System.Conversations.CrossBox'::lvarchar, pValueBool=1)

Step 3

Disable the cross-server transfers using the following command:

run cuc dbquery unitydirdb execute procedure
csp_ConfigurationModify(pName='HandoffForwardRemoteForward'::lvarchar,
pParentFullName='System.Conversations.CrossBox'::lvarchar, pValueBool=0)

Step 4

To view the entry do the following:

run cuc dbquery unitydirdb select fullname,name,parentid,valuebool,value from
vw_Configuration where name like 'HandoffForwardRemoteForward'

Configuring a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff Requests
By default, each Cisco Unity Connection server is configured to ignore cross-server handoff requests.
To enable cross-server features, you must configure the receiving location to accept requests and also
verify that the location routes incoming calls to a call handler. Do the following two procedures to
configure each receiving Connection location to accept handoffs. (Doing so allows the location to
receive handoffs of all typessign-in, transfer, and live reply.)

To Configure a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff

Requests, page 6-11

To Verify That Call Routing Rules Are Set to Route Calls to a Call Handler Greeting, page 6-12

To Configure a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff Requests
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server handoffs for users
who are homed on that location (the receiving location), expand System Settings > Advanced, then
select Conversations.

Step 2

Check the Respond to Cross-Server Handoff Requests check box.

Step 3

Repeat the procedure on all remaining Connection receiving locations.

Networking Guide for Cisco Unity Connection Release 9.x

6-11

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Transfers in Cisco Unity Connection 9.x

To Verify That Call Routing Rules Are Set to Route Calls to a Call Handler Greeting
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server handoffs, expand
Call Management > Call Routing and select Direct Routing Rules.

Step 2

Select the display name of the routing rule that applies to incoming cross-server calls from originating
locations.

Step 3

Verify that calls that match the rule are routed to a call handler.

Step 4

Repeat the procedure on all remaining Connection receiving locations.

Verifying That a Receiving Cisco Unity Location Routes Calls to the Opening Greeting
In order to accept cross-server handoff requests, each Cisco Unity server must be configured to route
calls to the opening greeting call handler. (This is the default when Cisco Unity is initially installed.) Do
the following procedure on each of the receiving Cisco Unity servers to verify that the call routing rules
are set properly to accept handoffs.

Note

For failover systems, do the procedure on both the primary and secondary servers.
To Verify That Call Routing Rules Are Set to Route Calls to the Opening Greeting

Step 1

In the Cisco Unity Administrator, on a location that will accept cross-server transfer handoffs, go to the
Call Routing > Direct Calls page.

Step 2

Verify that incoming cross-server calls from originating locations are routed to the Opening Greeting.
The Default Call Handler routing rule (which cannot be deleted or modified) sends calls to the Opening
Greeting. Therefore, if you have not added any routing rules, the server is already set to correctly process
cross-server calls.

Step 3

Repeat the procedure on all remaining Cisco Unity receiving locations.

Configuring a Cisco Unity Connection Receiving Location to Allow Cross-Server DTMF Sequences
from Cisco Unity Locations
The sequence of DTMF tones that an originating Cisco Unity location sends to the receiving location
begins with # (pound). By default, the Cisco Unity Connection opening greeting and other call handlers
are configured to ignore any additional caller input following a # key. In such a configuration, all
cross-server handoffs will fail.
You have a couple of options for changing the behavior on a Connection receiving location so that
cross-server handoffs are performed successfully:

Change the opening greeting (or other existing call handler that will receive the cross-server handoff
calls based on your routing rule configuration) to allow additional input.

Networking Guide for Cisco Unity Connection Release 9.x

6-12

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Transfers in Cisco Unity Connection 9.x

Create a new call handler and direct-call routing rule specifically to handle cross-server calls. The
direct call routing rule should route calls to the new call handler based on criteria that apply to
cross-server callsthe calling number of any originating Cisco Unity location, for example, or the
cross-server dial string that the originating locations dial to reach the receiving location. (If you do
not want other calls to match the routing rule, choose criteria that are unique to cross-server calls.)

Do the following procedure on each Connection receiving location to configure the opening greeting or
other call handler to allow additional input after the # key, and, optionally, to create a new direct-call
routing rule.
To Configure a Cisco Unity Connection Receiving Location to Allow Cross-Server DTMF Sequences from
Cisco Unity Locations
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server transfer handoffs,
expand Call Management, then select System Call Handlers.

Step 2

On the Search Call Handlers page, select the display name of the opening greeting or other call handler
that you want to modify, or select Add New to create a new call handler specifically for cross-server
calls.

Step 3

If you did not create a new call handler in Step 2, skip to Step 6. If you created a new call handler in
Step 2, on the New Call Handler page, enter basic settings, as applicable. (For field information, on the
Help menu, select This Page.)

Step 4

To configure the call handler to accept the cross-server DTMF sequence, do the following substeps:

Step 5

a.

On the Edit menu, select Caller Input.

b.

On the Caller Input page, select #.

c.

Uncheck the Ignore Additional Input check box.

d.

Select Save.

If you created a new call handler in Step 2, create a new direct-call routing rule to send calls from the
Cisco Unity servers to the call handler for processing:
a.

Expand Call Management > Call Routing, then select Direct Routing Rules.

b.

On the Direct Routing Rules page, select Add New.

c.

On the New Direct Rule page, enter the name of the new rule in the Display Name field.

d.

Select Save.

e.

On the Edit Direct Rule page, for Send Call To, select Call Handler, then select the name of the call
handler you added in Step 2.

f.

Select Save.

g.

Under Routing Rule Conditions, select Add New.

h.

Configure the routing rule condition to match cross-server calls from Cisco Unity servers. For
example, use the Calling Number field to match the phone numbers of the Cisco Unity ports that
answer user calls.

i.

Select Save.

j.

On the Edit menu, select Edit Direct Routing Rule.

k.

Repeat g. through j. for each additional number or number pattern that you need to match
cross-server calls.

Networking Guide for Cisco Unity Connection Release 9.x

6-13

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Transfers in Cisco Unity Connection 9.x

Step 6

Repeat the procedure on all remaining Connection receiving locations.

Configuring a Cisco Unity Connection Originating Location to Perform Cross-Server Transfer

Requests
By default, a Cisco Unity Connection location will not attempt to perform a cross-server transfer. Note
that when you enable cross-server transfers on Connection, cross-server live reply is automatically
enabled. Do the following procedure to enable cross-server transfer and live reply on any Connection
originating locations.
To Configure a Cisco Unity Connection Originating Location to Perform Cross-Server Transfer and Live Reply
Handoff Requests
Step 1

In Cisco Unity Connection Administration, on a location that transfers calls to remote users (the
originating location), expand Networking, then select Locations.

Step 2

On the Search Locations page, select the Display Name of a remote location that will accept cross-server
transfer handoffs for users who are homed on this location (the receiving location).

Step 3

On the Edit Location page for the receiving location, do the following to initiate cross-server features to
this receiving location:
a.

To enable cross-server transfer and live reply to the remote location, check the Allow Cross-Server
Transfer to this Remote Location check box.

b.

Enter the dial string that this location will use to call the receiving location when performing the
handoff (for example, the pilot number of the receiving location).

Note

Step 4

Repeat Step 2 and Step 3 for each receiving location that accepts cross-server transfer handoffs from this
location.

Tip

Step 5

You can enter only one dial string for each receiving location. If the originating location is
configured for multiple phone system integrations, enter a dial string that all phone system
integrations can use to reach the receiving location.

After you have saved the changes on a page, use the Next and Previous buttons to quickly
navigate through each location in the organization.

Repeat the procedure on all remaining Connection originating locations.

Configuring a Cisco Unity Originating Location to Perform Cross-Server Transfer Requests

By default, a Cisco Unity originating location will not attempt to perform cross-server transfers to any
other locations. Do the following procedure to enable cross-server transfers on any Cisco Unity
originating locations.

Networking Guide for Cisco Unity Connection Release 9.x

6-14

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Transfers in Cisco Unity Connection 9.x

Note

If the system is using failover, do the following procedure on both the primary and secondary server,
because most of the settings on the Network > Dialing Domain Options page are stored in the registry.
(Registry settings are not replicated to the secondary server.)
To Configure a Cisco Unity Originating Location to Perform Cross-Server Transfer Requests

Step 1

In the Cisco Unity Administrator, go to the Network > Dialing Domain Options page.

Note

If the Dialing Domain Options link is unavailable on the system, you must configure the dialing
domain on the Primary Location Settings page in the Cisco Unity Administrator.

Step 2

Select the Cross-server Transfer: Pass Control to the Called Subscribers Cisco Unity Server check
box. (Selecting Release Calls to the Phone System disables cross-server transfers originating from this
server. Instead of handing off calls to the home server of the user, Cisco Unity will attempt a release
transfer to the Cross-Server Transfer Extension configured for the user. This will fail if a Connection
user does not have a Cross-Server Transfer Extension configured.)

Step 3

In the Pilot Numbers for Cross-Server Logon, Transfer, and Live Reply section, enter the pilot number
in the Dial String field for each server displayed in the table. (Note that the pilot numbers that you enter
are stored in the SQL Server database UnityDb on the Cisco Unity server. Therefore, if the system is
using failover, the pilot numbers will be replicated to the secondary server.)

Step 4

Select the Play Prompt During Cross-Server Logon, Transfer, and Live Reply so That Callers
Know Something Is Happening check box. Although playing the One moment please prompt is
optional, we recommend that you check the check box because the cross-server process can take several
seconds before the caller is transferred.

Step 5

Select Save.

Step 6

Repeat the procedure on all remaining Cisco Unity originating locations.

Testing Cross-Server Transfer

We recommend that you test cross-server transfers before allowing callers to use the feature.
For failover systems, first test that the primary destination servers answer cross-server calls. Then
manually fail over the destination servers to verify that the secondary server answers cross-server calls.
If the destination servers are properly configured for failover, the secondary server should answer
cross-server calls when the primary server is unavailable.
To Test Cross-Server Transfer
Step 1

Create a new user account (or use an existing account) on each of the destination servers for testing
purposes. Be sure to verify that the user account information has replicated to all of the servers that you
will be testing. The time that it takes for the user data to replicate depends on your network configuration
and replication schedule.

Step 2

For each user account, call the pilot number for the server configured for cross-server transfer, and enter
the user extension at the opening greeting. Verify that:

The One moment please prompt is played (if configured to do so).

Networking Guide for Cisco Unity Connection Release 9.x

6-15

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Live Reply in Cisco Unity Connection 9.x

The call is transferred to the user phone or the greeting, according to the call transfer settings of the
called user.

Cross-Server Live Reply in Cisco Unity Connection 9.x

Live reply, when enabled, allows a user who is listening to messages by phone to reply to a message from
another user by transferring to the user. Note that whether users have access to live reply is controlled
by the class of service.
When cross-server live reply is enabled:
1.

After listening to a message from a user on another networked location, the message recipient
chooses to call the user who left the message.
Note that if identified subscriber messaging (ISM) is disabled on the location that recorded the
message, the cross-server live reply option will only be available for messages that are sent by users
who sign in and address and send the message from their mailboxes.

2.

The originating location puts the user on hold and looks up the extension in the database to
determine whether the user who is being replied to is on the same server or is on another networked
location. If the user is on the same server, processing proceeds as usual.
However, if the user who is being replied to is on another location, the originating location calls the
applicable receiving location.

3.

When the receiving location answers, the originating location sends a sequence of DTMF tones that
identify the call as a cross-server live reply.

4.

The receiving location responds with a sequence of DTMF tones.

5.

The originating location hands off the call to the receiving location for processing.

Prerequisites: Enabling Cross-Server Live Reply

If your Cisco Voicemail Organization includes networked Cisco Unity servers:

All of the Cisco Unity servers that you configure as originating locations for cross-server live

reply must be configured to be in the same dialing domain as the Cisco Unity site gateway. The
dialing domain is configured on the Network > Primary Location > Profile page in the
Cisco Unity Administrator.
Users must belong to a class of service for which live reply between users is enabled. For

Cisco Unity users, live reply between users is enabled on the Subscribers > Class of Service >
Messages page in the Cisco Unity Administrator, by checking the Subscribers Can Reply to
Messages from Other Subscribers by Calling Them check box.
For cross-server live reply to be available to messages that were sent when the sender called the

recipient from a recognized phone number and was forwarded to Cisco Unity, identified
subscriber messaging must be set up between networked Cisco Unity servers and extended to
include Connection Networking subscribers. For instructions, see the Extending Cisco Unity
Identified Subscriber Messaging to Include Connection Networking Subscribers section on
page 3-18.

Networking Guide for Cisco Unity Connection Release 9.x

6-16

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Live Reply in Cisco Unity Connection 9.x

Users must belong to a class of service for which live reply between users is enabled. For
Cisco Unity Connection users, live reply between users is enabled on the Class of Service > Edit
Class of Service page in Cisco Unity Connection Administration, by selecting the Users Can Reply
to Messages from Other Users by Calling Them check box.

Task List: Enabling Cross-Server Live Reply

Note

In Cisco Unity Connection, cross-server live reply is automatically supported (for users whose class of
service allows it) when cross-server transfer is enabled. If you have previously configured a Connection
location as an originating or receiving location for cross-server transfers, the location will also originate
or receive cross-server live reply requests.
Use the following task list to enable cross-server live reply between Cisco Unity and Connection sites,
or to enable cross-server transfers and live reply between Connection locations (either in a single site or
between two Connection sites). The cross references take you to detailed procedures.
1.

Determine whether each location will be an originating location, a receiving location, or both.

2.

For each originating location, make a list of the phone numbers the location must dial to reach the
receiving location servers.

Note

3.

You can enter only one dial string for each receiving location. If the originating location is
configured for multiple phone system integrations, you will need a dial string that all phone
system integrations can use to reach the receiving location.
Configure each receiving location so that it can handle incoming cross-server handoff requests.
If the receiving location is a Cisco Unity Connection server, see the Configuring a Cisco Unity

Connection Receiving Location to Allow Cross-Server DTMF Sequences from Cisco Unity
Locations section on page 6-6.
If the receiving location is a Cisco Unity server, see the Verifying That a Receiving

Cisco Unity Location Routes Calls to the Opening Greeting section on page 6-18.
4.

If Cisco Unity Connection locations will receive cross-server handoff requests from Cisco Unity
servers, configure the Connection locations to allow cross-server DTMF sequences that begin
with #. See the Configuring a Cisco Unity Connection Originating Location to Perform
Cross-Server Sign-In Requests section on page 6-7.

5.

For each originating location, enable the applicable cross-server features and enter the pilot numbers
of the receiving locations from the list that you created in Task 2.
If the location is a Cisco Unity Connection server, see the Configuring a Cisco Unity

Originating Location to Perform Cross-Server Sign-In Requests section on page 6-8.

If the location is a Cisco Unity server, see the Configuring a Cisco Unity Originating Location

to Perform Cross-Server Live Reply Requests section on page 6-21.

6.

Test the cross-server live reply functionality. See the Testing Cross-Server Sign-In section on
page 6-9.

Networking Guide for Cisco Unity Connection Release 9.x

6-17

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Live Reply in Cisco Unity Connection 9.x

Procedures: Enabling Cross-Server Live Reply

Configuring a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff Requests
By default, each Cisco Unity Connection server is configured to ignore cross-server handoff requests.
To enable cross-server features, you must configure the receiving location to accept requests and also
verify that the location routes incoming calls to a call handler. Do the following two procedures to
configure each receiving Connection location to accept handoffs. (Doing so allows the location to
receive handoffs of all typessign-in, transfer, and live reply.)

To Configure a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff

Requests, page 6-18

To Verify That Call Routing Rules Are Set to Route Calls to a Call Handler Greeting, page 6-18

To Configure a Cisco Unity Connection Receiving Location to Accept Cross-Server Handoff Requests
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server handoffs for users
who are homed on that location (the receiving location), expand System Settings > Advanced, then
select Conversations.

Step 2

Check the Respond to Cross-Server Handoff Requests check box.

Step 3

Repeat the procedure on all remaining Connection receiving locations.

To Verify That Call Routing Rules Are Set to Route Calls to a Call Handler Greeting
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server handoffs, expand
Call Management > Call Routing and select Direct Routing Rules.

Step 2

Select the display name of the routing rule that applies to incoming cross-server calls from originating
locations.

Step 3

Verify that calls that match the rule are routed to a call handler.

Step 4

Repeat the procedure on all remaining Connection receiving locations.

Verifying That a Receiving Cisco Unity Location Routes Calls to the Opening Greeting
In order to accept cross-server handoff requests, each Cisco Unity server must be configured to route
calls to the Opening Greeting call handler. (This is the default when Cisco Unity is initially installed.)
Do the following procedure on each of the receiving Cisco Unity servers to verify that the call routing
rules are set properly to accept handoffs.

Note

For failover systems, do the procedure on both the primary and secondary servers.

Networking Guide for Cisco Unity Connection Release 9.x

6-18

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Live Reply in Cisco Unity Connection 9.x

To Verify That Call Routing Rules Are Set to Route Calls to the Opening Greeting
Step 1

In the Cisco Unity Administrator, on a location that will accept cross-server live reply handoffs, go to
the Call Routing > Direct Calls page.

Step 2

Verify that incoming cross-server calls from originating locations are routed to the Opening Greeting.
The Default Call Handler routing rule (which cannot be deleted or modified) sends calls to the Opening
Greeting. Therefore, if you have not added any routing rules, the server is already set to correctly process
cross-server calls.

Step 3

Repeat the procedure on all remaining Cisco Unity receiving locations.

Configuring a Cisco Unity Connection Receiving Location to Allow Cross-Server DTMF Sequences
from Cisco Unity Locations
The sequence of DTMF tones that an originating Cisco Unity location sends to the receiving location
begins with # (pound) and includes a second tone that distinguishes the type of handoff (sign-in, transfer,
or live reply). By default, the Cisco Unity Connection opening greeting and other call handlers are
configured to ignore any additional caller input following a # key. In such a configuration, all
cross-server handoffs will fail.
You have a couple of options for changing the behavior on a Connection receiving location so that
cross-server handoffs are performed successfully:

Change the opening greeting (or other existing call handler that will receive the cross-server handoff
calls based on your routing rule configuration) to allow additional input.

Create a new call handler and direct-call routing rule specifically to handle cross-server calls. The
direct call routing rule should route calls to the new call handler based on criteria that apply to
cross-server callsthe calling number of any originating Cisco Unity location, for example, or the
cross-server dial string that the originating locations dial to reach the receiving location. (If you do
not want other calls to match the routing rule, choose criteria that are unique to cross-server calls.)

Do the following procedure on each Connection receiving location to configure the opening greeting or
other call handler to allow additional input after the # key, and, optionally, to create a new direct-call
routing rule.
To Configure a Cisco Unity Connection Receiving Location to Allow Cross-Server DTMF Sequences from
Cisco Unity Locations
Step 1

In Cisco Unity Connection Administration, on a location that will accept cross-server sign-in handoffs,
expand Call Management, then select System Call Handlers.

Step 2

On the Search Call Handlers page, select the display name of the opening greeting or other call handler
that you want to modify, or select Add New to create a new call handler specifically for cross-server
calls.

Step 3

If you did not create a new call handler in Step 2, skip to Step 6. If you created a new call handler in
Step 2, on the New Call Handler page, enter basic settings, as applicable. (For field information, on the
Help menu, select This Page.)

Step 4

To configure the call handler to accept the cross-server DTMF sequence, do the following substeps:
a.

On the Edit menu, select Caller Input.

Networking Guide for Cisco Unity Connection Release 9.x

6-19

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Cross-Server Live Reply in Cisco Unity Connection 9.x

Step 5

Step 6

b.

On the Caller Input page, select #.

c.

Uncheck the Ignore Additional Input check box.

d.

Select Save.

If you created a new call handler in Step 2, create a new direct-call routing rule to send calls from the
Cisco Unity servers to the call handler for processing:
a.

Expand Call Management > Call Routing, then select Direct Routing Rules.

b.

On the Direct Routing Rules page, select Add New.

c.

On the New Direct Rule page, enter the name of the new rule in the Display Name field.

d.

Select Save.

e.

On the Edit Direct Rule page, for Send Call To, select Call Handler, then select the name of the call
handler you added in Step 2.

f.

Select Save.

g.

Under Routing Rule Conditions, select Add New.

h.

Configure the routing rule condition to match cross-server calls from Cisco Unity servers. For
example, use the Calling Number field to match the phone numbers of the Cisco Unity ports that
answer user calls.

i.

Select Save.

j.

On the Edit menu, select Edit Direct Routing Rule.

k.

Repeat g. through j. for each additional number or number pattern that you need to match
cross-server calls.

Repeat the procedure on all remaining Connection receiving locations.

Configuring a Cisco Unity Connection Originating Location to Perform Cross-Server Live Reply and
Transfer Requests
By default, a Cisco Unity Connection location will not attempt to perform a cross-server live reply. Note
that when you enable cross-server live reply on Connection, cross-server transfer is automatically
enabled. Do the following procedure to enable cross-server transfer and live reply in on any Connection
originating locations.
To Configure a Cisco Unity Connection Originating Location to Perform Cross-Server Live Reply and Transfer
Handoff Requests
Step 1

In Cisco Unity Connection Administration, on a location that transfers calls to remote users (the
originating location), expand Networking, then select Locations.

Step 2

On the Search Locations page, select the Display Name of a remote location that will accept cross-server
live reply and transfer handoffs for users who are homed on this location (the receiving location).

Step 3

On the Edit Location page for the receiving location, do the following to initiate cross-server features to
this receiving location:
a.

To enable cross-server transfer and live reply to the remote location, check the Allow Cross-Server
Transfer to this Remote Location check box.

Networking Guide for Cisco Unity Connection Release 9.x

6-20

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Cross-Server Live Reply in Cisco Unity Connection 9.x

b.

Note

Step 4

You can enter only one dial string for each receiving location. If the originating location is
configured for multiple phone system integrations, enter a dial string that all phone system
integrations can use to reach the receiving location.

Repeat Step 2 and Step 3 for each receiving location that accepts cross-server transfer handoffs from this
location.

Tip

Step 5

Enter the dial string that this location will use to call the receiving location when performing the
handoff (for example, the pilot number of the receiving location).

After you have saved the changes on a page, use the Next and Previous buttons to quickly
navigate through each location in the organization.

Repeat the procedure on all remaining Connection originating locations.

Configuring a Cisco Unity Originating Location to Perform Cross-Server Live Reply Requests
By default, a Cisco Unity originating location will not attempt to perform a cross-server live reply to any
other locations. Do the following procedure to enable cross-server live reply on any Cisco Unity
originating locations.

Note

If the system is using failover, do the following procedure on both the primary and secondary server,
because most of the settings on the Network > Dialing Domain Options page are stored in the registry.
(Registry settings are not replicated to the secondary server.)
To Configure a Cisco Unity Originating Location to Perform Cross-Server Live Reply Requests

Step 1

In the Cisco Unity Administrator, go to the Network > Dialing Domain Options page.

Note

If the Dialing Domain Options link is unavailable on the system, you must configure the dialing
domain on the Primary Location Settings page in the Cisco Unity Administrator.

Step 2

In the Live Reply section, select the Subscribers with Class of Service Rights Can Reply to Messages
from Subscribers Homed on Other Cisco Unity Servers by Calling Them check box, then select
Cross-Server Live Reply: Pass Control to the Called Subscribers Cisco Unity Server. (Selecting
Release Calls to the Phone System disables cross-server transfers originating from this server. Instead
of handing off calls to the home server of the user, Cisco Unity will attempt a release transfer to the
Cross-Server Transfer Extension configured for the user. This will fail if a Connection user does not have
a Cross-Server Transfer Extension configured.)

Step 3

In the Pilot Numbers for Cross-Server Logon, Transfer, and Live Reply section, enter the pilot number
in the Dial String field for each server displayed in the table. (Note that the pilot numbers that you enter
are stored in the SQL Server database UnityDb on the Cisco Unity server. Therefore, if the system is
using failover, the pilot numbers will be replicated to the secondary server.)

Networking Guide for Cisco Unity Connection Release 9.x

6-21

Chapter 6 Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Step 4

Select the Play Prompt During Cross-Server Logon, Transfer, and Live Reply so That Callers
Know Something Is Happening check box. Although playing the One moment please prompt is
optional, we recommend that you check the check box because the cross-server process can take several
seconds before the caller is transferred.

Step 5

Select Save.

Step 6

Repeat the procedure on all remaining Connection originating locations.

Testing Cross-Server Live Reply

We recommend that you test cross-server live reply before allowing callers to use the feature.
For failover systems, first test that the primary destination servers answer cross-server calls. Then
manually fail over the destination servers to verify that the secondary server answers cross-server calls.
If the destination servers are properly configured for failover, the secondary server should answer
cross-server calls when the primary server is unavailable.
To Test Cross-Server Live Reply
Step 1

Create a new user account (or use an existing account) on each location for testing purposes. Verify that
users belong to a class of service in which live reply is enabled. Also verify that the user account
information has replicated to all of the servers that you will be testing. The time that it takes for the user
data to replicate depends on your network configuration and replication schedule.

Step 2

Sign in as a user on an originating location and send a message to the test users on other locations.

Step 3

For each user that receives the test message, sign in, listen to the message, and choose to call the sender.
Verify that:

The One moment please prompt is played (if configured to do so).

The call is transferred to the user phone or the greeting, according to the call transfer settings of the
called user.

Notable Behavior for Cross-Server Sign-In, Transfers, and Live

Reply in Cisco Unity Connection 9.x
This section provides information about notable expected behavior associated with cross server sign-in,
transfers and live reply.
See the following sections:

Cross-Server Sign-In Does Not Provide User Workstation Client Sign-In Access, page 6-23

Users Are Always Prompted for a Password During Cross-Server Sign-In Between Cisco Unity
Connection and Cisco Unity, page 6-23

Factors That Can Cause Delays During Cross-Server Handoff, page 6-23

Increased Port Usage with Cross-Server Features, page 6-23

Transfer Overrides on Cross-Server Transfers, page 6-24

Networking Guide for Cisco Unity Connection Release 9.x

6-22

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Using Cross-Server Features with the Display Original Calling Number on Transfer Parameter,
page 6-24

Cross-Server Sign-In Does Not Provide User Workstation Client Sign-In Access
Users must access their home server (or cluster) when using client applications such as the
Cisco Personal Communications Assistant (Cisco PCA) and IMAP clients. The phone interface is the
only client that provides cross-server sign-in capability.

Users Are Always Prompted for a Password During Cross-Server Sign-In

Between Cisco Unity Connection and Cisco Unity
When a Cisco Unity Connection user calls a Cisco Unity location from a known extension and is
transferred to the home location by using cross-server sign-in, the receiving Connection location can
identify the user but does not recognize that the user is calling from a known extension. For this reason,
the user is always prompted for a password, regardless of whether the Skip Password When Calling From
a Known Extension setting is selected on the System Settings > Advanced > Conversation page in
Cisco Unity Connection Administration.
Likewise, when a Cisco Unity user calls a Cisco Unity Connection location from a known extension and
is transferred to the home location by using cross-server sign-in, the user is always prompted for a
password, regardless of whether Prompt for Phone Password is set to Only When User Calls from an
Unknown Extension (on the Phone Password page for the user).

Factors That Can Cause Delays During Cross-Server Handoff

The following factors can contribute significantly to delays in cross-server call handoff:

Longer user extensions. A four-digit extension does not take as long to dial during the handoff as a
ten-digit extension.

Longer dialing strings to reach the receiving location. A four-digit dialing string does not take as
long to dial as a ten-digit dialing string.

Multiple elements (such as PIMG/TIMG units, voice gateways, TDM trunks, and PSTN interfaces)
in the call path between the originating location and the receiving location. More elements in the
call path require more processing time for handing off cross-server calls.

In your environment, these factors can create delays that may cause the cross-server features to be
unusable or unfeasible for callers. You must test your cross-server configuration on a representative call
path in your environment to determine whether the delays that callers experience are acceptable.

Increased Port Usage with Cross-Server Features

The cross-server features require the use of ports on both the originating and receiving locations.
Depending on how busy your servers are, you may need to add more ports or an additional server before
enabling these features. You may also need to adjust how ports are configured. For example, you may
need to enable more ports to accept incoming calls.

Networking Guide for Cisco Unity Connection Release 9.x

6-23

Chapter 6 Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

After enabling the cross-server features, we recommend that you monitor activity on the servers closely
until you are confident that the servers can handle the increased load. For Cisco Unity Connection
servers, you can use the Port Activity report in Cisco Unity Connection Serviceability to monitor port
usage. For Cisco Unity servers, you can use the Port Usage Analyzer for this task. The Port Usage
Analyzer is available in the Report Tools section of Tools Depot. See Port Usage Analyzer Help for
detailed instructions. Be sure to also monitor the Windows Event Viewer on any originating and
receiving Cisco Unity servers for event log messages related to problems with ports.

Transfer Overrides on Cross-Server Transfers

When a caller enters an extension in the automated attendant followed by the digits #2, the caller will
be routed directly to the greeting for the extension entered without a transfer being attempted. This is
known as the transfer override digit sequence.
Cisco Unity Connection 9.x automatically supports the transfer override sequence between networked
locations. For Cisco Unity servers, by default the transfer override digit sequence is ignored when the
user who is associated with the extension preceding the #2 is homed on another server in the dialing
domain. If you want to enable the transfer override digit sequence for users who are homed on other
locations in the dialing domain, including Connection locations, do the following procedure on each
Cisco Unity server that will originate cross-server transfer requests.
To Enable Transfer Override on Cross-Server Transfers from a Cisco Unity Location
Step 1

On the Cisco Unity server desktop, double-click the Cisco Unity Tools Depot icon.

Step 2

In the left pane, under Administrative Tools, double-click Advanced Settings Tool.

Step 3

In the Unity Settings pane, select NetworkingAllow Transfer Override on Cross-Server Transfer
Handoff.

Step 4

In the New Value list, select 1, and then select Set.

Step 5

When prompted, select OK.

You do not need to restart the Cisco Unity software or server when you make a change.

Note

For Cisco Unity failover, registry changes on one Cisco Unity server must be made manually on
the other Cisco Unity server, because registry changes are not replicated.

Using Cross-Server Features with the Display Original Calling Number on

Transfer Parameter
When Cisco Unity Connection (and/or Cisco Unity) is integrated with Cisco Unified Communications
Manager, the Display Original Calling Number on Transfer from Cisco Unity service parameter in Cisco
Unified CM can interfere with the cross-server handoff, because the receiving location does not
recognize that the incoming cross-server handoff call is from another location.

Networking Guide for Cisco Unity Connection Release 9.x

6-24

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Do the following tasks so that cross-server handoffs complete properly between locations when this
service parameter is set in Cisco Unified CM. In the task list, you create a special directory number for
each receiving location that is used only during cross-server handoffs, so that the receiving location
recognizes the call as a handoff.
Task List for Configuring a Cross-Server Directory Number for Cross-Server Features
1.

In Cisco Unified Communications Manager Administration, create a new directory number (for
example, on a CTI route point) for each location that receives cross-server sign-in, transfer, or live
reply calls. Configure the new directory number to always forward calls to the pilot number for the
location. See the Directory Number Configuration chapter of the applicable Cisco Unified
Communications Manager Administration Guide for your release of Cisco Unified CM, at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html.

2.

Configure each receiving location with a forwarded call routing rule that sends calls in which the
forwarding station equals the locations new cross-server directory number to the Opening Greeting
call handler. See the Adding Forwarded Call Routing Rules to Destination Locations for
Cross-Server Calls section on page 6-25.

3.

Update each originating location to dial the cross-server directory number of the receiving location
during cross-server calls, rather than the pilot number. See the Configuring the Cross-Server
Directory Number as the Dial String on Originating Locations section on page 6-27.

Adding Forwarded Call Routing Rules to Destination Locations for Cross-Server Calls
This section contains two procedures. Do either or both of the procedures, depending on whether you
have Cisco Unity Connection and/or Cisco Unity receiving locations:

To Add a Forwarded Call Routing Rule to Cisco Unity Connection Receiving Locations, page 6-25

To Add a Forwarded Call Routing Rule to Cisco Unity Receiving Locations, page 6-26

To Add a Forwarded Call Routing Rule to Cisco Unity Connection Receiving Locations
Step 1

In Cisco Unity Connection Administration on any one of the Connection receiving locations, create the
new forwarded routing rule:
a.

Expand Call Management, then expand Call Routing.

b.

Select Forwarded Routing Rules.

c.

On the Forwarded Routing Rules page, select Add New.

d.

On the New Forwarded Rule page, enter the name of the new rule in the Display Name field.

e.

Select Save.

f.

On the Edit Forwarded Routing Rule page, for Send Call To, select Call Handler. From the call
handler drop-down list, select Opening Greeting.

g.

Select Save.

h.

On the Edit Forwarded Routing Rule page, under Routing Rule Conditions, select Add New.

i.

On the New Forwarded Routing Rule Condition page, select Forwarding Station. From the
forwarding station drop-down list, select Equals. In the text box, enter the new cross-server
directory number for this location.

j.

Select Save.

Networking Guide for Cisco Unity Connection Release 9.x

6-25

Chapter 6 Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Step 2

Return to the Forwarded Routing Rules page by selecting Forwarded Routing Rules > Forwarded
Routing Rules, or by navigating to Call Management > Call Routing > Forwarded Routing Rules.

Step 3

Check the order of forwarded routing rules on the page. If the new routing rule that you created in Step 1
is not at the top of the table (in order of descending precedence) do the following substeps to move the
new routing rule to the top of the forwarded routing rules table:

Step 4

a.

On the Forwarded Routing Rules page, select Change Order.

b.

On the Edit Forwarded Routing Rule Order page, select the Display Name of the new routing rule
that you created in Step 1.

c.

Select the up arrow icon below the table to move the rule to the top position. (You may need to select
the icon multiple times.)

d.

Select Save.

Repeat the procedure for each remaining Connection receiving location.

To Add a Forwarded Call Routing Rule to Cisco Unity Receiving Locations

Step 1

Step 2

In the Cisco Unity Administrator on any one of the Cisco Unity receiving locations, create the new
forwarded routing rule:
a.

Navigate to Call Management > Call Routing.

b.

Select Forwarded Calls.

c.

Select the Add icon.

d.

In the Add a Call Routing Rule dialog box, enter the name of the new rule in the Name field.

e.

Select Add.

f.

In the Forwarding Station field, enter the new cross-server directory number for this location.

g.

In the Send Call To field, select Call Handler. Then, select Select Call Handler.

h.

In the Call Handler Selection box, find and select the Opening Greeting call handler, then select
Select.

i.

Select Save.

Check the order of forwarded routing rules on the page. If the new routing rule that you created in Step 1
is not at the top of the table (in order of descending precedence) do the following substeps to move the
new routing rule to the top of the forwarded routing rules table:
a.

Select Change Rule Order.

b.

On the Forwarded Calls Rules Reorganization page, select the Display Name of the new routing rule
that you created in Step 1.

c.

Select Up to move the rule to the top position. (You may need to select Up multiple times.)

d.

Select Close.

Step 3

Select the Save icon.

Step 4

Repeat the procedure for each remaining Cisco Unity receiving location.

Networking Guide for Cisco Unity Connection Release 9.x

6-26

Chapter 6

Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Configuring the Cross-Server Directory Number as the Dial String on Originating Locations
This section contains two procedures. Do either or both of the procedures, depending on whether you
have Cisco Unity Connection and/or Cisco Unity originating locations:

To Configure the Cross-Server Directory Number as the Dial String on Cisco Unity Connection
Originating Locations, page 6-27

To Configure the Cross-Server Directory Number as the Dial String on Cisco Unity Originating
Locations, page 6-27

To Configure the Cross-Server Directory Number as the Dial String on Cisco Unity Connection Originating
Locations
Step 1

In Cisco Unity Connection Administration, on any one of the Connection locations that originate
cross-server calls, expand Networking, then select Locations.

Step 2

On the Search Locations page, select the Display Name of a receiving location).

Step 3

On the Edit Location page for the receiving location, change the dial string that this location will use to
call the receiving location to the new cross-server directory number of the receiving location.

Step 4

Repeat Step 2 and Step 3 to configure each receiving location that accepts cross-server handoffs from
this location.

Tip

Step 5

After you have saved the changes on a page, use the Next and Previous buttons to quickly
navigate through each location in the organization.

Repeat the procedure on all remaining Connection originating locations.

To Configure the Cross-Server Directory Number as the Dial String on Cisco Unity Originating Locations
Step 1

In the Cisco Unity Administrator, go to the Network > Dialing Domain Options page.

Step 2

In the Pilot Numbers for Cross-Server Logon, Transfer, and Live Reply section, enter the new
cross-server directory number in the Dial String field for each server that is displayed in the table. (Note
that the numbers that you enter are stored in the SQL Server database UnityDb on the Cisco Unity server.
Therefore, if the system is using failover, the numbers will be replicated to the secondary server.)

Step 3

Select Save.

Step 4

Repeat the procedure on all remaining Cisco Unity originating locations.

Networking Guide for Cisco Unity Connection Release 9.x

6-27

Chapter 6 Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x
Notable Behavior for Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 9.x

Networking Guide for Cisco Unity Connection Release 9.x

6-28

INDEX

overview

6-1

search space considerations

addressing options

6-2

cross-server live reply

for non-networked phone systems

VPIM Networking

1-13

4-18

alternate names, adding for VPIM locations

audio format for VPIM Networking

4-14

definition

1-12

overview

6-15

prerequisites

4-18

procedures
task list

6-16
6-17

6-16

cross-server sign-in

B
blind addressing, VPIM Networking

4-18

definition

1-12

overview

6-3

prerequisites

Bulk Administration Tool

creating VPIM contacts

procedures

4-7, 4-8

errors, correcting (VPIM)

task list

4-9

6-4
6-5

6-4

cross-server transfer

C
Cisco Unity, changing a site gateway

6-9
6-11

6-10

CSV files

5-4

correcting errors for Bulk Administration Tool

linking to Cisco Unity

linking two sites

creating VPIM contacts

1-3

2-1

removing a location

4-7

2-3

delivery locations, creating for VPIM

5-1

removing intersite link between two sites

dialing domains

5-6

4-6

1-15

dial plan

2-2

Cisco Unity sites, linking to Cisco Unity Connection

Cisco Voicemail Organization, definition

1-2

1-3

addressing options
considerations
directory size limits

cross-server features
notable behavior

4-9

2-16

procedures to setting up

task list

6-9

task list

5-3

1-3

prerequisites

overview
procedures

intersite link with Cisco Unity, removing

linking

1-12

prerequisites

5-3

Cisco Unity Connection site

changing the gateway

definition

6-22

1-13

1-13
1-10

directory synchronization
Book Title

78-xxxxx-xx

IN-1

Index

between Cisco Unity and Cisco Unity Connection

sites 1-8
between two Connection sites

between two Connection sites

1-7

within a Cisco Unity Connection site

within a Cisco Unity Connection site

DNS, resolving names with IP addresses

1-5
4-4

S
search spaces

1-15

servers, linking

2-7

site, definition
gateway

1-1

system distribution lists and messaging

changing

1-5

1-7

1-11

5-3

changing for a Cisco Unity site

5-3

V
VPIM contacts

after creating
identified user messaging

1-14

intersite link between Cisco Unity and Cisco Unity

Connection
prerequisites
procedures
task list

3-1

4-11

correcting CSV errors for Bulk Administration

Tool 4-9
creating

4-7

creating by using Bulk Administration Tool

3-4

creating by using CSV files

3-2

4-7

creating with Connection Administration

definition

1-2

removing

5-6

customizing directory update settings

deleting

intrasite links, definition

1-1

location, removing

4-14

4-6

customizing
2-7

4-11

VPIM locations
creating

4-9

4-15

adding alternate names

linking servers

4-7

creating with Bulk Administration Tool

intersite links

4-8

4-6

VPIM Networking
5-1

adding alternate names for VPIM locations

4-14

adding VPIM contacts with Connection

Administration 4-9

addresses

name resolution, VPIM

4-4

4-17

addressing options

4-18

after creating VPIM contacts

audio formats

4-11

4-18

configuring remote voice messaging system

replication

creating VPIM contacts

between Cisco Unity and Cisco Unity Connection

sites 1-8

4-15

4-7

creating VPIM contacts with Bulk Administration

Tool 4-7, 4-8

Book Title

IN-2

78-xxxxx-xx

Index

creating VPIM locations

4-6

customizing VPIM contact directory update

settings 4-11
customizing VPIM locations
definition

1-5

deleting VPIM contacts

design decisions
DNS

4-6

4-15

4-3

4-4

messages

4-16

messaging similarities and limitations

overview

4-1

prerequisites

4-2

removing a VPIM location

4-15

resolving names with IP addresses

sample message
setting up

4-18

4-4

4-16

4-1

setup procedures

4-3

using CSV files for creating VPIM contacts

4-7

verifying connectivity with remote voice messaging

system 4-5

Book Title
78-xxxxx-xx

IN-3

Index

Book Title

IN-4

78-xxxxx-xx