Showing results for 
Search instead for 
Did you mean: 

SMTP message notification, Unity 4.0(5) to Unity Connection 7.1.2

I am migrating from Unity 4.0(5) to Unity Connection 7.1.2 using Cobras.

Haven't made the cut, but when testing the import of messages using Cobras users who have  SMTP in notification devices are getting an email for every message imported, even if they are not new.  For instance I migrated my vmail messages from exchange backend to Unity connection using cobras and there were 32 saved messages - I received 32 emails from unity connection saying you have a new message.  Once the process was done they were correctly marked in Unity Connection (as already read/listened to) but this did not prevent the notification device from getting hit for every message.

Is there an easy way to disable this for just the imports?  I have over 3,000 subscribers to import messages for.

Any other ideas?  I could probably muck around with the "smart host" but afraid of causing other problems (thousands of bounces, the mail just queueing up until can be sent) etc...

Thank you.

Everyone's tags (3)
Cisco Employee

Re: SMTP message notification, Unity 4.0(5) to Unity Connection

Chatting with the notificaiton folks on this point - unfortunately there's not a lot of good options for suppressing notification events here during import - currently the MTA just processes messages from the COBRAS restore as normal inbound messages - the header has the "seen" tag and original send dates which are applied but AFTER the new message event is processed when the message gets added to the mailstore database (which generates all the counters and other update events needed down the road) - thus any active notification device will be triggered even though the message is almost immediately marked "seen" - train's left the station by that point.

Ideally the MTA would provide special header tags for "supress notification" or the like but this is obviously new feature work that's not trivial.

It'd be possible for COBRAS to forcibly disable all notification devices for a user but the timing is very tricky - you can't just disable them, toss the messages into the MTA and then enable them again since the MTA may process messages in batch (particuarly if it's busy during a large import) and when you turn the devices back on you may do it in front of the actual message insertion - leaving you in the same boat.  Plus the disable, send, wait, enable process is pretty ugly stuff in general.  To do it right you'd need to create a table of all notifcation devices and owners that had been disabled, disable them all during user import/creation, import all messages for all users, wait till the MTA reports an empty queue  and then when you're all done go back and enable all devices again - that'd give you the best chance - but that's a pretty sizable pile of work.

I can eyeball it a bit the end of the week to see if it's less hairy than I'm imagining but I'm doubting it'll be something that can be done safely in a reasonable timeframe (assuming you are looking to migrate sooner rather than later).  This is something that would take some testing cycles for sure.


Re: SMTP message notification, Unity 4.0(5) to Unity Connection

Thanks for the thorough response.  I am looking to migrate in about two weeks so likely not something you can fix for me.

What happens to the notification messages if there is no SMTP smart host configured in Unity Connection?

Are they queued up or will they just go in a black hole forever(which is what I want)?

If I deconfigure the SMTP smart host for the duration of the import will I be able to accomplish what I want?

Or will those messages just be sent once I configure the SMTP smart host back in?


Cisco Employee

Re: SMTP message notification, Unity 4.0(5) to Unity Connection

Actually, we might - chatted with my guys about it today - the import could be updated to include optional logic for disabling all notification devices during restore for new users when message restore is in play.  this is something we could tuck into an optional behavior via a command line option so we don't run afoul of the QA folks (i.e. existing tested behavior remains unchanged by default, you'd have to run it with the "/DisableNotificationDevicesDuringRestore" option or the like).

We'll take a closer look at it tomorrow but we should be able to get you something to test with by early next week - ping me directly (lindborg at cisco dot com) and we can chat about details.

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards