Setting Up a Unity Connection 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 Unity Connection site concepts, you should first read the “Overview of Networking Concepts” chapter and then review the task list and procedures before beginning the setup.
You can link up to ten 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 Unity Connection version 15. You cannot link more than two sites together.) For procedures, see the “Linking Two Unity Connection Sites” section.
Prerequisites for Setting Up a Unity Connection Site
Before starting the setup, verify that the following prerequisites have been met on each server that joins 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 15, available at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/requirements/b_15cucsysreqs.html.
-
Unity Connection is already installed.
-
The servers networked together are directly accessible through TCP/IP port 25 (SMTP), or SMTP messages are routable through an SMTP smart host.
-
For Unity 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 Unity Connection site, you should be familiar with the concepts in the “Dial Plan” section of the “Call Management” chapter of the System Administration Guide for Cisco Unity Connection Release 15, available at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/administration/guide/b_15cucsag.html.
Task List for Setting Up a Unity Connection Site
Use this task list to set up a networking site between Unity Connection servers or clusters. The cross-references take you to detailed procedures.
If you have a Unity Connection cluster, do the tasks only on the publisher server.
-
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.
-
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 Each Unity Connection Server has a Unique Display Name and SMTP Domain” section.
If the display name of a server matches the display name of another server on the site, the server cannot join the site. Likewise, if the SMTP domain matches the SMTP domain of another server on the site, the server cannot join the site.
-
Start by linking two Unity Connection servers together to create a site, then link additional servers to any location in the site. See the “Linking Unity Connection Servers with an Intrasite Link” section.
-
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 Unity Connection cluster), configure the smart host, and configure the applicable locations to route through the host. See the “Configuring a Smart Host” section.
Note
For each Unity 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.
-
Verify that replication is complete among locations. See the “Checking Replication Status Within a Site” section on page 2-11.
-
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 Unity Connection Sites” section on page 2-12.
-
Secure the site so that message transmissions are not misdirected. See the “Securing the Unity Connection Site” section on page 2-12.
-
Optionally, set up cross-server features. See the “Cross-Server Sign-In, Transfers, and Live Reply” chapter.
-
Test the site. See the “Testing the Intrasite Setup” section on page 2-12.
-
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-14.
-
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 Unity Connection VPIM Locations and Contacts” section on page 2-15.
-
If you have not already done so, set up VPIM Networking to connect the Unity Connection locations to any other VPIM-compatible voice messaging systems. See the “VPIM Networking” chapter.
-
Optionally, create a mapping of which users are homed on which location. See the “Mapping Users to Their Home Locations” section on page 2-15.
-
Optionally, if you have a large site that includes locations running Unity Connection 14, 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 Unity Connection Digital Networking Replication Agent services on these locations.
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 Unity Connection Administration affect the replication agent (and also affect intrasite messaging between users as well as other features that use SMTP for message transmission).
Procedures for Setting Up a Unity Connection Site
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 Unity Connection site but support the Voice Profile for Internet Mail (VPIM) protocol (for example, Cisco Business Edition, Unity Connection servers, or other VPIM-compatible systems), use VPIM Networking to connect them.
Follow the given approaches:
-
Unless your servers are already configured for VPIM, set up the site first, then set up VPIM Networking.
-
Select a single Unity 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 Unity 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” section.
-
If you are migrating a VPIM location to a Unity Connection site (for example, because you used VPIM Networking to connect two or more Unity Connection servers and have upgraded the servers to Unity Connection 15) set up the Unity Connection site first. After the directory is fully replicated and you have tested message exchange between the Unity 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 Unity 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:
-
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 select 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 Unity Connection user data with user data in an LDAP directory, you should configure Unity 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 use to call this server, if cross-server sign-in or transfer is configured on other servers to hand off calls to this server.
-
Verifying Each Unity Connection Server has a Unique Display Name and SMTP Domain
Each Unity Connection server that you join to a Unity Connection site must have a unique display name. The display name must be unique both among Unity Connection locations and among VPIM locations. If the display name is not unique, the server cannot join the site. For new Unity 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 Unity 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 |
Select a display name for each server that is descriptive and that helps you identify the location when it is listed among all locations in the organization in Cisco Unity Connection Administration. |
Each Unity Connection server that you join to the site must also have a unique SMTP domain, both among Unity 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 need to disrupt messaging to the VPIM location while doing the migration—either 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" section.)
Do the following procedure to Verify each Unity Connection server :
Procedure
Step 1 |
Check the Display Name of the first server:
|
Step 2 |
Check the SMTP domain of the first server:
|
Step 3 |
Check the Display Name and SMTP Domain Name of all VPIM locations homed on the local server:
|
Step 4 |
Repeat Step 1 through Step 3 on each location that is 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 |
Change the Display Name of the Unity Connection location:
|
Step 7 |
To change the Display Name of a VPIM location:
|
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 |
To change the SMTP Domain of a Unity Connection location:
|
Step 11 |
To change the SMTP Domain Name of a VPIM location: |
Step 12 |
If there are any remaining SMTP domain conflicts, repeat Step 9 as necessary to resolve each conflict. |
Linking Unity Connection Servers with an Intrasite Link
To create a 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 Unity Connection cluster is linked to a site, the cluster counts as one location in the site.)
When you add a Unity Connection server to an existing Unity 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. You should 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.
Automatically Joining Two Unity Connection Servers
Procedure
Step 1 |
In Cisco Unity Connection Administration (on either server), expand Intrasite Links. (In Cisco Unity Connection, expand Networking, then select Unity Connection Locations.) select |
Step 2 |
Select Join Site. (In Unity Connection, select Join Unity Connection Network.) |
Step 3 |
On the Join Site page, select Automatically Join the Site. (In Unity Connection, on the Join Unity 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 Unity 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. |
Step 7 |
Select Auto Join Site. (In Unity Connection, 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 Unity Connection Digital Networking Replication Agent, continue with Step 9. Otherwise, skip the rest of this procedure and continue with the “Manually Joining Two Unity Connection Servers” procedure. |
Step 9 |
On either server, in Cisco Unity Connection Serviceability, select https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/serv_administration/guide/b_15cucservag.html.) . (For information on using Cisco Unity Connection Serviceability, see the Administration Guide for Cisco Unity Connection Serviceability Release 15, at |
Step 10 |
In the Server list, select the Unity Connection server, and select Go. |
Step 11 |
Under Optional Services, locate the Connection Digital Networking Replication Agent and select Activate. |
Step 12 |
Manually Joining Two Unity Connection Servers
Procedure
Step 1 |
In Cisco Unity Connection Administration (on either server), expand Networking> 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 Unity Connection 7.x, expand Networking, then select Unity Connection Locations.) |
Step 2 |
Select Join Site. (In Unity Connection 7.x, select Join Unity Connection Network.) |
Step 3 |
On the Join Site page, select Manually Join the Site. (In Unity 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 Unity Connection Administration on the second server. |
Step 6 |
In Unity Connection Administration on the second server, expand Networking> select Intrasite Links. (In Unity Connection 7.x, expand Networking, then select Unity Connection Locations.) |
Step 7 |
Select Join Site. (In Unity Connection 7.x, select Join Unity Connection Network.) |
Step 8 |
On the Join Site page, select Manually Join the Site. (In Unity 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 Unity 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 . |
Step 15 |
In the Server list, select the Unity Connection server, and select Go. |
Step 16 |
Under Optional Services, locate the Unity Connection Digital Networking Replication Agent and select Activate. |
Step 17 |
Configuring a Smart Host
SMTP is used to transmit both directory information and messages between 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 Unity 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 Unity Connection site, you would join ServerA, ServerB and ServerD together to form the site. Note the following:
-
On ServerA, you would configure the Unity 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 Unity Connection location for ServerD (which represents cluster 2) to route through the smart host.
-
On ServerD (the cluster 2 publisher), you would configure the Unity 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, 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:
-
Configure the SMTP smart host to accept messages from the Unity Connection server. If your site includes Unity 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.
-
Configure the Unity Connection server to relay messages to the smart host. See the “Configuring Unity Connection to Relay Messages to a Smart Host” procedure on page 2-9.
-
Configure the Unity Connection server to route messages to the other Unity Connection locations through the smart host. See the “Configuring Unity Connection to Route Inter-Location Messages through the Smart Host” procedure on page 2-9.
Configuring Unity Connection to Relay Messages to a Smart Host
Procedure
Step 1 |
In Cisco Unity Connection Administration, expand Smart Host. and select |
||
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. |
Configuring Unity Connection to Route Inter-Location Messages through the Smart Host
Procedure
Step 1 |
In Cisco Unity Connection Administration, expand Networking and 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 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.
Alternatively, you can configure each cluster location to route messages to every other location through a smart host; when you do this, the other Unity 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 establishes 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 Unity 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 Unity 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-8. 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.
Configuring Direct SMTP Access for Cluster Subscriber Servers
Procedure
Step 1 |
On a network location, in Cisco Unity Connection Administration, expand Server. and select |
||
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.
|
||
Step 5 |
Select Save. |
||
Step 6 |
On the Access IP Address page, check the Allow Unity 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 |
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 Unity 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 Unity Connection Administration.
Tip |
On Unity Connection 15 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” section of the “Using the Voice Network Map Tool” chapter of the Administration Guide for Cisco Unity Connection Serviceability Release 15 at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/serv_administration/guide/b_15cucservag.html. |
Checking Replication Status Within a Site Using Cisco Unity Connection Administration
Procedure
Step 1 |
In Cisco Unity Connection Administration on a server that is joined to the network, expand Intrasite Links. and select |
||||
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 Unity Connection Administration on ServerA shows that a directory push to ServerB is in progress, and the Unity Connection Administration on ServerB shows that a directory pull from ServerA is in progress.
|
||||
Step 3 |
To get more information about the status of replication with a particular remote location, expand Networking and select Locations, then 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 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 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 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 Unity 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 “Dial Plan” section of the “Call Management” chapter of the System Administration Guide for Cisco Unity Connection Release 15, available at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/administration/guide/b_15cucsag.html.
Securing the 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 Unity 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 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:
Verifying Messaging Between Users on Different Unity Connection Locations
Procedure
Step 1 |
Sign in to a Unity Connection location as a user. |
Step 2 |
Follow the prompts to record and send messages to users who are associated with other Unity Connection locations. |
Step 3 |
Sign in to the applicable Unity Connection location as the recipient user to verify that the message was received. |
Step 4 |
Verifying Call Transfers From the Automated Attendant to Users on Other Unity Connection Locations
Procedure
Step 1 |
From a non-user phone, call a Unity Connection location that has been configured to handle outside callers, and enter the extension of a user who is associated with another Unity Connection location. |
Step 2 |
Verify that you reach the correct user phone. |
Verifying Call Transfers from a Directory Handler to Users on Other Unity Connection Locations
Procedure
Step 1 |
From a non-user phone, call a Unity 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 Unity Connection location in the phone directory, and that the directory handler transfers the call to the correct user phone. |
Verifying Identified User Messaging Between Networked Users (When Identified User Messaging is Enabled)
Procedure
Step 1 |
Verify that Unity Connection plays an internal greeting for users who leave messages, by doing the following sub-steps:
|
Step 2 |
Verify that users are identified when the recipient listens to a message, by doing the following sub-steps:
|
Verifying Live Reply Between Users on Different Unity Connection Locations
Procedure
Step 1 |
From a user phone, call a user who is associated with another Unity Connection location, and allow the call to be forwarded to voicemail. |
Step 2 |
Leave a message. |
Step 3 |
Sign in to the applicable Unity 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 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 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/user/guide/phone/b_15cucugphone.html.) |
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:
-
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 “System Distribution List” chapter of the System Administration Guide for Cisco Unity Connection Release 15, available at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/administration/guide/b_15cucsag.html.
-
Create a new All Voicemail Users system distribution list on one location to use as the master list.
-
Add the lists from all locations as members of the master list.
-
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.)
Tip |
To avoid users generate large amounts of voice message traffic using reply-all to reply to messages sent to the master list, you should 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. |
Cleaning Up Unused Unity Connection VPIM Locations and Contacts
After migrating a 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 Unity 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 Unity 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”
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 Unity Connection location. The information in this report includes the user name and primary location. For more information, see the “Reports” section of the “Advanced System Settings” chapter in the System Administration Guide for Cisco Unity Connection Release 15, available at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/15/administration/guide/b_15cucsag.html.