Gradual Migration Using Intersite Networking
At a high level, the process of using a Cisco Voicemail Organization to link Cisco Unity and Cisco Unity Connection would look like this:
1. Build a networked mixed environment:
a. Upgrade Cisco Unity as needed to meet minimum requirements for Intersite networking.
b. Install and configure at least one Cisco Unity Connection 9.x server.
c. Begin initial preparation of search spaces and partitions on Connection. (For design considerations, see the “Partition Considerations” section.)
d. Join the Cisco Unity and Connection sites with an intersite link.
e. Complete the configuration of search spaces and partitions on Connection.
f. Complete the initial configuration of distribution lists. (For design considerations, see the “Distribution List Management” section.)
g. Set up intersite cross-server features.
2. Migrate groups of users over an extended time period:
a. Use COBRAS hot mode to move user accounts to Connection.
b. Reconfigure user phones to use Connection pilot numbers.
c. Optionally, configure access for migrated users to their old voice messages on the Cisco Unity server, and instruct users on how to access archived mailboxes.
3. Decommission (uninstall) each Cisco Unity server when all users on the server are migrated and archived mailboxes have expired.
For a high level overview of a Cisco Voicemail Organization that links Cisco Unity and Cisco Unity Connection sites, see the “
Overview of Networking Concepts in Cisco Unity Connection 9.x
” chapter of the
Networking Guide for Cisco Unity Connection
It is critical that the migration be viewed as a one-way flow. All associated tools, such as COBRAS and PDL Builder, are intended to assist in moving objects from the Cisco Unity site to Connection. There is no automated process to move users or distribution lists in the reverse direction, from Connection to Cisco Unity.
In most cases a gradual migration should focus on moving subscribers from one Cisco Unity location at a time. This will help reduce the cost and complexity of the overall Cisco Voicemail Organization. When all subscribers for a given location are migrated, the Cisco Unity server can be decommissioned and repurposed. A decommissioned server may even be repurposed as a Connection server if it meets the platform requirements for Cisco Unity Connection (see the
Cisco Unity Connection 9.x Supported Platforms List
For more information on implementing a gradual migration, including a detailed task list, see the “
Migrating from Cisco Unity to Cisco Unity Connection 9.x by Gradually Moving Data
” chapter of the
Reconfiguration and Upgrade Guide for Cisco Unity Connection
See the following sections for additional details:
Pre-Existing Dual Environments Using VPIM
With earlier releases of Cisco Unity and Cisco Unity Connection it was possible to maintain a mixed environment by using VPIM networking. These mixed environments can be greatly enhanced by utilizing the intersite networking features available in Connection Release 9.x. When the VPIM link has been replaced by an intersite link, the general migration process can follow a gradual migration as detailed in the “Gradual Migration Using Intersite Networking” section.
Note that it is not necessary to entirely remove the VPIM link between the two sites. Leaving the VPIM link in place will preserve routing for users who reply to messages that were sent previously. However, pre-existing VPIM contacts on both sides of the network may cause addressing conflicts. These contacts should be hidden or deleted. Also, VPIM on both sides must be configured not to automatically create VPIM contacts.
For example, consider an installation where John Smith is a Cisco Unity Connection user with extension 1234. In the pre-existing VPIM environment a VPIM contact account was created for John Smith and assigned extension 1234 within Cisco Unity. When intersite networking is established, Cisco Unity attempts to create a new Connection contact for John Smith. In some cases this creation fails entirely due to conflicts with the existing VPIM account. In other cases, the Connection contact is created, but the primary extension for John Smith (1234) is not associated with the new account.
On Connection, existing VPIM contacts can be hidden from users by reassigning them to a partition that is not addressable from any search space. Note that VPIM accounts at the Cisco Unity site cannot as easily be hidden. Also, existing VPIM accounts on Cisco Unity may prevent the proper intersite replication of corresponding Connection users. To avoid addressing and synchronization conflicts, in Cisco Unity, delete all VPIM contacts that are associated with the Connection location. This of course means that existing messages addressed from the VPIM contacts are no longer associated with the contact.
Any distribution lists—either system or private—that contain VPIM contacts should be updated to use the replicated Connection Networking subscribers instead. Note that such updates must be performed manually. Cisco Unity distribution lists that contain VPIM contacts will lose those members when the VPIM contacts are deleted as recommended above. In the reverse direction it is possible for Connection distribution lists to continue delivering messages via VPIM. However, even this becomes problematic as users are migrated to Connection. The VPIM contacts on Connection are not automatically updated during a COBRAS hot-mode migration. If a Connection distribution list contains a VPIM contact for a migrated Cisco Unity subscriber, messages to that list will be delivered to the archived mailbox of the subscriber on Cisco Unity.
Selecting Site Gateways
When establishing an intersite link between Cisco Unity and Cisco Unity Connection for a gradual migration, a server at each site must be designated as the site gateway. When networking has been established between the two sites, reassigning the role of site gateway to another server is not a simple task. Therefore, careful selection of the site gateways is critical. For basic prerequisites and considerations, see the “
Setting Up Networking Between Cisco Unity and Cisco Unity Connection 9.x Servers
” chapter of the
Networking Guide for Cisco Unity Connection
At the Cisco Unity site, care should be taken to select a server that can maintain the role of site gateway for the duration of the migration. For example, any server that is to be repurposed as a Connection server during the migration should not be selected. Also, if multiple dialing domains exist on the Cisco Unity site, selection of the site gateway will affect the resulting dial plan (see the “Fitting Cisco Unity Connection Partitions into Dialing Domains” section for additional details).
The role of site gateway does place nontrivial additional load on the server. Therefore, servers with the most available resources should be selected whenever possible. System load testing exposed performance impacts on the Cisco Unity site gateway related to the processing of directory information to and from the remote site. These impacts can be minimized by using a Platform Overlay 2 or 3 server as the site gateway. Impact can also be reduced by minimizing the number of regular subscribers or users homed on site gateways.
While there are no minimum bandwidth requirements between the two site gateways, HTTP or HTTPS connectivity is required. A DNS environment that allows FQDN resolution between the two site gateways is recommended. As long as this minimal connectivity can be met, priority should be given to other criteria discussed above.
Within the Cisco Unity site, dialing domains offer a very basic form of partitioning. When multiple dialing domains exist, extra planning is needed in deciding how the dialing domain topology will be integrated with Cisco Unity Connection search spaces and partitions.
See the following sub-sections for additional details:
Fitting Cisco Unity Connection Partitions into Dialing Domains
When networked with a Cisco Unity site, each Cisco Unity Connection location has just a single partition that is made available in Cisco Unity. At the Cisco Unity site, all Connection locations are assigned to the dialing domain of the site gateway. Cisco Unity attempts to add all incoming extensions from Connection into this single dialing domain. 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 are omitted from the Cisco Unity directory.
Figure 8-1 depicts a Cisco Voicemail Organization consisting of two 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 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 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 will not be available to users on Cisco Unity.
Figure 8-1 Extensions from the Partition You Select for Each Cisco Unity Connection Server Are Placed in the Dialing Domain of the Cisco Unity Site Gateway
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 9.x
” chapter of the
Networking Guide for Cisco Unity Connection
Cisco Unity automated attendant searches always treat imported 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 will not be able to contact Connection users through automated attendant searches.
Cisco Unity subscriber-addressing searches and directory handler searches treat imported Connection users as if they are homed on the Cisco Unity site gateway. On the site gateway, 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 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.
Fitting Dialing Domains into Cisco Unity Connection Partitions
Cisco Unity Connection does not carry over dialing domain information from Cisco Unity. For each Cisco Unity location, Connection creates a dedicated partition, as shown in Figure 8-2. You might have several Cisco Unity locations in a dialing domain, with a global, non-overlapping dial plan. Connection does not see this. It only sees the individual locations and creates distinct partitions for you to manage.
Figure 8-2 depicts the same Cisco Voicemail Organization shown in Figure 8-1. In this case, looking from the perspective of mapping Cisco Unity objects into Connection partitions, we see that three new partitions are created on the 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 Connection B.
Figure 8-2 A Single Cisco Unity Connection Partition is Automatically Generated for Each Cisco Unity Server And Replicated in the Connection Site
When intersite networking is initially configured between Cisco Unity and Connection, users who are homed on Connection are not able to dial or address messages to users on Cisco Unity. This is because the Connection search spaces do not contain the partitions that were auto-generated for Cisco Unity locations. After initial replication completes, Connection search spaces must be modified to include the new partitions. This needs to be done at each 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 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 Connection they can be assigned to any local partition on the 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 will then disappear. Therefore, focusing the user migration to one Cisco Unity server at a time can help reduce complexity at the Connection site.
Migrating Away from Dialing Domains
An intermediate goal of the migration might be to eliminate the need for multiple dialing domains. Doing so will reduce the complexity of an organization and typically will allow 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 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 will not be able to provide the same level of segregation.
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 8-3, Kelly and Avery can find Connection users in directory handler searches and address to them by 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 Connection A.
Figure 8-3 Example: Before Migrating Users from a Cisco Unity Site Segmented Into Two Dialing Domains to a Cisco Unity Connection Site with Two Partitions
When Kelly is migrated to Cisco Unity Connection A by 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 will also be 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 8-4. Similarly, Kelly can be assigned to a search space that will maintain 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 Connection. Even if none of Chris’s extensions are placed into Partition A1 (the partition that will replicate to Cisco Unity), Chris will still have a contact account created by Cisco Unity within Dialing Domain 1, as shown in Figure 8-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.
Figure 8-4 Example: After Migrating Users from a Cisco Unity Site Segmented Into Two Dialing Domains to a Cisco Unity Connection Site with Two Partitions
Interworking with Other Voice Messaging Networks
A Cisco Unity environment can use other voice messaging network types (Bridge, AMIS, VPIM or Trusted Internet). However, messages from Cisco Unity Connection users cannot be relayed to remote subscribers who are associated with these other Cisco Unity delivery locations. Instead, direct networking to these other locations must be established independently from the Connection site.
See the following sub-sections for additional details:
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 8-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.
Figure 8-5 Both Sites in a Cisco Voicemail Organization Must Be Independently Configured for VPIM
As users are migrated from Cisco Unity to 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.
Connection does not support Bridge or AMIS networking. If a remote messaging system supports only Bridge or AMIS networking, Connection users will not be able to address to users on those systems.
Distribution List Management
In a mixed Cisco Unity and Cisco Unity Connection network, directory synchronization can be configured to include system distribution lists. When this is done only addressing and routing information for the distribution lists is shared. Membership information for each list is stored and managed at the site where the list was created. However, with some careful advanced planning, it is possible to limit most list management activity to one site. This will reduce the need to jump between Cisco Unity and Connection administration for list maintenance.
See the following sub-sections for additional details:
System Distribution List Management on Cisco Unity Connection
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 Connection right away. This can be done by using Public Distribution List Builder (see Public Distribution List Builder Help for details, at
). When a distribution list is created in Connection, intersite networking can allow both Cisco Unity and 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 Connection. This is because 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.
A “Sales Staff” distribution list on Cisco Unity is populated by using a corresponding subscriber template. When intersite networking is introduced, the Cisco Unity Sales Staff list cannot be migrated over to 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 Connection. The distribution list on 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 Connection.
When the “Sales Staff – Unity only” distribution list has replicated from Cisco Unity to Connection, it can then be added as a nested member of the “Sales Staff” distribution list on Connection. The list on Connection is now the master “Sales Staff” distribution list. Users on 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 by 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 Connection becomes problematic when Cisco Unity is a unified messaging deployment and Connection users are using ViewMail for Outlook within the same Active Directory. The groups that Cisco Unity creates in Active Directory for replicated Connection system distribution lists can complicate matters for Connection users when they address messages via ViewMail for Outlook or other email clients. Connection users who try to address messages to such lists receive a non-delivery receipt in response. Currently, Connection does not provide a way to mitigate the issue for synchronized distribution lists by using SMTP proxy addresses like you can for Connection users.
Public Distribution List Management on Cisco Unity
When Cisco Unity and Cisco 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 will allow them to be fully synchronized with Active Directory. Distribution lists can be selectively enabled for directory replication to Connection.
Distribution lists populated via subscriber templates can be handled in a way similar to that discussed in the “System Distribution List Management on Cisco Unity Connection” section. Template-based lists from 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 Connection from users.
A “Sales Staff” distribution list on Cisco Unity is populated by using a corresponding subscriber template. When Connection Networking is introduced, the Cisco Unity Sales Staff distribution list cannot be migrated over to Connection because new sales staff may still be added to the Cisco Unity site during the gradual migration. Instead, a corresponding “Sales Staff – Connection Only” template and distribution list are created on Connection. This list on 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 Connection distribution list is replicated to Cisco Unity, its display name appears as “Sales Staff – 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 Connection by 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 Connection address to it via its replicated object, which by default shows up on Connection as “Sales Staff.” When a new mailbox is created by 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 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 Connection site.
Another caveat of managing distribution lists within Connection occurs as users are migrated to 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 for additional details.)
Hybrid Distribution List Management
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 Cisco Unity Connection” section and the “Public Distribution List Management on Cisco Unity” section, 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.
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 Distribution Lists
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 Cisco Unity Connection” section, the “Public Distribution List Management on Cisco Unity” section, and the “Hybrid Distribution List Management” section, 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.
Private Distribution Lists
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 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 will not be automatically updated during the migration. Unless the distribution list is manually edited, messages sent to it will continue to be delivered to the archived mailbox of the migrated user on Cisco Unity.
Cisco Unity and Cisco Unity Connection use different methods for securing messages. In particular, Connection is not able to decrypt secure messages that are sent from Cisco Unity. Therefore, by default, messages marked as secure will not be sent between the systems.
Optionally, you can configure both systems to enable delivery of secure messages between sites. However, in order for this to occur, all secure messages must be unencrypted as they traverse the network. An x-header is placed on the messages indicating whether they are intended to be secure. This allows the receiving site to apply secure handling of the messages when they arrive. For example, Cisco Unity can be configured to encrypt inbound messages that are flagged as secure as soon as they arrive.
Both Cisco Unity and Cisco Unity Connection can be configured to transcode all messages sent to the remote site. This may be required, for example, if the messages are stored locally in a format not supported at the remote site. However, use of the transcoding feature is likely to reduce audio quality of the messages. This is particularly noticeable if a message traverses between sites multiple times, for example, by being forwarded between sites, or when a distribution list contains remote users.
Consider the master “Sales Staff” distribution list on Cisco Unity Connection from the “System Distribution List Management on Cisco Unity Connection” section. A Cisco Unity user is able to send messages to this list by using the replicated “Sales Staff – voicemail” list found on Cisco Unity. The message is first routed across to the Connection site, introducing possible transcoding degradation. Connection members of the list receive the message in this state. But then the message is further routed back across to Cisco Unity so that it can be delivered to members of the “Sales Staff – Unity only” distribution list. This introduces a second generation of transcoding degradation. We now have up to two generations of degradation for a message that, in the end, was sent between two users on the same messaging system.
When COBRAS hot mode is used to migrate batches of users from Cisco Unity to Cisco Unity Connection, the user mailboxes on Cisco Unity are preserved but set to an archived state. These mailboxes are hidden in the directories and cannot be directly addressed to by other users. Because messages are not moved as part of the migration process, the archived mailboxes allow users to access their messages for a period of time on the Cisco Unity server.
Because distribution list membership is not automatically updated when users are migrated, archived mailboxes can still receive new messages. We strongly recommend that archived mailboxes be manually purged from all Cisco Unity distribution lists, both public and private. For public distribution lists an alternate solution is to use the Public Distribution List Builder tool to move lists from Cisco Unity to Connection. Even if the list already has archived mailboxes as members, Public Distribution List Builder maps and replaces those members with the correct corresponding user on Connection.
The archived mailboxes are hidden in the Cisco Unity Administrator. The only administrative tasks available for these mailboxes are password resets and deletes. These tasks can be done by using the Bulk Password Reset and Bulk Subscriber Delete tools. For additional information about the tools, see the respective tool Help at
Voice Name Replication
Replication of recorded voice names between Cisco Unity and Cisco Unity Connection is optional. It can be enabled in one direction, both directions, or not at all. Additionally, the voice names can be converted to a different codec when they are replicated between sites. For example, if disk space is a concern at one site the names can be converted to a more compressed format.
At the Connection site, Text to Speech is automatically used for users who do not have recorded names. This applies to remote Cisco Unity users also. This feature may provide a reasonable alternative to transcoding if disk space required for remote Cisco Unity users is a concern on Connection.
Often, new users on Connection choose not to record their own voice names because of the Connection Text to Speech feature. However, Cisco Unity does not have this Text to Speech feature, so users without recorded voice names are not accessible through directory handlers. Recorded voice names are also valuable during message addressing. Therefore, it generally is a good idea to encourage Connection users to record their voice names and to enable voice name replication to Cisco Unity.