I have a user that is not able to listen to one particular message. The user gets the error "Message is currently not available at this time". All other messages she can access. Has anyone ran into this?
Sounds similar to CSCtd27767 UC - New message not recognized on first subscriberlogin
I can't get to the link you posted. I know rebooting the server will fix the problem, but looking for a different work around. We are on System Version: 220.127.116.1100-2, which is higher than the version you posted.
Just to add the link to the great info from Tere (+5"T")
One thing to keep in mind is that newer versions don't always contain the "fixed" bug-fix We got bit
(no pun intended) by a bug that we assumed was fixed in a newer build which in fact had NOT been carried forward.
I would contact TAC as Tere suggested for the proper ES.
Did you find out anything from TAC? I have the same issue in a clustered environment but I am on 8.0(3) and it was supposed to have been fixed in 8.0
They are having me run some traces for them, but the problem is my user with the affected message is on vacation and wont be back until April. So before I run the traces to send to TAC I need her to try and play the message. You should open a TAC case too. I have a feeling that when she gets back from vacation she may say that she deleted the message, otherwise I will post findings here.
The user deleted the affected message, so we are unable to run any traces. If anyone finds the solution to this, please post in case this comes up again. Thanks!
I have a user with two messages in their inbox that they are unable to listen to. I was able to drill through the database and discoverd that the .wav files were really there, but I wasn't able to download the wave files from the database. (Just not sure what the command would be to complete that action .) If I can get ahold of the user I'll see what happens if they try retreving the messages vai the PCA. Also I'll try seeing if the DRS Message Fisher can help me out any too... If I get any real resolution I'll follow up.
My situation is a bit different (My CUC cluster is running 7.1.2) so my assumed fix is to upgrade to the ES.
Thanks for documenting this issue here. It helped me figure out what was happening and expedite my TAC case. For our environment, it was actually CSCtl94104. The bug below really doesn't describe the symptom, but it does describe what's going on under the hood. It's addressed by various ES's depending on which affected version you are on. Remember that there are a couple of trains of code at play here... just because it's fixed on a version of 8.0.3, it doesn't mean it's fixed in all version of 8.5.1.
As for the workaround before you install the ES, you don't need to reboot the server. Fail it over to the subscriber and fail back. It should fix it. The issue seemes to be a replication service. This has fixed it for me, until I add more users the way that I was before.
Specifically for the environment that I am working in, this occurred when I was attempting to login to the mailbox of a user who was migrated via COBRAS and then later associated to LDAP. Then subsciber tries to login for the first time. Ports are configured on UCM to hit subscriber first and then publisher.