Daryl Hunter – Hubby, Daddy, Mentor, Friend

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.

and

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)

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

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

 

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.

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

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…