Migrating to Cisco Unity Connection


The Rise of Unity Connection

For years, Cisco Unity has been Cisco’s premiere voice messaging solution. Customers around the world implemented Unity and; in turn, it became the ruler which most competitive solutions would ultimately be measured against.

However, a combination of technological, organizational, and competitive factors brought about the need for a new voice messaging platform. A platform which offered the stability of an appliance, a robust and flexible feature-set, as well as the ability to bridge the gap between a standard voicemail-only solution and a full scale Unified Messaging solution.

Say hello to Cisco Unity Connection.

The Need for a Standalone Voice Messaging Appliance

As the advent of the appliance model triggered many customers to move away from Windows server applications, Cisco was able to bring Unity Connection to market at just the right time.

Unity Connection is Cisco’s first and only Linux-based voice messaging appliance. Based on the same platform as the highly successful Linux-based Cisco Unified Communications Manager, Unity Connection offers customers an increase in uptime coupled with a decrease in maintenance time. When compared to Unity, which is a Windows-based application, Unity Connection also requires significantly less setup time.

Where Does Unity Connection Fit In?

There are three primary voice messaging architectures. The simplest is referred to as voicemail only. Voicemail only is the most basic of voice messaging options because users primarily receive message via the Telephone User Interface or TUI, for short.

Going from one extreme to another, the fully integrated architecture is referred to as Unified Messaging. With Unified Messaging, there is a single message store where all messages (email, voicemail, and fax) are stored. In many cases, the message store is Microsoft Exchange. From a user perspective, this means that there is a single inbox where all messages are received. In many cases, this is the user’s Inbox within the Microsoft Outlook client.

In between voicemail only and Unified Messaging is an architecture referred to as Integrated Messaging. With Integrated Messaging, voicemail and email are stored separately. So Microsoft Exchange or possibly Lotus Notes may be the email message store; however, voicemail is stored on the voice messaging servers and users setup an IMAP folder within their email client to access voicemail. For users, this means that there are separate folders for email and voicemail. Email is received the standard Inbox and voicemail is received in an IMAP folder. Integrated Messaging is a nice middle ground because it can offer a user experience similar to Unified Messaging; however, technically things remain separated on the backend.

So, where does Unity Connection fit in? While all of Cisco’s voice messaging products are capable of providing voicemail only and/or integrated messaging for users, Unity Connection is the flagship product for both of these architectures. This is largely due to the stability, scalability, and abundance of features built into the Unity Connection platform. In addition, Unity Connection offers customers something other Cisco voice messaging product offerings do not…high availability via active-active clustering of two Unity Connection hosts.

As for Unified Messaging, Unity is still the only platform available from Cisco that provides complete integration into an existing Active Directory and Microsoft Exchange environment to provide Unified Messaging features for end users (note that support for Domino/Lotus Notes has been discontinued in the Unity 8x release).

Let the Migrations Begin

In the last few years, competition within the Unified Communications space has really picked up. Of course, Microsoft is working hard to make itself a true contender in relation to Cisco. One of the low hanging fruits for Microsoft has been Unified Messaging. While the complete story around Microsoft’s Unified Communications offering is sometimes a hard sell, Unified Messaging is another story. At the most basic level, it does make some sense. If the backend message store for Unity is ultimately Microsoft Exchange and Microsoft can now do Unified Messaging then why not just go with the Microsoft solution? Without suggesting one product over the other, one analogy would be this: If given the choice to buy a car directly from the manufacturer (the source) as opposed to a dealership (the middle man), most consumers would probably see going straight to the source as a rather enticing option. In today’s competitive landscape for Unified Messaging, Cisco Unity has become “the middle man” in many ways. In fact, Microsoft even changed the MAPI protocol for Exchange 2010 which has caused some heartburn for Cisco. Given that MAPI is Unity’s interface into the Exchange environment, Cisco has to do quite a bit of research, testing, and development in order to reverse engineer a way for Unity to talk to Exchange 2010. Presently, only Unity 7x supports integration with Exchange 2010 and; while support is planned for Unity 5x and 8x, no hard dates have been defined for that functionality to be released.

That’s only one side of the story though. The reality is that many customers who had already implemented Unity started asking about how to migrate to the Unity Connection platform for reasons of their own. There are some pretty common themes for why customers are considering migrating from Unity to Unity Connection.

Why Are My Customers Migrating to Unity Connection?

Organizational support issues can play a large part in the decision to migrate to Unity Connection. In many organizations, the Voice Engineers and the Microsoft Engineers are not actively engaged with each other. What this equates to is that when voice messaging issues arise, the finger pointing begins. In many cases, many Voice Engineers simply do not have the necessary Microsoft skills to fully understand Unity and the various interactions and integration points it has with Active Directory and Exchange. To be fair, the opposite is typically true as well. Many Microsoft Engineers have few voice-related skills. Unity Connection has no dependence on the corporate Microsoft environment. This reduces the complexity of the solution and gives Voice Engineers more control in maintaining the voice messaging system.

Another common theme is the “technical decisions are often made by non-technical managers blinded by cool stuff” problem. Many companies fail or just skip the requirements gathering and definition phase of projects. This leads to a situation where a small minority can’t wait for the “cool stuff”; whereas, no one has accounted for what the large majority of end users actually need, want, and/or would benefit from.

Regulatory factors also play a large role in the decision to migrate to Unity Connection as well. With Unified Messaging, everything is email because there is one message store, one Inbox, and so forth. It is not uncommon for a company to consider (or even start) a Unified Messaging deployment only to find that the legal department has a lot of questions regarding electronic records, retention policies, and how this impacts the company legally. With Integrated Messaging, Unity Connection offers a nice middle ground. There are plenty of features and “cool stuff” to impress the decision makers and there is enough flexibility to ease the concerns of the legal crowd. IMAP provides an experience similar to Unified Messaging but voicemail is voicemail and email is email because they are stored separately. In addition, Unity Connection offers the flexibility of managing many features on a user by user basis. So, if one user wants Integrated Messaging but another just wants voicemail only then this can easily be accommodated.

Another driving factor for migrating to Unity Connection is timing. Right now, many companies are refreshing older hardware platforms. It is a good time to take advantage of the Cisco migration tools that make migrating to Unity Connection fairly easy.

The COBRAS Migration Tools

Cisco has developed a set of migration tools called the Consolidated Object Backup and Restore Application Suite (COBRAS) that enable customers to perform a variety of functions. While the tools are not made exclusively for migrating from Unity to Unity Connection, they do make the process easier.

COBRAS consists of three primary migration tools that allow customers to backup all subscribers, call handlers, public distribution lists, and other system objects and import that data into another Unity or Unity Connection server(s). COBRAS allows for partial backups, restores, and even merging data from multiple backups into one system. COBRAS consists of the following three migration tools:

  1. COBRAS Export is used to selectively backup data from a Unity or Unity Connection server. Optionally, customers can even backup messages.
  2. COBRAS Data Viewer is used to open backup files (directory or message backup files). One of the key functions that Data Viewer provides is the ability to change subscriber aliases and/or extensions contained in a backup file prior to importing the data into a new system. This can be quite handy depending upon customer requirements.
  3. COBRAS Import is used to selectively import data into a Unity or Unity Connection server. One of the primary functions of COBRAS Import is to walk through the data to be imported so that any conflicts between objects in the database being restored are resolved prior to import.

The Basics of a Migration from Unity to Unity Connection

With proper planning and education on the COBRAS migration tools, getting from Unity to Unity Connection can be done efficiently and with great success. What does the migration process entail?

  1. Build and verify the health of the Unity Connection server or cluster (Publisher and Subscriber).
  2. Configure general application settings within Unity Connection such as the default application time zone, service activations, etc. In order to import data into Unity Connection, customers need to active the Database Proxy service and configure the timeout value (e.g., 999 days). In addition, customers who are migrating messages will need to configure the SMTP parameters to allow all connections and disable authentication.
  3. Configure settings that cannot be imported via COBRAS. This includes Classes of Service, User Templates, Password Policies, and Restriction Tables.
  4. Create a user account (user without a mailbox) and assign the Remote Administrator role. This user will be used to login to Unity Connection when importing data.
  5. Configure DRS for Unity Connection and get a clean backup of the system. This backup can be used to fall back to if there are issues with the import.
  6. On the Unity server, install COBRAS Export and Data Viewer (optional).
  7. Export data from Unity via COBRAS Export and make a COPY of the master backup database to use for import into Unity Connection.
  8. Identify a Windows 2003 or XP machine to be the import host. Ensure that this server or PC has plenty of disk space as COBRAS does write a number of files to a temp folder in the program’s installation path. If the disk that COBRAS is installed on is running low on disk space, customers may experience issues during the import process.
  9. On the import host, install the Informix ODBC drivers (for remote connection to Unity Connection via the Database Proxy service) and COBRAS Import.
  10. Disable any local firewall and/or antivirus software as this may interfere with the import process.
  11. Import the Unity backup data into Unity Connection via COBRAS Import.
  12. Complete all necessary validation and post-migration tasks to ensure the import was a success.

Recommendations on System Administration and Maintenance

While Unity Connection may provide Active-Active fault tolerance, each server should still perform certain roles during normal operations. The Publisher should be left to handle web traffic, IMAP connections (for Integrated Messaging), and database functions. The Subscriber should be the primary call processing host. If there are no ports available on the Subscriber, then calls can rollover to the Publisher.

For Unity Connection clusters, configure DRS for both servers. In your SFTP server configuration, create a separate folder for each server and write backups for each server to its dedicated folder. If messages fail to backup on the Publisher but succeed on the Subscriber, there is no need for panic. It is perfectly okay to backup everything but messages on the Publisher and then backup everything on the Subscriber.

Whenever possible, use G.711 as the audio codec. While Unity Connection supports wideband CODECS such as G.722 and Internet Low Bandwidth Codec (iLBC), port capacity is reduced by 50% when these CODECS are used.

A general rule of thumb for port allocation is to reserve 25% of the available ports to perform message notification, send MWI requests, and provide Telephone Record and Playback (TRAP) connections. On a 144 port server, this equates to 108 ports configured to strictly answer calls. The remaining 36 ports would be used as noted above (the “Answer Calls” parameter should be disabled on these ports).

Since the mail store is independent of Exchange, administrators have more control over mailbox size allocation. By default, Unity Connection is set to automatically purge deleted messages. This typically leads to a scenario where users keep everything and stop deleting messages. Whenever possible, disable this setting within the Class of Service message options by deselecting the “Delete Messages Without Saving to Deleted Items Folder” option.

When setting Mailbox Quotas, remember that the values for the warning, send, and send/receive quotas must be different. Use these quotas in conjunction with Message Aging Policies and the addition of the Deleted Items folder access to encourage users to manage their mailbox.

The Road to Success

Unity Connection is proving to be a stable, feature-rich, and viable voice messaging option for customers of all sizes. As with all projects, the road to successfully migrating to Unity Connection is paved by defining requirements, proper planning, and becoming knowledgeable on both the application and the various tools available to customers.