When networked with a Cisco Unity site, each Unity Connection location has just a single partition that is made available in Cisco Unity. At the Cisco Unity site, all Unity Connection locations are assigned to the dialing domain of the site gateway. Cisco Unity attempts to add all incoming extensions from Unity Connection into this single dialing domain. Because extensions within a dialing domain must be unique, the collection of all partitions chosen across the Unity 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 are omitted from the Cisco Unity directory.

Figure 9-1 depicts a Cisco Voicemail Organization consisting of two Unity Connection locations with two partitions each, and three Cisco Unity locations in two dialing domains. In this case, Partition A1 is selected as the partition from which user extensions map to the dialing domain for Unity Connection A (in Cisco Unity Connection Administration this is known as the Local Partition That Cisco Unity Users Can Address to By Extension), and Partition B1 is selected to map to the dialing domain for Unity Connection B. All extensions from these partitions map to Dialing Domain 1 because the Cisco Unity site gateway, Cisco Unity X, is a member of Dialing Domain 1. These partitions should be chosen such that the extensions are unique across Partition A1, Partition B1, and Dialing Domain 1. Other partitions, such as Partition A2 and Partition B2, are not used by Cisco Unity. Any extensions in those partitions are not available to users on Cisco Unity.

For additional information on the local partition that Cisco Unity users can address to by extension, see the “About Linking Cisco Unity Connection and Cisco Unity Sites” section and the “Cisco Unity Dialing Domains and Cisco Unity Connection Users” section in the “Overview of Networking Concepts in Cisco Unity Connection 12.x” chapter of the Networking Guide for Cisco Unity Connection Release 12.x, at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/12x/networking/guide/b_12xcucnetx.html.

Cisco Unity automated attendant searches always treat imported. Unity Connection users as remote users. Therefore, the automated attendant search scope should be set to dialing domain on every Cisco Unity server. Callers within alternate dialing domains at the Cisco Unity site are not able to contact Unity Connection users through automated attendant searches.

Cisco Unity subscriber-addressing searches and directory handler searches treat imported Unity Connection users as if they are homed on the Cisco Unity site gateway. On the site gateway, Unity Connection users are found even if the scope is restricted to local server. For all other servers, a local server scope does not return any Unity Connection users. Dialing domain or global directory should be selected as the scope for these types of searches in order to provide consistent behavior between the site gateway and non site gateway servers.

Cisco Unity Connection does not carry over dialing domain information from Cisco Unity. For each Cisco Unity location, Unity Connection creates a dedicated partition, as shown in Figure 9-2. You might have several Cisco Unity locations in a dialing domain, with a global, non-overlapping dial plan. Unity Connection does not see this. It only sees the individual locations and creates distinct partitions for you to manage.

Figure 9-2 depicts the same Cisco Voicemail Organization shown in Figure 9-1. In this case, looking from the perspective of mapping Cisco Unity objects into Unity Connection partitions, we see that three new partitions are created on the Unity Connection A, the site gateway, when the sites are linked. Each partition corresponds to a Cisco Unity location. The new partitions are then replicated via intrasite networking to Unity Connection B.

When intersite networking is initially configured between Cisco Unity and Unity Connection, users who are homed on Unity Connection are not able to dial or address messages to users on Cisco Unity. This is because the Unity Connection search spaces do not contain the partitions that were auto-generated for Cisco Unity locations. After initial replication completes, Unity Connection search spaces must be modified to include the new partitions. This needs to be done at each Unity Connection location in the network. In most basic topologies, this might mean simply adding the new partitions to the default search space on each server. In complex environments consideration must also be given to all search spaces used by call handlers, directory handlers, call routing rules, and users. For example, the search space of a Unity Connection user must include the Cisco Unity partitions in order for that user to add remote site users to a private distribution list.

When users are migrated from Cisco Unity to Unity Connection they can be assigned to any local partition on the Unity Connection server. After a Cisco Unity server is fully migrated it is possible to remove the location from the network. If this is done, the auto-generated partition for that location then disappears. Therefore, focusing the user migration to one Cisco Unity server at a time can help reduce complexity at the Unity Connection site.

An intermediate goal of the migration might be to eliminate the need for multiple dialing domains. Doing so reduces the complexity of an organization and typically allows for more flexible dial plans. This is most effective when all servers in a dialing domain can be migrated simultaneously. If a subset of the dialing domain is migrated, connectivity between those users and the remaining dialing domain members may be disrupted. The users migrated can be provided with search spaces that allow access to any Cisco Unity Connection user as well as access to Cisco Unity subscribers in any dialing domain. However, any Unity Connection partition that is associated with those migrated users can only be mapped to the dialing domain of the Cisco Unity site gateway.

In some cases dialing domains are used to intentionally segregate users, for example to provide limited tenant services. In this case, the dialing domain of the Cisco Unity site gateway should be migrated first. If users from another dialing domain are migrated, Cisco Unity is not able to provide the same level of segregation.

Example

Before beginning the user migration from Cisco Unity to Cisco Unity Connection, Kelly and Avery are homed on Cisco Unity X, the site gateway, in Dialing Domain 1. Chris and Robin are homed on Cisco Unity Z in Dialing Domain 2. As shown in Figure 9-3, Kelly and Avery can find Unity Connection users in directory handler searches and address to them using their extensions in Partition A1, but they cannot reach Chris and Robin by the same means. Chris and Robin can address to each other but cannot address to Kelly or Avery or to users on Unity Connection A.

When Kelly is migrated to Cisco Unity Connection A using COBRAS hot mode, during the migration process, Partition A1 is selected for the target partition. This means that all existing extensions and alternate extensions for Kelly is also assigned to Partition A1. Because Partition A1 is replicated into Dialing Domain 1 of Cisco Unity, all dialing and addressing scopes within the Cisco Unity site that previously controlled access to Kelly are still effective, so Avery can still reach Kelly as usual, as shown in Figure 9-4. Similarly, Kelly can be assigned to a search space that maintains the same level of access that she had before the move. Of course the search space can also be made more granular or even provide additional access.

Now suppose Chris is also migrated to Unity Connection. Even if none of Chris’s extensions are placed into Partition A1 (the partition that replicates to Cisco Unity), Chris still have a contact account created by Cisco Unity within Dialing Domain 1, as shown in Figure 9-4. This means that Avery can now locate Chris when using dial by name with a directory handler or during subscriber message addressing. Robin is still unable to reach Kelly or Avery through directory handlers and subscriber message addressing, and can no longer reach Chris through these means.

A direct VPIM link can be established between the Cisco Unity Connection site and any other remote messaging network, although the VPIM link between Cisco Unity and the external system must also be maintained, as shown in Figure 9-5. Relaying messages across the intersite link to VPIM contacts is not possible in either direction. The servers acting as the VPIM bridgehead at each site can also act as the site gateway, though they do not need to.

As users are migrated from Cisco Unity to Unity Connection, the external VPIM system needs to be updated. The exact steps required depend on the specific system. Typically, contacts or message routing are managed according to the extension of each user. Therefore, migrating users in groups within continuous extension ranges is desirable. The administrative work required at the external system may become onerous if migrated users span multiple disjointed extension ranges.

System contacts can be manually created in Cisco Unity Connection that correspond to the Trusted Internet Subscribers on Cisco Unity.

Unity Connection does not support Bridge or AMIS networking. If a remote messaging system supports only Bridge or AMIS networking, Unity Connection users are not able to address to users on those systems.

