Is there any way to not have a message waiting light go on for public distribution list messages? We have a site that has over 1500 users and they do not want message lights to go on if there are group messages being sent because of the time it takes to light all the lights and the strain on the Calista integration. Other message waiting lights (on and off) appear to be delayed when they send a distribution list message.<br><br>
No, the notifier component (the guy that's monitoring everyone's inbox) doesn't make any distinction about the source of the message or how it got to your inbox. Whenever a change is made in a subscriber's inbox, the notifer filters for new messages that are tagged as voice (i.e. they have a message class of IPM.Note.Voice.Unity) and if there's at least one that's marked unread, it'll trigger the lamp to go on if it's not already on and vice versa.
It'd be very difficult in Exchange to have to open each message and determine if it was sent to a DL (since Exchange "flattens" the delivery list, this is tricky). Even if possible this would add a lot of overhead to the mailbox monitoring process since we'd actually have to open each voice mail message instead of just filtering on it's message class.
In general, I'm reluctant to be selective about which messages trigger lamps/notifications... These are the types of things that cause calls to support with complaints of "delayed messages" and "I had a voice mail, why wasn't my lamp on or why didn't I get paged" etc... Also, things get sticky since you can address voice mail messages to many recipients (i.e. multiple DLs and individual subscribers). How would we determine which destinations had their lamps lit and which didn't?
One possible compromise would be something like not turning lamps on for messages sent with low priority. We can filter for the priority flag without having to open the message itself, which will keep the overhead down. Of course you'd still have some potential confusion when folks picked up their phone to check messages and discovered they had one or more even though their lamp wasn't on. This would also require that folks sending messages to DLs remember to mark their messages as low priority. But, that said, I still think it would be a better option than going the route where all messages sent to DLs don't trigger lamps.
Jeff, Thanks for the quick reply. I see now that this has been on the forum once or twice already. The one part of your reply that seems like an option is the last paragraph where you refer to sending the message as a low priority and not lighting the light for low priorities. How would we do that? Would tech support have to log in to flag it as such? If we had a distribution list that the customer was aware was going to be a low priority dl, could we just flag that one particular dl automatically to be low priority and not light MWL's? This end-site is a college campus environment where they would know when that particular dl would be used. Any more help on this would be appreciated.
Sorry if I was unclear... these are not capabilities of the current product. These would be engineering changes if we were going to support not lighting lamps for low priority messages. It can't be done today.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...
If you have 2 ISR routers, one acting as Failover, do we need to have both the same number of SRST licenses on the 2 routers?
No. You will only need the SRST licenses on the primary router. Because this feature...