External voicemails not working

[azam]

Hi,<br><br>I'm running unity 3.0 (build 3.0(4)on a W2k server with ccm 3.1(2c). I'm currently not getting any voicemails (or they come through hours later) when left from an external source, although messages left from other ip phones within the company are ok.<br><br>I noticed the following process - Avumrsyncsvr.exe - which is running at cpu usage of upto 99%, and the memory usage counter is increasing quite rapidly. Rebooting the server didn't help either.<br><br>I'd be grateful if anyone can shed any light as to what might be causing the sudden loss of messages.<br><br>Thanks<br><br>

[#2]

Any errors in the application event log that might be related? If I had to guess I'm thinking there is probalby a message (or more) in the UnityMTA directory that is having some problem being delivered. Check the commserver\UnityMTA\ directory and see if there's a bunch of messages stacked up in there. If so, try moving them to another folder and see if the UMR process calms down. Then you can move them back in chunks (starting with the newer ones) until you find one that doesn't go through. The files in the directory are in pairs (a routing file and a message file) so be sure to take that into account when moving them back.

These are all outside caller messages parked in here... which fits your description. Subscriber to subscriber messages are delivered from the inbox of the sender and don't go through this UMR directory.


Jeff Lindborg
Unity Technical Lead/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[azam]

Thanks Jeff,

There were indeed a large number of both .wav files and .txt files in this dir. However, the dir was totally cleared and the server was rebooted but to no avail. Looking at the cpu usage, it is spiking constantly, anywhere between 0 - 100%. There is no one process that appears to be causing the spiking, except that they all appear to be av type .exe files. It appears as if it's trying to deliver the messages, failing and trying again.

Your input is much appreciated.

Edited by azam on 5/9/02 03:48 PM.

[#4]

Is there anything in the application event log that will give us a clue here... Unity dumps anything alarming (and some stuff that's not-so-alarming) to the application event log. If the UMR service or some other guy up the food chain is choking it should be loking errors/warnings in here that'll give us a clue.

Jeff Lindborg
Unity Technical Lead/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[azam]

Here's an extract from the App log:

Type Date Time Source Category Event User Computer
Information 5/9/2002 05:03:58 AvWM_MC Stop 29001 N/A UNITY
Information 5/9/2002 05:03:58 AvUMR_MC UMR Thread Error 120 N/A UNITY
Error 5/9/2002 05:03:58 AvUMR_MC UMR Thread Error 101 N/A UNITY
Error 5/9/2002 05:03:58 AvUMR_MC UMR Thread Error 101 N/A UNITY
Information 5/9/2002 05:03:57 AvWM_MC Init 29000 N/A UNITY
Information 5/9/2002 05:03:57 AvLogMgrSvr_MC Run 10055 N/A UNITY
Information 5/9/2002 05:03:56 AvWM_MC Stop 29001 N/A UNITY
Information 5/9/2002 05:03:56 AvUMR_MC UMR Thread Error 120 N/A UNITY

[#6]

Hmmm... the UMR is definitely not happy about a return code it's getting back from the DOH when it's trying to contact the Exchange server to deliver messages and the like. The only way we'll be able to tell what's going on is to have you turn on a few traces and get us the output.

Fire up the Unity Diagnostic Tools in the Unity program group and head to the micro traces section. Turn on:

ALCommon #10
DOH #10
DALdb #10
DALex #10
MALex #10
UMR - all of them.

Then hit the "start new log files" button to cycle the logs. Let the traces go for a few minutes (make sure you span enough time to get one of those errors in the event log). Then hit the Gather Log Files option, pick a directory for it to dump to and then use the "select logs" radio button and pick all the components you added a trace to above.

Zip this info up and send it my way, we'll get the message guys to look it over. If you have a TAC case open, be sure to send me the case number as well (if you don't have a TAC case open, you should probably open one).


Jeff Lindborg
Unity Technical Lead/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#7]

Hi
I'm a colleague of Azam working on the site with the problem. The problem was a rogue message in the mta queue.

I removed this and all new messages went through ok. I also pushed through all the old messages up to the earliest one.

This was a message for recipient alias:Installer
subject :message from unknown caller.

Today we had the same problem re-occur.

TAC case :684839

Regards,

Ben

[#8]

If you have messages going to the installer, that's your problem. The Installer account only lives in SQL (we use it for various internal needs) but it does not get an account in AD/Exchange. If you somehow have messages being addressed to this guy, this would explain why Unity is having problems getting Exchange to take it... the guy doesn't exist.

You shouldn't be able to see the guy in the SA (it's not a subscriber) so if you can and if somehow a handler is setup to use this guy as a recipient, that would explain what you're seeing. I'm unsure how this would have happened other than with a manual manipulation of the database via SQL or DOHPropTest...

I'd run dbWalker on the system and see if it picks the links up, if not you'll have to go on a hunt to find the references to installer and to check into why it's being considered a full subscriber when it's not.


Jeff Lindborg
Unity Technical Lead/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#9]

hi

did you upgrade from an earlier version of unity? if so make sure that the following files have been updated from the 3.0 cdrom.

avlog32.dll
avmem32.dll
avos32.dll
avtsm.dll
avwm.dll

hope this helps.

jim
customer support
Astec Telecom

[azam]

Hi,

No we didn't upgrade. But thanks for your input.