Because the long term goal of a migration is to have everything on Cisco Unity Connection, it may be beneficial to move most, if not all, voicemail distribution lists, including membership, to Unity Connection right away. This can be done using Public Distribution List Builder (see Public Distribution List Builder Help for details, at http://ciscounitytools.com/Applications/Unity/PublicDistributionListBuilder/Help/PublicDLBuilder.htm). When a distribution list is created in Unity Connection, intersite networking can allow both Cisco Unity and Unity Connection users access to the list. The original list on Cisco Unity should then be removed.

Note that distribution lists that use subscriber templates for membership cannot be managed fully on Unity Connection. This is because Unity Connection does not use templates when creating contacts for replicated Cisco Unity subscribers. However, distribution list nesting can be used to manage template-based distribution lists that span both sites.

Example

A “Sales Staff” distribution list on Cisco Unity is populated using a corresponding subscriber template. When intersite networking is introduced, the Cisco Unity Sales Staff list cannot be migrated over to Unity Connection because new sales staff may still be added to the Cisco Unity site during the gradual migration. Instead, a corresponding “Sales Staff” template and distribution list are created on Unity Connection. The distribution list on Unity Connection is configured to replicate to remote sites over intersite links.

On Cisco Unity, the “Sales Staff” distribution list is renamed to “Sales Staff – Unity only.” If previously enabled, the “Show Distribution List in Email Server Address Book” attribute is removed. Using Public Distribution List Builder, the “Sales Staff – Unity only” distribution list is marked for replication to Unity Connection.

When the “Sales Staff – Unity only” distribution list has replicated from Cisco Unity to Unity Connection, it can then be added as a nested member of the “Sales Staff” distribution list on Unity Connection. The list on Unity Connection is now the master “Sales Staff” distribution list. Users on Unity Connection address to it directly while those on Cisco Unity address to it via its replicated object, which by default shows up on Cisco Unity as “Sales Staff – Voicemail.” When a new mailbox is created using the sales staff template at either site, that mailbox is immediately a recipient of the master “Sales Staff” distribution list.

Note that managing voicemail distribution lists on Unity Connection becomes problematic when Cisco Unity is a unified messaging deployment and Unity Connection users are using ViewMail for Outlook within the same Active Directory. The groups that Cisco Unity creates in Active Directory for replicated Unity Connection system distribution lists can complicate matters for Unity Connection users when they address messages via ViewMail for Outlook or other email clients. Unity Connection users who try to address messages to such lists receive a non-delivery receipt in response. Currently, Unity Connection does not provide a way to mitigate the issue for synchronized distribution lists using SMTP proxy addresses like you can for Unity Connection users.

When Cisco Unity and Unity Connection are both integrated (or unified in the case of Cisco Unity) it may be desirable to manage system distribution lists at the Cisco Unity site. This allows them to be fully synchronized with Active Directory. Distribution lists can be selectively enabled for directory replication to Unity Connection.

Distribution lists populated via subscriber templates can be handled in a way similar to that discussed in the “System Distribution List Management on Unity Connection” section on page 9-10. Template-based lists from Unity Connection can be nested into corresponding lists on Cisco Unity. In this case the Cisco Unity lists become the master lists. Partitions and search spaces can be used to hide the sub-lists on Unity Connection from users.

Example

A “Sales Staff” distribution list on Cisco Unity is populated using a corresponding subscriber template. When Unity Connection Networking is introduced, the Cisco Unity Sales Staff distribution list cannot be migrated over to Unity Connection because new sales staff may still be added to the Cisco Unity site during the gradual migration. Instead, a corresponding “Sales Staff – Unity Connection Only” template and distribution list are created on Unity Connection. This list on Unity Connection is configured to replicate to remote sites over intersite links. The list is assigned to a partition which is not addressable by users.

When the Unity Connection distribution list is replicated to Cisco Unity, its display name appears as “Sales Staff – Unity Connection Only – voicemail.” The “Show Distribution List in Email Server Address Book” attribute should be removed for this list. It can then be added as a nested member of the Cisco Unity “Sales Staff” distribution list. The Cisco Unity “Sales Staff” distribution list is marked for replication to Unity Connection using the Public Distribution List Builder tool.

The distribution list on Cisco Unity is now the master “Sales Staff” distribution list. Users on Cisco Unity address to it directly while those on Unity Connection address to it via its replicated object, which by default shows up on Unity Connection as “Sales Staff.” When a new mailbox is created using the sales staff template at either site, that mailbox is immediately a recipient of the master “Sales Staff” distribution list.

Note that this method for managing voicemail distribution lists limits dial plan flexibility. All distribution lists that are replicated from Cisco Unity to Unity Connection are assigned to the same auto-generated partition as all other objects from the Cisco Unity location. If greater granularity for search scope partitioning is needed, distribution lists need to be managed at the Unity Connection site.

Another caveat of managing distribution lists within Unity Connection occurs as users are migrated to Unity Connection. Distribution list membership within Cisco Unity is not adjusted when COBRAS hot mode is used to migrate users. Messages to the distribution list continue to be delivered to the Exchange mailboxes of the migrated users. While these messages are accessible via the archived subscriber account, the situation may cause confusion for users. (See the “Archived Mailboxes” section on page 9-13 for additional details.)

Managing distribution lists entirely on one site or the other is often not possible. In addition to the caveats mentioned in the “System Distribution List Management on Unity Connection” section on page 9-10 and the “Public Distribution List Management on Cisco Unity” section on page 9-10, distribution lists that contain contacts cannot be replicated. This is because messages that are sent across an intersite link cannot be further relayed to remote mailboxes that are not part of the Cisco Voicemail Organization. If a user at the remote site were to attempt addressing to such a list, a non-delivery receipt (NDR) would be generated for each undeliverable contact within the list.

Example

Suppose the Cisco Unity “Sales Staff” distribution list from the previous examples also contains VPIM contacts in addition to mailbox users. In order to use templates at both sites for populating a master “Sales Staff” list, two separate distribution lists are maintained at each site. Each site has a “Sales Staff – <site>” list that contains only users from the local site, and each list is assigned to the corresponding template at each site. (The list can be hidden from users but must be configured to replicate across the intersite link.) Next, each site also has a “Sales Staff” master distribution list. The master lists contain both “Sales Staff – <site>” lists plus any remote contacts such as VPIM users. The two master lists are not replicated between the sites. Users at each site must address to the corresponding local master list.

Nesting of distribution lists can be extremely useful. However, it is important to be aware of list membership when nesting. In each of the distribution list examples in the “System Distribution List Management on Unity Connection” section on page 9-10, the “Public Distribution List Management on Cisco Unity” section on page 9-10, and the “Hybrid Distribution List Management” section on page 9-11, two categories of lists are used at each site. The first category is local lists that are created with the intent of having list membership limited to the local site. The display names for the local lists should follow a naming convention that helps identify their role. The second category of lists is the master lists. The membership for the master lists includes objects from both sites. When nesting lists, a master list should never be nested inside another list. Following a well-defined naming convention can help ensure nesting loops are not created.

Additionally, any list that contains external contacts, such as VPIM subscribers, should not be nested within any list that is replicated. A naming convention for list display names could be extended to flag these lists. This would serve as a reminder to avoid placing such lists within a list that is intended for replication.

When users are migrated from Cisco Unity to Cisco Unity Connection, some private distribution list membership information may be lost. Backups only include membership information about full subscribers (users with mailboxes) and public distribution lists. Members of the private distribution list that are remote contacts (including Unity Connection users) or other private lists are not included in the private list membership backup.

Also, if a migrated user was included as a member of a private distribution list owned by a Cisco Unity subscriber who has not been migrated, that private distribution list is not automatically updated during the migration. Unless the distribution list is manually edited, messages sent to it continues to be delivered to the archived mailbox of the migrated user on Cisco Unity.