i have a problem with all voice mail going to the example admin account. this just started in the past day or so. we have made some changes to exch in order to close an open relay. i am sure some of the changes made are causing this problem but am not sure where to start looking. i am running unity 126.96.36.199 on a win2k server with exch 5.5 sp4 on a win2k server. the following is from event viewer on unity<br>Event Type: Warning<br>Event Source: MSExchangeMTA<br>Event Category: X.400 Service <br>Event ID: 178<br>Date: 10/24/2001<br>Time: 6:55:18 PM<br>User: N/A<br>Computer: TECATE<br>Description:<br>An error occurred while transferring in message C=US;A= ;P=ABSi;L=TECATE-011024225318Z-11 because the directory name could not be expanded to an O/R address. An X.400 API Association (XAPIA) unable-to-transfer reason code and unrecognised-OR-name diagnostic code were returned. [MTA SUBMIT 15 73] (14) <br><br>any suggestions on where to start looking in order to fix this would be appreciated. thanks.<br><br>
Maybe you could expand a little on what you guys did in Exchange (and why) might help us out with some clues. Clearly the MTA is choking on sending the message off our Exchange box to the remote Exchange box(es). In the case of a subscriber to subscriber message that would result in an NDR bouncing back to them. Presumably when you say the Example administrator is getting all the messages these are outside (unidentified) callers leaving messages. When the MTA throws them back they are returned to the Unity Messaging System account which then forwards them to the Unaddressed Messages distribution list which, by default, dumps them to the Example administrator.
As to why the MTA is having trouble I got a couple of possible hits on MSDN about that specific error this one in particular deals with not having a valid X.400 address for your users:
The bigger question for me, however, is why X.400 is involved here at all typically we see generic MTA issues (as Scott was eluding to) involving DNS issues and bind back problems etc but this one is specifically the X.400 connector barking. In general X.400 should only come in to play in unusual situations for site connectors and for connecting to foreign messaging systems. Either way, Unity should not be involved in trying to send messages to subscribers outside of our site. If outside callers are leaving messages and its the X.400 connector tripping up the message delivery, that would mean that subscribers must be outside of our site (or, of course, it could mean the error message is completely misleading).
Either way, Id be curious to know what went down with the changes you made.
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...