LC.tv IT Skunk Works #1 – Cisco CUCM + Exchange 2010 UM – Part 3

Wow, has it really been 2 months?  I guess it has.  For this Skunk Works project, we're attempting to fully integrate Cisco CUCM with Exchange 2010 Unified Messaging.

In Part 1 we did the Cisco SIP Trunk creation & the Exchange 2010 UM Role Installation

In Part 2 we actually configured the Exchange 2010 UM Role & Setup a user (me)

In this part, we'll jump on a weird error, and make some changes on the Cisco CUCM side now.  These changes are a little convoluted – jumping back and forth between call routing sections – but bear with us.  It comes out well in the end.

First, An Update
Let's start first with an update.  Cisco now supports Unity 7.x and Exchange 2010.  This is in the form of an Engineering Special – Called ES35 – and you can read more here.  This is good for us, because, for this Exchange UM to leave skunk Works, and turn into a live project, we would have needed this so an easy transition / use-both-systems-and-flip-the-switch-overnight type of thing.  Which it is.  So yay.

Second, An Error
So, as we went through last time, I've migrated a user – me – over to Exchange 2010 voicemail.  It's working and has been working just fine.  A small complication has been the fact that we have two (2x) Exchange 2010 boxes – using DAG – and sometimes we've noticed a couple errors in the Event Logs related to UM.

Screen shot 2010-04-30 at 4.12.10 PM

and

Screen shot 2010-04-30 at 4.12.24 PM

These are odd because I know I had things setup right – but it turns out, I really didn't.  If you recall in Parts 1 & Parts 2, I set Cisco CUCM up with a SIP Trunk and a profile that did all the awesomeness using a single Exchange 2010 box.  Since I have two, the "second" box really wasn't talking to Cisco.  If we were in producton, and our "first" exchange 2010 box failed, this means that exchange 2010 unified messaging would have been a failure.  That's why this is skunk works – working out the details 🙂

Let's fix the problem.

Add Another SIP Trunk
We don't need to change anything on Exchange.  All this is Cisco CallManager stuff.  Head over to your CUCM admin page -> Device -> Trunk and add a 2nd trunk for the 2nd exchange box.  We did this in Part 1 – so – I won't bore you again.  EXACT details as before minus one change – instead of using IP 43 we use IP 53 – the IP of our 2nd exchange 2010 box.

Route Pattern Check
Now that we have two SIP trunks for two exchange 2010 boxes, let's change at how the voicemail traffic is routed.  CUCM -> Call Routing -> Route/Hunt -> Route Pattern -> 9999 (our voicemail pattern from Part 1)

Screen shot 2010-02-28 at 9.49.25 PM

Notice that it's only routing to one Gateway – the Exchange 2010 Trunk (exchange box #1).  We cannot adjust that to use two trunks.  But, we can use a Route List.  Let's Pause here and do that.

Route Group Creation
In Order to have a Route List, you must have a Route Group.  I know, this gets confusing.  Let's go make a Route Group first.

Head over to CUCM -> Call Routing -> Route/Hunt -> Route Group and start a new RG

Screen shot 2010-04-30 at 3.23.25 PM

Our RG is called "Exchange2010-RG" and we'll add the Exchange2010-second Trunk in there. Since our Route Pattern is currently "using" Exchange2010, we need to create the Route Group (and Route List) using the 2nd Exchange Trunk for now – and then later go clean all that up.

Save. Route Group Done. Now, let's add the new Route Group to a newly created Route List

Route List Creation
Head over to CUCM -> Call Routing -> Route/Hunt -> Route List and create a new Route List

Screen shot 2010-04-30 at 4.41.30 PM 

Okay – see that?  We've now created a Route List – Exchange_RouteList – which contains the Route Group that we just created.  It's all a bunch of nested objects and can get confusing.

Great.  We've got a Route List – containing a Route Group – containing the 2nd Exchange 2010 SIP trunk.  Let's head back to the Route Pattern (scroll up a few pictures).

Route Pattern Change
We paused – now let's un-pause.

Back to CUCM -> Call Routing -> Route/Hunt -> Route Pattern

We need to change the Route Pattern for 9999.  Instead of pointing to Exchange2010 (the 1st Exchange 2010 Trunk) we want to point this to the Route List we created.

Screen shot 2010-04-30 at 3.26.04 PM

See that?  We just changed the drop-down to point to "Exchange_RouteList" instead of "Exchange2010" which was a single trunk.  Click Save.

Route Group Change
I know, I know – we've done this a lot already.  Let's go back and adjust our Exchange2010-RG Route Group.  Now that we've adjusted the Route Pattern to use a "list" – we can now add the 1st Trunk into the Route Group membership.

This is CUCM -> Call Routing -> Route/Hunt -> Route Group

Screen shot 2010-04-30 at 4.46.50 PM

See that?  Both Trunks are now in this route group.  We're set to use "Top Down" as the destination pattern – which means – use the 1st Trunk and if it fails, use the 2nd trunk. Save.

Did you follow that?  This was convoluted and crazy because when I first started this project, I only pointed Cisco CUCM to a "single" exchange 2010 box rather than "both" of my exchange 2010 boxes holding the UM role.  If I would have set it up using route groups / route lists the first time, we wouldn't have gotten this error.  However, we also wouldn't have this blog post – so – I guess that's good 🙂

Anyway, that's all for now.  Cisco CUCM is handling out calls and passing voicemail properly now to our Exchange 2010 cluster – both boxes – and not pushing errors.  Let's see what's next…

7 thoughts on “LC.tv IT Skunk Works #1 – Cisco CUCM + Exchange 2010 UM – Part 3

  1. When we tested this against another device (e.g. 3rd party fax server) we witnessed that the failover between selected trunks did not occur automatically. It seemed at the time of testing that the fact that one of the trunks was down was not communicated back to CM so the failover did not occur. We did find that manually re-ordering the trunks in the Route Group could achieve the effect (i.e. first device listed was the only one used). Have you also seen this behavior, or does your RG behave correctly?

    My environment is CM 7.1.3.32900-4 with Exchange 2010 SP1 RU3v3 and 2007 SP1 RU5 (migration in progress).

  2. Hey Keith–

    I noticed that failover worked properly on my end. I wonder if this is environmental – particular to your situation?

    I’ve tried this setup in a few different CUCM->(other) integrations, and have always had the RG order behave as expected.

    –DW

  3. Hi Daryl – Great articles by the way. Have a ? for you. We currently are running CCUM 6.1 and a Exchange UM server (standalone) not in a cluster with our other Exchange Servers. Everything seems to be working great. Every once in a while a user will hit the messages button on phone and the number will ring and go right into Exchange voice mail.Other times, a user may do the same sequence but it will just ring. The user may hang up and then try again, same results. One more time, they may get into voice mail. Any suggestions? Thanks for your thoughts!

  4. Hi Chris, probably the best thing to do is to turn on Diagnostic Logging on Exchange UM to make sure the call makes it to Exchange. Does this happen to some, one, or all users? When you created your route pattern for the voicemail pilot, you have it going to a single trunk right? Not a route list or route group?

    –DW

  5. Hi Daryl,

    Thanks for the good posts.

    We are also planning to move from unity to exchange 2010. As unity had 48 voicemail ports, do we create these in CUCM as well or only Hunt pilot in cucm and point it to sip trunk and then create hunt pilot and voice mail ports in exchange 2010.

    The little confusion i am having is around how it works?? if someone dials voicemail pilot it goes to CUCM and which is routed directly to SIP Trunk instead of any hunting in CUCM and then hunts throough the voice mail ports in excahnge? Is that rite? Which step involves crreating these voice mail ports in excahnge? Forgive me if i missed anything from your posts.

    Thanks,
    GR

  6. Garry–

    That’s a great question. I’m a little rusty, so take this with a grain of salt. I have not created any “voicemail ports” in Exchange. All I have done (and I’ve done this several times) is great your CUCM trunk, pilot, route pattern and point it to Exchange.

    The SIP Trunk can handle multiple “paths” or “ports” so to speak.

    Your second paragraph is right… you dial the pilot, it goes to CUCM, which is routed directly to SIP Trunk (at which point CUCM hangs up and Exchange takes over) and then Exchange handles the call from that point.

    –DW

  7. Thank you for the article. I just implemented Exchange UM using two servers in different sites. This article was helpful in setting up redundancy between the servers and CUCM.

    One thing that I ran into is that on failover it appears the second link is not available. What I discovered is, due to default SIP timers in CUCM, it will take a long time for the second SIP trunk to be used. To the user it looks like nothing is happening.

    The fix is to change the timers as described in a Cisco doc at the link below. With your guide and the timer change, it all works perfectly.

    http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a008082d76a.shtml

Comments are closed.