06-08-2007 11:12 AM - edited 03-18-2019 07:26 PM
We did a DIRT restore to move the voice mail users over to a new domain/unity box. Unity is running ok, but the only error we are getting is this;
Event Type: Warning
Event Source: CiscoUnity_ConvSubscriber
Event Category: Log Doh Access
Event ID: 187
Date: 6/8/2007
Time: 9:58:42 AM
User: N/A
Computer: GCR-UM1
Description:
While running the subscriber conversation for user:(John Moore - VM) with extension:(1019) an error occurred when trying to match the message sender (AVP_SENDER_OBJECT_ID) to a subscriber in the Unity database. The following error was returned:(HR [IAvDohMessage::get_Sender]).
The subscriber conversation treated the message as if it was from an unknown subscriber. As a result the subscriber's recorded name, if available, was not played back and reply options were not available.
Please run DBWalker from Cisco Unity Tools Depot with the option 'Check for orphaned entries in the GlobalSubscriber table' to check for database inconsistencies.
This happens when a subscribers plays a voice mail from another subscriber. We did run DBWALKER and no errors are given.
TIA
06-08-2007 02:07 PM
Is it happenning with all subscibers or just this one. Have John Moore rerecord his voice name and test to see if you get the error in the event log. I bet you don't.
rlp
06-10-2007 12:44 PM
Hello,
This seems to be a Permissions issue, Try to do the following:
- Run the DBWalker, select the right fix/check options and correct the errors.
- Run the PW and make sure that you are selecting all the User containers where you have subscribers and all the mailbox stores that contain Unity subscribers.
- Open a CLI and execute this command "\CommServer\ConfigurationSetup\Setup /sync"
- Then try to do a Bulk logout and a Bulk Sync with the Bulk Logout tool.
Please let us know how it goes!!!
06-26-2007 08:37 AM
Any luck with this solution??
We have the same issue in our enviroment and although it is not causing loss of services it is irritating to see these events everyday..
06-28-2007 06:47 PM
Im having the same issue, along with some others, any luck with this?
06-28-2007 06:55 PM
Hello,
Just try the following:
- Run dbWalker as suggested.
- Run a sync of the message store:
\Commserver\ConfigurationSetup\setup.exe -sync
- Run the latest Permissions Wizard available at ciscounitytools.com (you must execute the PW with an account that has Domain Admins rights).
- Run a Total Resync of GC:
- run \Commserver\Tech Tools\DoPropTest
- press OK and Ignore for the password
- press the "GC Monitor" button and perform a TotalResync.
The start and finish events of the sync will be reported in the Application Log.
Let us know how it goes!
08-24-2007 08:19 AM
I'm seeing this same problem. I don't think the problem is with John Moore, I think the problem is with the person placing the call. In our situation, what I've tracked down so far from the CallManager CDR logs is that the person calling is from a 4-digit extension on the callmanager, and that extension does not have a voicemail mailbox on Unity.
It almost seems that Unity recognized that the calling number was 4 digits, and assumed that it should have a mailbox on Unity, which in our case it doesn't.
Can anyone shed any light on Unity's expected behavior in this scenario and confirm why Unity thought this should have been a subscriber?
08-24-2007 09:02 AM
In the orignal post there is two places were subscriber information is stored. SQL database and AD. I am assuming this is offbox message store so there must be some inconsistancies in the AD and Unity. Since a DIRT was performed which would restore the SQL database. Also from Unity I would look at the AD and see if message store ...etc match with what is in the subscriber profile.I assuming that John Moore can retreive their voicemails? Since unity does know if a phone originated the call to voicemail or a call was forwarded to voicemail based upon CFB/CFNA.
08-24-2007 09:17 AM
Make the Unity_
Stop/Start Unity and test again, if the problem persists, just delete the Unity_
Please remember that the calls from unidentified callers are handled differently than the calls from known callers(subscribers).
02-14-2008 08:06 AM
I see alot of "try this" answers but nobody has said if the suggested solutions actually work.
Seeing the commonality of this issue why has Cisco not posted a definitive answer somewhere on the site.
Our organization gets 20 -30 of these error messages a day.. If the errors are related to unidentified callers, why would the error message be generated at all?
So has anybody had any success with eliminating these errors?
04-21-2008 05:22 AM
Did you restore messages and select the option to re-map subscriber aliases during the restore? I'm experiencing the same message and I suspect it could be because the original sender's alias on a saved message has changed due to the re-mapping.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide