Daryl Hunter - Church IT Guy

Exchange 2010 - Offline Address Book (OAB) Issue Resolved

Hello! It seems like I keep saying this, but, we're ALMOST ready (thiiiiiiiiis close) to fully deploy (en masse) Exchange 2010 at LifeChurch.tv - but we keep running into little issues.

The latest issue to hit us has been a problem with getting Offline Address Books (OAB) to download on our Outlook clients.  We honestly hadn't noticed this until it was reported about a week ago.

Initial Config
Our initial config has been documented fairly well on this blog. In order to do our OAB config, I utilized two methods.  First of all, I used this script to setup all the virtual directories and help use a single SSL cert for all my exchange goodness.  Then, I followed this blog in order to handle all the various http / url redirections.  We thought everything was fine...

Symptoms
So, one of our executive assistants opened a helpdesk ticket asking us why some recently hired people were not appearing in her Exchange address book.  That's odd.  Why is that?  We started testing, and when directly connected to exchange (non-cached mode) - everything is fine.  When using OWA to checking via the web, everything is fine.  As soon as we do cached mode the new people don't exist.  Sounds like an OAB problem.

This picture confirms it:

 

Yup - There's the 0x80040113 Error...

The Fix
This week, a few of us worked on this and didn't have a solution. We found a TON of possibilities, but none that worked.  So I started asking around, and doing some deeper googling, etc.  I asked my friend @cgreentx and he asked some great questions. He asked if I had done URL redirection (yes) and how I did it (that blog post above) and he told me I did it wrong.  HA!  Actually, what he said was that he had seen the problem before and pointed me to the solution...

Here is the fix - a script to handle URL redirection & also fix the OAB issue

Yes, that worked.  This picture shows that the OAB was downloaded successfully:

Leftover Oddity
What's that you say?  There's still a problem?  Yup, still is.  That silly [80004005-501-4B9-560] error is still there.  It turns out, as best as we can tell (thanks @mburleson) that this is a known bug (and confirmed on a link from here) to be addressed in Exchange 2010 Service Pack 1 coming out later this year.

Anyway, that's that.  Hope it helps someone.

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.

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...

Exchange 2010 - Updating when using DAG

It's been a little nutso in the LifeChurch.tv IT world recently.  We've been a little stuck on some projects like Cisco Unity 7 / Exchange 2010 Integration (Engineering Special required) - which has been delaying our full Exchange 2010 rollout.  That's been annoying for sure.  We've also been neck deep in Ruckus Wireless migration at our Central / Edmond & OKC Campuses.

We're breaking inertia this week.  It's slow, but it's breaking and we're starting to move forward.

Last night, after several days/weeks of working with Cisco TAC, @mburleson made a giant breakthru on the Unity / Exchange stuff.  We decided to go ahead and fully update Exchange 2010 using Update Rollup 3 while we were at it.  To complicate things, we're running DAG - Database Availability Groups - so we had to update in the right order.  Here's some of the process.

First of all - we've got two boxes to update - so grab the update on both servers.

I found a great blog resource on updating Exchange 2010 when using DAG. Go read that. Really.

In our situation, we'll get started on the server Exchange01. Drop to the Exchange Management Shell (EMS) and run the following shell command:

Get-MailboxDatabaseCopyStatus –Server (hostname) | Suspend-MailboxDatabaseCopy –ActivationOnly –Confirm:$false

This basically tells Exchange01 to NOT activate any databases if our 2nd DAG node goes down.  This doesn't stop hosting the databases.  That's next.  Let's activate all the databases to Exchange02.  Drop back to the EMS and run the following shell command:

Move-ActiveMailboxDatabase -Server (hostame) -ActivateOnServer Exchange02

or

Move-ActiveMailboxDatabase -Server (hostname)

The first command tells Exchange01 (hostname) to move all active databases to Exchange02.  The second command let's Exchange figure out which server on which to activate the databases. You can either be explicit or trust exchange to find the right DAG server.

Great - do that.  When it's done you can verify all the databases are mounted on a DAG server OTHER than the one you'd updating.  Install the rollup.

That's the one.  Click Next.

Accept the EULA.  Click Next.

Yes - I'm sure. Click Yes. And the installation starts.

Hooray!  Painless, but this seems "fast" for a rollup.

Ah - there it is.  That's why it's so fast.  Something got jacked along the way.  Our Update Rollup 3 ended prematurely.  What in the world does THAT mean?  Click Finish and let's go put out google-fu into practice by googling the error text.  Whatcha know, top link points to this blog that explains the issue as being a UAC problem.  I didn't turn off UAC of course, and I didn't run the update using elevated privileges so it barfed.  Crap.  So, we can fix using two steps.

1) Uninstall the update - because unlike the text in the error - it DID do something, just not what you expected.

2) Re-install using "Run As Administrator" - I did this from and Elevated Command prompt.

Let's uninstall.  Head over to the Control Panel, Programs, Programs & Features, Installed Updates and get rid of Exchange 2010 Update Rollup 3.

Go away.

Now, let's restart using an elevated command prompt.

That's better.  That's what I expected.  It takes a while to install a rollup because it compiles the binaries, etc.  Wait about 15 minutes.

Much better.  Click Finish.

Now, you're done with Exchange01.  Let's run another Exchange Management Shell command:

Get-MailboxDatabaseCopyStatus –Server (hostname) | Resume-MailboxDatabaseCopy

This one allows the box to receive/activate databases again.  You're done.

Now, do the same thing with Exchange02 - the second box on our DAG.

We're all done.  Hooray!  That was painless, huh?