Monday, November 30, 2009

CUCiMOC, caveat emptor...

For those of you out there thinking about making your user's dreams come true with CUCiMOC, have a quick think about the following before you continue:

You are going to have to deploy a client to all of your workstations. Before you decide to do this, have a quick chat to your Systems Management guys. Depending on your environment, this may not happen as quickly or as easily as you think.

Many CUCM deployments have required a second implementation of Active Directory, due to AD admins refusing to put the required schema changes in the production environment. What does this mean for you? CUCiMOC uses the currently logged on users creds to access many services, such as retrieving voice mail. This means your user name and password must be the same in both domains. No problem right, just manually sync them. This will work, but what happens after 30 days when your password expires?

Check your dial plans... CUCiMOC will just dial the numbers you give it. One problem you may come across is that in your GAL, your numbers are probably in E164 format. Without modifications to your dial plan CUCiMOC won't be able to dial these numbers forcing you to manually modify numbers everytime you make a call.

It is not free. Depending on how you are licensed with Cisco will depend on how much this is going to cost you. Better do the maths up front.

Do you really want to strip your OCS deployment down to being just a presence engine? To make life less confusing for your users, Cisco  suggests that you hide all the native functionality of Communicator, leaving only the CUCiMOC calling controls exposed. Not sure this is really what you would have intended when you started on your OCS journey.

So for Matt's 5 cents:
CUCiMOC may be a good option for people who want to start using their PC as their voice endpoint but don't want to use Microsoft's UC platform yet. If you really think this is your only/best option, I would really suggest doing a pilot production with a handful of "real" users before jumping in, as some of these issues seriously impact user experience. For those who are unsure of how Microsoft's offering will compare, why not pilot that too, you may be pleasantly surprised. 

3 comments:

  1. Hi Matt,

    Much in the same view as your other Cisco Vs MS post, Cisco are the king of marketing whether its true or not, being well versed in whats on offer is the key.I completly agree with you, run a side by side comparison to get a real feel for the end user experience when making your decision as it will be almost always come down on the side of OCS.

    ReplyDelete
  2. FUD Quote " Many CUCM deployments have required a second implementation of Active Directory, due to AD admins refusing to put the required schema changes in the production environment."

    Fact: CUCM deployments doesn't require active directory schema extension since CUCM 5.

    FUD Quote "Check your dial plans... CUCiMOC will just dial the numbers you give it. One problem you may come across is that in your GAL, your numbers are probably in E164 format. Without modifications to your dial plan CUCiMOC won't be able to dial these numbers forcing you to manually modify numbers everytime you make a call."

    It's easy to make changes to the dial plan. In fact, it's so easy, it's easier than installing OCS. It's easier to update 1 dial plan and maintain it than to maintain 2 dial plan concurrently.

    ReplyDelete
  3. Hi Anonymous thanks for your comment,

    I agree that it is not mandatory, but many organisations have chosen to put the IP Tel kit into a separate AD environment for whatever reason and I can think a quite a few.
    From what I have seen the larger the environment the more likely that this is the case.

    Secondly my point here is that Cisco are making a big deal out of the fact that you are going to have to modify your dial plan to integrate with OCS when in fact using CUCiMOC will still require you to do this anyway.

    ReplyDelete