After recording the recorded voice for a mailbox, it vanishes after less than 5 minutes. I have no clue. I have the wav file saved away so I can readd it. We are using Unity 22.214.171.124.<br><br>
My first guess is this is an Exchange user that's hidden in the address book being imported as a subscriber but Unity is not configured to pick up hidden users in the directory. The subscriber information is dumped in the memory cache (which is what the SA and conversations reads from) and everything is fine for a maximum of 10 minutes and then a resync kicks in. The DOH doesn't see the user in the directory so they are removed from the cache and disappear from the SA and the conversations wont find them.
If this user is hidden in Exchange I'm betting this is your issue (if not let me know). Here's a post on the registry changes you need to make sure are set in 2.4.6 so Unity will pick up hidden users and/or hidden distribution lists:
That doesn't match your description exactly, however... if the subscriber information is there (i.e. you find them in the SA, you can get to them over the phone and hear their greeting etc...) and it's only the voice name not getting writen through to the directory itself, that's a different class of problem. The voice name is converted into text (uuencode) and stored in the "voice mail name" property in Exchange for that mail user. If for whatever reason that mail user is choking on that property, that would result in what you're seeing. However that'd be pretty unusual...
this is only happening for one person or is this everyone?
Unity Product Architect/Answer Monkey
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
I saw this once upon a time ago.
If you looked at the subscriber profile, the recording tool would show the length of the recorded name when it was still available, but once it disappeared, it would show as 0 seconds and the ability to play the name is gone, you could only record a new name.
Looking in Exchange, at the raw properties for the Subscriber, the object attribute Voice-Mail-Recorded-Name was never present.
This issue ended up being a problem with running out of MAPI threads. The customer had a bunch of MAPI errors in the Application log pointing us to this. After running the Exchange Optimizer and 'Over Optimizing' Exchange it cleared up.
Unity Technical Lead
Unified Voice Team, San Jose
My company is experiencing the same problem - we use Unity 126.96.36.199 with Exchange 5.5. A unique twist to this, however, is the fact that we do not see any MAPI errors as mentioned in the previous post. Multiple users are unable to record their name and have it remain. None of the mailboxes in question are hidden in Exchange.
We are going to run Optimizer this weekend to attempt to resolve the situation, but are concerned that it may be a different, but related issue and Optimizer won't fix it. Due to production requirements we can't run such maintenance during the week, and Management is hot on this issue so we can't afford to wait another week for a fix.
Is there anything else we can check in the interim to try and determine exactly what the problem is? Any assistance would be appreciated.
Red Capital Group
I hate to add a me too... The problem seems to disapear by deleting the user and recreating them. I don't want to have to do this for the 80 people that are complaining about it.
Are you deleting just the subscriber attributes (i.e. removing them as a subscriber and adding them back via the SA) or are you deleting the Exchange account entirely and recreating it? If it's just removing the subscriber properties via the SA I'd be supprised, haven't seen anything along those lines before.
The voice names in 2.4.6 are streamed right into the directory into the "Voice name" property on the mail user. It also gets written to the local cache on the Unity box and will hang out there for 10 minutes or so until the next resynch with the directory (which happens about every 10 minutes). If the voice name is for whatever reason not making it into the directory, it'll be removed from the local cache when it synchs. This is why it may seem like it's there and then dissapears.
It's difficult to speculate what might be causing the write through to the voice name field to fail. As keith mentioned earlier in the thread, we've seen this crop up due to MAPI threads running out since the actual streaming process uses MAPI (we used to go right in via LDAP but LDAP was not designed to take such large chunks of data at once and this caused memory leaks left and right). Usually this will cause MAPI/thread errors to pop up in the event logs which are a good clue. If you're not seeing those, I'm not sure right off hand what might be causing the issue.
You can verify the problem by recording a voice name and then looking at that user's raw properties in Exchange and check out their voice name field to see if has anything in it or not. If it does not, then the write is being denied further up stream for some reason. If so and then it goes away later this is a different problem entirely.
I hate sound stupid, but what tool are you using to look at the raw properties in Exchange 5.5?
Also, with out going thru each user, is there any type of reporting I can run in 2.4.6 to see those users with blank recorded names (or length of 0)
We have the same concern. We ran the Performance optimizer on the exchange server, where all the recipients are located. Is there any specific parameter needs to be tuned in the perf. optimiser, as there are a lot of parameters appear on the perf. optimiser when ran on the verbose mode. Also our question would be, do we need to run perf. optimizer on the Unity server also? Any help will be greatly appreciated..
You know, bingo. I have been fighting this thing for a couple of months and this is all it was?
I gotta ask, how did you run this down?
The original poster of this thread escalated to Cisco's Enterprise Communications Software Buisiness Unit (ECSBU) through TAC. We worked with them to resolve their problem. We found that because they had moved the system mailobx (Unity_ServerName) to an Exchange server that Unity was not directly connected to, that when they would make changes to their mailbox, some changes were commited to Exchange via LDAP and others made via MAPI. The LDAP changes were made to the Exchange directory that Unity was connected to (the onbox Exhcange server) and the MAPI changes were made to the Exchange server the system mailbox (Unity_ServerName) resided on. When Exchange would replicate, the changes would override each other.