Cisco Unity vs. Unity Connection - Installation and Recovery Times

Billy Carter Post Unity Restore

For several years Cisco has offered two Unified Communications voice messaging products. Unity, built on Windows Server, Exchange (or Lotus Domino), and MS SQL, and Unity Connection built on Linux and Informix.

I just spent 12 hours restoring a Cisco Unity system and thought this would be a good time to discuss the installation and disaster recovery process. I will skip the configuration steps to integrate with the phone system, create voice mail users, etc.

Overview of the Cisco Unity Installation Process

---

I have been building Cisco Unified Communications Systems (or VoIP systems for the ol'timers) since 2000. Regular Unity has always been a complicated and comprehensive installation. There are many steps including things like "click options 2,3 and 5", "before proceeding to the next step, install this patch on the Exchange server", "if the Partner Exchange server is version 20XX, install Engineering Special ES9".

There is really four installations; Windows Server install, MS SQL install, messaging platform install (either full Exchange for Voice mail only, minimal Exchange components for Unified Messaging, or Domino), and finally the Unity application install.

Thankfully Cisco provides separate Cisco Unity Installation Guides or each option. I have to say, after 12 years of Unity Installations, I still always have the guide right in front of me:

1. Unity Unified Messaging Configuration with Exchange (with Failover Configured)
2. Unity Unified Messaging Configuration with Exchange (without Failover Configured)
3. Unity Voice Messaging Configuration with Exchange  (with Failover Configured)
4. Unity Voice Messaging Configuration with Exchange  (without Failover Configured)
5. Unity Unified Messaging Configuration with IBM Lotus Domino (with Failover Configured)
6. Unity Unified Messaging Configuration with IBM Lotus Domino (without Failover Configured)

All of the guides have you install the operating system, SQL, and messaging backend, then they all have to be patched. The Cisco Unity Server Updates wizard automatically installs recommend updates. Depending on the server model, this step takes 1.5 to 2 hours (Prior to the wizard, this was a manual process that often included 93 reboots and took 4 to 8 hours.)

Now that the core components are installed, but before installing the Unity software, the Active Directory scheme is extended and special AD accounts are created (unityinstall, unityadmin, unitydir, and unitymsg).

The Permissions Wizard is run to give these new accounts special permissions in Active Directory. Then you have to manually delegate Exchange Administrative control to some of the special Unity AD accounts. In my experience, 90% of the time when Unity fails to work properly after installation, it is due problems with the Unity accounts and permissions not being properly assigned.

---

Note - You can see there is extensive changes made to Active Directory, and the Unity accounts have some significant and powerful rights to Active Directory. This DOES make the AD administrators nervous (as it should). After installation, if the Unity AD accounts have some permissions removed, it will break Unity.

---

Finally the Unity software is installed and connected to the messaging environment.

Total Unity Installation Time: 8 to 16 Hours

Overview of the Cisco Unity Connection Installation Process

---

There is a single Cisco Unity Connection Installation Guide per Unity Connection version. The installation is very simple:

1. Put the installation DVD in the server and boot it up
2. Follow the installation wizard to set IP Addressing, Primary DNS, NTP, Time Zone, DHCP settings, SMTP hostname, and X.509 Certificate information. 
3. Set the application and operating system usernames and passwords
4. Identify if the server is the 1st server in the cluster.
5. To install a Unity Connection High Availability server, follow steps 1-4, but mark the systems as the 2nd server in a cluster and enter the information about the 1st system.
6. Patch the system buy uploading the single update file and click install.
7. If using Unified Messaging following the configuration steps.

Total Unity Connection Installation Time: 1 to 1.5 Hours

Overview of Cisco Unity and Unity Connection Restore Process

---

Unity uses the Disaster Recovery Tool (DiRT). DiRT allows you to back up and restore a Unity system. It is very important the exact same version of DiRT is used to backup and restore.

Cisco Unity Restore Process:

1. You should already have run a DiRT backup and stored the files off-box
2. Follow the complete installation process from above (8-16 hours). The version of Unity installed must be the EXACT SAME version that was backed up (major version and Engineering Specials)
3. Install and run DiRT restore (30 minutes to 1 hour)

Cisco Unity Connection Restore Process:

1. You should already have run the Disaster Recovery System backup
2. Follow the complete installation process from above (1 to 1.5 hours). The information entered in installation steps 2 and 3 must be the same.
3. The version of Unity Connection installed must be the EXACT SAME version that was backed up (major version and updates)
4. Sign into the Disaster Recovery System and run the Restore Wizard (~30 minutes)

Summary

---

Unity Connection has several advantages over Unity:

1. Much faster installation process, thus much shorter RTO
2. Automated installation eliminates many steps which could break the system
3. Less dependent on the Active Directory and Messaging environment
4. Almost complete feature parity with Unity (Cisco says they almost have feature parity, but I can find any features missing that I or my customers want). In fact Unity Connection has many features not available on Unity
5. Unity Connection is under active development with new features every release while Cisco has announced Unity End Of Life
6. Its just an easier system  

What do you think about Unity vs. Unity Connection?

VMware ESXi 4.1 Optimizations for Cisco UC on UCS

In my previous post I discussed the importance of installing the latest version of VMware Tools on UC virtual servers in a Cisco UC on UCS deployment. A second and equally important VMware 'tweak' is disabling Large Receive Offload (LRO) on VMware ESXi hosts.

VMware Knowledge Base Article 1027511 addresses some Linux TCP/IP stacks perform poorly when handling LRO-generated packets. This results in poor TCP performance.

1. Log into the ESXi host or its vCenter with vSphere Client.
2. Select the host > Configuration > Software:Advanced Settings.
3. Select Net and scroll down slightly more than half way.
4. Set the following parameters from 1 to 0:
1. Net.VmxnetSwLROSL
2. Net.Vmxnet3SwLRO
3. Net.Vmxnet3HwLRO
4. Net.Vmxnet2SwLRO
5. Net.Vmxnet2HwLRO
5. Reboot the ESXi host to activate these changes.

Your guest VMs should now have normal TCP networking performance.

References:
http://docwiki.cisco.com/wiki/Disable_LRO
VMware Knowledge Base - KB Article 1027511
Cisco UC on UCS - Don't Forget VMware Tools

Home

Cisco UC on UCS - Don't Forget VMware Tools

Recently we upgraded a Cisco Unified Communications system running on physical HP servers, to Cisco UCS C-Series rack mount servers. Three days after the upgrade, all of the UC applications slowed down.

When users picked up their phone handset, there was a noticeable delay before dial tone. Delayed dial tone is a classic symptom of an overworked CallManager.

The Cisco UCS C210M2 servers were more than adequate for the load. Each UCS-C210M2 hosted VMware VMs of CallManager, Unity Connection, and UCCX. All of the VMs were deployed using the Cisco prescribed OVA templates.

Cisco UCS C210M2

So what is “VMware Tools”?

According to docwiki.cisco.com/wiki/VMware_Tools:

VMware Tools are specialized drivers for virtual hardware that is installed in the UC applications when they are running virtualized.

Now I understand Drivers. Up to date drivers are a good thing. Docwiki goes on to state:

It is very important that the VMware tools version running in the UC application be in sync with the version of ESXi being used.

Anyone who has read Cisco documentation before should realize, Cisco doesn’t often use the phrase “it is very important”. This is as close as Cisco gets to saying “you have to do this”.
So we installed VMware tools on all of the VMs and the Cisco voice system has been stable ever since.

Cisco has 3 methods for installing VMware Tools on Unified Communications Application VMs dependent on the UC Application version. Visit DocWiki-VMware Tools to find the appropriate method.

Please Note: VMware Tools will have to be re-installed anytime VMware ESXi is patched or upgraded.

Home

Comcast, Skype announce partnership - Does this kill Cisco umi?

I found this article by Larry Hettick at Network World. Comcast, Skype announce partnership

Comcast and Skype announced a strategic partnership that will bring HD video calls, audio calls, and messaging to Comcast customers' television sets. The announcement was timed to coincide with the annual National Cable & Telecommunications Association's "Cable Show" held in Chicago.

Under the arrangement, Comcast subscribers will be able to connect to each other and to the global base of Skype users. Video calls from the television using Skype will be able to connect to other TVs, PCs, compatible smartphones or tablets...

The service will be delivered to the HDTV through an adapter box, and it comes with an HD video camera and microphones that sit atop the TV set, along with a specially designed remote control that combines a keyboard for texting, TV controls and audio/visual communication controls. The other calling party does not need any special equipment beyond what is needed to use Skype.

Telex Radio Dispatch System Integration with Cisco Unified Communications. Part 3

A reader has asked about our progress with this and it reminded me I haven't talked about our results.

I want to just reiterate what the Telex Radio Dispatch System is.

Telex provides an integration with multiple communications systems. This is commonly used in an environment where dispatchers communicate on multiple communications systems. The Telex C-Soft console provides dispatchers a point and click interface to interact with the various communications systems. Dispatchers can increase or decrease audio volumes from a specific radio system. They can also click on a specific radio system and, through their headset, talk on a particular radio system. The Telex Radio Dispatch System also allows for a phone system integration.

For example, consider an ambulance company. Their ambulances provide services for town A, town B, town C. All these towns communicate on specific radio channels. The ambulance company has radio towers and systems that connect to each radio channel/network. For each radio channel/network/town, Telex has a VoIP adapter that converts the radio communications to VoIP. The Telex system multicasts the audio from the radio system to the dispatchers.

For Cisco centric people, think Cisco IPICS.

We were brought in to integrate a Cisco CallManager phone system with the Telex system.

The primary problem we had was the integration between the physical phone and the Telex C-Soft Dispatch console. The physical integration is provided via in-line adapter connected to the phone (See Part 1). Often a NENA compliant phone is used. Cisco, as well as most other vendors, do not have NENA compliant phones (We later learned NENA compliant phones can cost several thousand dollars a piece). When an inbound call is presented to the dispatcher, they can answer the call by clicking on the appropriate icon on the dispatch console.

We connected a Cisco IP Phone to the Telex in-line adapter. On an inbound call, the dispatcher had to physically press the appropriate button on the phone to answer the call. This would not work, the customer wanted to use the C-Soft Dispatch Console to click and answer the call.

We tried removing a physical phone all together and use the C-Soft SIP phone. This worked ok for receiving calls. The C-Soft SIP phone was configured as a basic SIP phone in CallManager. To place outbound calls, dispatchers had to append @10.1.1.1 (CallManager's IP Address) to every outbound call, either internal or external. I held out hope the SIP client would work, but it looked to me like a freeware no frills SIP softphone. For the customer, this was a no go.

We found a small company in California which produces a box which connects to a physical phone (pretty much any phone) and provides the proper signalling to integrate with Telex (Sorry I don't have the companies name right now, but I can find it on request). With this box, dispatchers could click to answer the call, however C-Soft didn't pickup the audio.

After much troubleshooting we found the phone system needed to generate a tone or a beep when the call was answered to cause C-Soft to "hear" the call and mix the audio. After banging our heads together a co-worker suggested enabling the "call recording tone" on the dispatchers phones. This is normally used to play a tone to callers indicating the call is being recorded. We were not using a call recording system, but playing this tone caused the C-Soft console to recognize the call and mix the audio.

Telex Radio Dispatch System Integration with Cisco Unified Communications. Part 1

Telex Radio Dispatch System Integration with Cisco Unified Communications. Part 2

Home

Telex Radio Dispatch System Integration with Cisco Unified Communications. Part 2

After much research, calls to our Cisco SE, a PDI case, and a conference call with Telex we have decided...

We are going to implement Telex SIP softphones on the desktops. This will provide the best solution short of rigging up some cables connecting the Cisco IP Phone headset port and auxiliary port to the Telex ADHB-4 box. Telex stated this solution has been available for five years but has only caught on in the last year.

Running this system on SIP softphones leaves me a little unsettled, I am somewhat comforted because Telex seems to be releasing updates to their software on a regular basis. This tells me they are actively fixing problems.

The main downside to this solution is the Cisco UCCX Call Center version 8.5 doesn't support 3rd party SIP phones. I can't say that I blame the UCC Business Unit since this could require testing and certifying many 3rd party SIP phones. In this testing, of course some vendors would be left out, customers would complain, and this would pull key staff away from fixing bugs and preparing the next version.

So I will configure CallManager, excuse me, Unified Communications Manager, with 3rd party SIP devices for the Dispatchers' SIP softphones.

We have two UCMs and the softphones allow for one entry for a SIP server, either IP Address or Domain Name. I read up on creating DNS server entries for SIP servers, so I think I will try creating one DNS SIP SVR entry for two IP addresses.

An email from Cisco referred to the Cisco Interoperability and Collaboration System (IPICS). This system is basically and Cisco UC systems with some Radio over IP integration. Without any experience on this, I this this is a very good and viable option, however the customer has already purchased a solution supporting the Radio, RoIP, and operator console functions. We are just trying to integrate telephony into the system.


Stay tuned...We will see how the Telex SIP softphones cooperate with Cisco UCM 8.5 (did I mention we are doing the Cisco UC on UCS with Cisco UCS-C servers?

FYI...I am also frustrated Cisco doesn't support Cisco Unified Enterprise Attendant Console server installed on the same Cisco UCS-C Class server which also have Cisco UCS installed on them....

While Cisco supports UxAC running on VMware, it is only supported on Cisco UCS-B or UCS-C servers. These servers can not have other Cisco UC systems loaded on them (same host server)...hhmmm....Such is the question...Install CxAC on Cisco UCS servers with VMware, (which is supported) or on Cisco UCS servers without Cisco UC apps are not installed

but not on those servers have other Cisco UC applications (which is not supported), Install on VMware with other Cisco UCS servers (which is permitted) or install on

-Bill

Telex Radio Dispatch System Integration with Cisco Unified Communications. Part 1

I have Telex Radio Dispatch system I want to integrate with a Cisco phone system.

Side note: Using two Cisco UCS C-Servers with VMware. Cisco' UC on UCS. Works great!

Telex system has interfaces to the radio networks and the telephone network. 

Each user has a Telex ADHB-4.  This device mixes the audio from the different Radio networks and the telephone. Coming out of the ADHB-4 is a headset for the dispatcher. The dispatcher has a desktop application were they can select different audio sources and the ability to combine audio channels.

The interface between the phone needs audio tx and rx along with on/off hook switch and ground across 6-wires.  The box/application needs the hook switch to answer and hang up calls.

I am wondering if I can create a cable from the Phone to the Telex Device. Telex provides a basic diagram:

I would think I could get TX and RX audio and Ground from the phones headset port. I would also think I could get Hook Switch from the phones aux port (this is the port used for the wireless hook switch feature).

We will see how today goes, I am almost onsite.

I'll keep you posted.

-Bill