You can stop the resynch process by stopping the AvMsgStoreMonitorSvr service. But one you restart it and Exchange is online/available, the resynch will commence again. When you stop it in this way, you will see an application event message indicating it was stopped and how many inboxes had been completed. Make sure you have at least one Unity port per integration for performing MWI dialouts.
Yeah if the sync start again then it is anti productive to what needs to happen. I have a few ports for dialout of MWI so that is not the issue.
One problem too would be that the AVMsgStoreMonitorSvc (correct me if I am wrong) monitors the exchange environment for changes before queuing the event in with the Notifier for dialout. So new messages would not display MWI?
MWI can be frustrating for sure...any other way of monitoring the progress?
If the service was stopped for a long time, the AvNotifier service (which is dependent on the AVMsgStoreMonitorSvr service) would not send the set lamp instruction to CallManager. I mentioned stopping this service just to cancel the one that was in progress and give the ports time to clear out, not to keep the service stopped. Something else I can recommend, as I have a Unity server integrated with two CCM clusters (but no failover) is to schedule nightly MWI synch in UTIM at different times for each cluster. That may help. Also, when we perform Exchange maintenance on Sundays and Exchange is down for awhile, we've noticed we have to restart the AVMsgStoreMonitorSvr service on Monday mornings. The scheduled resynch will kick off OK, but never complete. Restarting the service has been the circumvention that works for us. A way to monitor the progress is to run Port Status Monitor for the ports configured for MWI dialout while you are synching MWI. Other forum experts may have other recommendations.
You can try opening the Data Link Explorer from the Tools Depot under Diagnostic Tools. Scroll down to the NotificationMWI table. If you sort on MWIStatePending column on the right hand side, you can see how many pending MWIs there are after a resync. 0 = it is not pending.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...