Unity 5.x MWI different than 4.x MWI ??

[kdamisch]

Customer had Unity 4.0(5). When listening to messages, the MWI would go off as soon as they started listening to the message. We just upgraded them to Unity 5.0(1). Now, the MWI light stays on even after listening to the message and doesn't go off until you either choose Save or Delete.

We've checked this on a few Unity 5.x installations and this seems to have changed on those as well. Is there a way to change this either globally or per subscriber on Unity 5.x?

Thanks,

Kevin

[ranpierce]

This has nothing to do with the version of Unity. I have 4.2.1 and sometimes the lights are late. It all depends on when exchange notifies Unity that there are changes in the inbox. Then Unity will send the code to CCM.

Do you have subscribers with large inboxes?

Do you have subscribers with large mailcounts?

When Unity is delayed because of indexing a large mailbox, even someone with a small one will be delayed at the sametime.

Just things to think about.

rlp

[egrinkin1]

Randy,

Sometime our MWI is delayed and I also get:

"The Unity Message Repository detected that the Partner Mail Server is ready for message delivery. Messages held in the temporary store will now be delivered."

But our exchange guys says there's no errors on exchange so the delay must be from Unity.

Unity 5.0/CUCM 6.1/Exchange

We do have users with VERY large inboxes.

Any ideas how to prove where the delay is happening?

Thank you,

Liz

[ranpierce]

There are traces that I have to find. I will try to find it.

Randy

[egrinkin1]

Thank you very much Randy. I'd appreciate it.

~ Liz

[ranpierce]

I found this from a while ago from TAC.

For the delay user, you should expect "SEARCH_REBUILD" in the traces. Again, this is due to a high message count in the inbox.

Traces I set

a. MWI macro trace

b. Malex 10, Alcommon 10

c. ExchangeMonitor 10-13

d. NodeMgr 10-18

e. Messagestoremonitor 1, 10-13 (I think this is Malex and not messagestoremonitor as there is not one in the micro traces.) Not sure.

Gathered traces.

AvCsMgr

AvMsgStoreMontitor

AvNotifier

This was a while ago SR605395209.

If I can help in anyway let me know. We have just learned to deal with the delays cause the subscribers are not willing to reduse there inboxes.

Randy

[egrinkin1]

Thank you so much Randy. I'll keep you posted.

~ Liz

[Ginger Dillon · Accepted solution]

Hi Kevin -

I just checked the 5.0 Unity release notes and it does indicate the MWI behavior changed from prior versions - http://www.cisco.com/en/US/docs/voice_ip_comm/unity/5x/release/notes/501curelnotes.html

Check out the section titled "Message Notifications and Message Waiting Indicators". If you read further below, there is an Advanced Setting tool you can configure, "If you prefer the behavior in earlier versions, you can use the Advanced Settings Tool to adjust a setting that controls this behavior. The setting is called Conversation-Delay Mark As Read." I am still running 4.2, but may consider this setting as well.

Ginger

[kdamisch]

Ginger,

Ah yes, the release notes. :)

I used the Advanced settings tool to change this:

Conversation - Delay Mark As Read

When enabled (default), a message will be marked as read only after a user has completely finished with the message and moved onto the next one without saving it as new.

When disabled (old behavior prior to this feature), a message would be marked as read as soon as the user begins to start listening to it.

0 - Mark message read when beginning to play (old behavior)

1 - Mark message read when the user is finished with it. (Default)

Sure enough, it was set to 1, so I set it to 0, and it works the same as in 4.x, which is what the customer wanted.

Thanks,

Kevin

[ranpierce]

Ginger, in the AST it states that this setting only works for 5.x+ systems. I just set it in my lab. Thought you might want to know.

rlp