A Review on the Cisco Meeting Server (Acano)

Welcome to the new world of multi-point conferencing

New that is, if you are Cisco Systems Inc. and recently acquired a company such as Acano just like they did in 2016.  When Cisco bought out Acano for a reported 700 million, they inherited another flagship product from the legacy of the old TANDBERG days (also acquired by Cisco Systems).  It should not be shocking that the same engineers that brought us marvels such as the Video Communications Server are behind the Acano-X series which have now been re-branded by their new owners as the Cisco Meeting Server (CMS). There’s never been a better time.


Or is there?



What I want to do is explore what the sales engineers don’t want to say.  I want to look at this product with an unbiased eye  and basically go “do I really want to buy this thing?”  In that respect let’s jump into some of the good things that make this product really stand out.


Advantage #1: 

Bravo Cisco team (or Acano) for the ability to host functions separately on their own virtual machine.

In a nutshell, the CMS product stands alone as one of the first (at least that I’m aware of) attempts at virtualizing a MCU.  Now before you go wagging fingers, I want to clarify what I mean.  Where the CMS stands alone is that it is actually virtualizing FUNCTIONS of a conferencing bridge, not just the bridge itself.  Any freshman coder can probably work out how to convert an appliance image to a vm-or-hypervisor hosted platform, but it takes real vision to separate the functions entirely, which is what the CMS essentially does.  Every function, be it recording, streaming, conferencing, lync integration, and probably walking your dog essentially can be split up into multiple “nodes” for processing.  In some cases, you are required to host a specific function alone on its own virtual machine instance.


Advantage #2

Another benefit is the ability to cluster and combine call control through use of multiple virtual machines.

What this is talking about is the product’s ability to have up to 8 processing nodes for conferencing which can be clustered across a geographical distance.  As long as you can meet the 300 millisecond requirement, there’s no need to locate these bad boys in just one data center.  Add in the functionality of what they term “call groups” and you can actually specify where a user has their conferencing by priority.  I think essentially they are copying a lot of the same lessons learned from the Unified Communications Manager product (or Call Manager for us older crowd), so you will definitely recognize some similarities.


Advantage #3

Finally is the Integration aspect.  It can act as a H323, Skype for Business (or lync) and/or WebRTC gateway.  Now I’m still trying to understand Cisco’s end state model a bit regarding the WebRTC component but I figure it’s probably just being left in there for functionality sake.  Regardless I can say that this thing does the whole Microsoft integration much easier than doing it through the Video Communication Server solution (again, just my opinion).


Now, onto the bad parts and if you’re a Cisco Sales Engineer reading this, I’m going to warn you to leave immediately.


Still here?  Ok, here it goes:


Disadvantage #1


Will someone please tell me who on this earth thought it was a good idea to make something as basic as conference control (i.e. the ability to mute/unmute/change screen layouts, etc) dependent on an active directory integration!?  I mean seriously?  There should ALWAYS be a local admin ability to jump into a box, get into a conference, and basically administer the conference.  This is the kind of horseshit that companies do from time to time to “force” a change in the industry and you know what the response generally is?  Screw you, I’m going the competitor that still gives me that abilty.

I was told a long time ago that you never take away when you update, you always add to.  In that context, Cisco needs to pull its head of its butt and give us back that function without the Directory service dependency.

Otherwise its probably going to be a good year for Polycom (or someone else).


Disadvantage #2

Again, just another example of where I would like to walk into a business unit meeting and scream at the top of my lungs: who’s the smart guy in the room who thought it was  a good idea to build yet another management product from cisco that ONLY does the CMS product?

I mean, don’t we have enough management products already between CMM, TMS, Cisco Prime Assurance, and Cisco Prime Provisioning?  Wasn’t it confusing enough that video system can be provisioned from both TMS or a Unified CM when you introduced Prime Provisioning?  Its like you’re not even looking across your portfolio and seriously looking at the long-term game.  Pick a flavor already and let’s stick with it.

At least the good news is that the Cisco Meeting Manager (CMM) is FREE (for the time being at least) with any CMS purchase.  The suck is that it will ONLY work with CMS and while your legacy TMS will at least create/destroy conferencing using CMS, it will not provide any conference control (see gripe #1).

Oh yea, CMM doesn’t support Exchange at all in the near future, so keep that TMS alive if you’re in that situation.



Disadvantage #3

Lastly my final documented gripe for CMS has mainly to do with its poor operations from an administrators point of view.  Oh sure, lets play up the user side of things and totally forget the little guy behind the scenes who has to actually make it work.

WARNING: if you don’t like command line, GET/POST methods, or a SCP/SFTP program such as WinSCP then I would avoid this product for the time being.

You literally can not do anything from the main webserverMost of the functionality is enabled/disabled/modified using the command line through a SSH session.  Additionally to actually license the thing, you will need something like WinSCP to actually put the license file in there (and the licensing is extremely chaotic right now so let’s not get into that).

Finally assuming you love that flavor of ice cream, when you start messing with X.509 certificates you’ll be working exclusively through command prompt.  At least however the CMS supports self signing so you can always get a good idea of things before using external certificates.


So ultimately its up to you whether to drink the CMS wine or not.  For me personally, I want to let it marinate a few more versions before I go all head first. Oh and Cisco, if you are listening, you can either listen to me or I’ll just find someone else who will (maybe like all the remaining TANDBERG guys who didn’t actually buy in just yet).

Cheers guys!


As always we are open to your comments and suggestions so check us out on facebook and linkedin for more continued updates and opinion pieces.


Filed Under: ArticlesOpinion


About the Author: 15+ year veteran who has dabbled in video technologies going back to 2001 starting as a bridge operator and now working as a full scale UC Engineer. Experienced in both commercial and government deployments with a fierce passion for greatness as well as a low mood for politics.

RSSComments (4)

Leave a Reply | Trackback URL

  1. vctech says:

    Great write-up. Appreciate it as I’ve been trying to size up this new beast.

    • Some VTC Guy says:

      Just trying to paint a view of the thing, it definitely has its good and bad moments. If you are running a managed conferencing environment then you’ll be better off with a conductor/virtual telepresence server combination. One conductor can host up to like, 30 TP servers.

  2. vctech says:

    To your points about disadvantage #3…I just don’t understand why they do things like this.
    Look at the Codian/TANDBERG MCU interface (4200/5300 series) -now, I realize this box is more than an MCU, but…?
    Or look at Pexip’s Infinity (may not be exactly apples to apples) but from a MCU admin perspective it’s just seems simpler: https://youtu.be/0TbKk6_hFrQ

    • Some VTC Guy says:

      I do like Pexip a lot and yes, their GUI is absolutely awesome. Where they lose me though is the proprietary nature of their configuration. Like it or not, its a standards-based world now and vendors really need to stop doing their own thing when it comes to signaling/media channels. Adhering to the RFC (i.e. SIP, H323) will drive a lot of my design planning that I do for customers because ultimately the information highway should be the same, no matter the vendor. Now features on the other hand… feel free to be as unique as you can. Those are fair game (imo).

Leave a Reply

If you want a picture to show with your comment, go get a Gravatar.

  • Contact Us




  • About the Team

    We have recently changed owners and leadership but the new team brings over 15 years of video-specific experience spanning mainly across the commercial and military sectors.  We look forward to branching out even more in ever-changing, crazy UC world.