cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
460
Views
0
Helpful
8
Replies

MWI resynching subscriber mailboxes

hardtke
Level 1
Level 1

We are running Cisco Unity 4.0 Build 4.0(4) SR 1 with Call Manager 4.1 and Exchange 2003 Version: 6.5.7226.0

The biggest problem we have with Unity right now is the resynching subscriber mailboxes.

We have 729 mailboxes and anytime there is a problem, we have to wait 5 to 6 hours for the MWI resync.

My Questions are:

Can we prevent Unity from autostarting a resync on boot up?

Can we program around the native resync so we don't have to wait for every mailbox to sync before any of them work?

Thanks in advance.

Craig

8 Replies 8

gogasca
Level 10
Level 10

I would open a TAC case in order to investigate the MWI delay.

Regarding your question, under Tools Depots | Switch Integration | UTIM Under Properties there is an option for MWI to resynch at midnight, you may give it a try.

Regarding the possible root causes you may confirm that Unity and Exchange are in the same LAN.

Check this link for MWI troubleshooting:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity40/tsg/tsg404/ex/tsg0500.htm#wp1048540

HTH

We have had several discussions with our Integrator and TAC about the delay. We have been told that we just have to live with it.

At one time we did do a resync every night, we have found that we don't need to put this load on the servers unless we are having a problem.

The issue comes up when we have problem during the day, say we have to fail over to the secondary Untiy server. This causes the MWI problem and a resync then takes 5 to 6 hours.

gpulos
Level 8
Level 8

5-6 hours seems kind of slow.

i get 4000+ unity MWI resyncs in a half hour to two hours, depending on system utilization.

what type of server is your unity running on?

how many ports are used for MWI?

(perhaps you can increase this to allow for more simultaneous MWI resyncs)

also, i agree that a nightly MWI resync is a good idea. i use MWI resync every night around 2am or so.

I am interested in knowing the size of your Exchange mailboxes. We believe our problem is that out users may have tens of thousands of emails in their inboxes which is the reason for the delay.

We have all 72 port available to MWI sync. We are running on a Cisco MCS-7835H-3.0-ECS1

You may be correct if they have enormous inboxes like that - Unity is having to log into each mailbox and then perform a filter to get a message count (i.e. so it knows if notification devices such as MWI or pagers need to be triggered). In earlier versions of Unity this is done on the fly which for huge mailboxes like that can take a long time - given the nature of MAPI these are largely serialized (i.e. not happening in parallel).

In later versions of Unity we added logic to force Exchange to keep indexes around for the message types we're interested and have it keep them up to date regardless of if we're logged in or not - this greatly speeds up this process of logging in and also reduces message count delays when calling in to check messages - I'm betting you guys also hear some delay for folks when they call in to check messages?

There's nothing that's going to make the delays when you have to restart go away but I'm betting you can reduce the total resync time with a later version.

Do you know what version the indexes were implemented?

We do not experience delays when users call in to check messages, which always seem interesting to me.

Below is the response from my integrator about upgrading Unity. Any thoughts? I want to make sure we are upgrading to the best version possible. BTW we are not running an Exchange Cluster.

This is in response to your voicemail that you left me in regards to the version of Unity that we are proposing you upgrade to versus what you were seeing out on one of the technical forums. I know that you specifically are concerned about the MWI resync delay as well as the fact that the latest version of Unity is 4.2.

My personal recommendation would be to go to 4.0(5) as intended for several reasons. Unity version 4.0 is on its 5th and final release. Based on your recent issues, interruptions, etc this would be the most stable release of Unity for you. In addition, there is an engineering special ES 32 http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_release_note09186a00805b0929.html that should address the MWI resync delay based on the documentation contained in the link above. Version 4.2(1) is the latest Unity version and we could take you to this version if you really are wanting the latest and greatest. I would be more comfortable with Unity version 4.1.1 which is a rollup with fixes of all 4.0 releases including the above engineering special. The implementation plan would be the same for either 4.0(5) or 4.1(1). So, the delay in switching the plan now should be minimal. However, we would want to make sure we revisit any caveats there may be in regards to upgrading to 4.1(1). Please, let me know your thoughts.

First, improvement were made for the static filters (i.e. filters we ask Exchange to maintain for indexes on messages in user's mailboxes) in 4.1 and 4.2 - however, if the site is not experiencing delays on login when getting message counts, this is not likely the root cause of any delays when synching MWIs. If it was taking a long time for Exchange to get back to us about the prsence of new/read/urgent messages of various types (voice mail, fax, email) then you'd also get that delay when you called in to check messages since we are forced to do the same check prior to voicing your counts.

So certainly upgrading is not a bad thing to do (lots of bug fixes and feature work done between your version and the current release) but I'm not sure you should expect a dramatic improvement in MWI sync time - there may be other issues at play since the delays you talk about are unusually high for the number of users you have.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: