Changing the SMTP domain on a Unity Connection server really isn’t that big of a deal, but as with all things voice, no change works as initially advertised. Previously, I had never had cause to mess with the SMTP domain address, but recently one of the major cell providers quit delivering our voice mail message notifications to devices and, not surprisingly, users were none to happy about it.
My guess was that the carrier in question didn’t much like the format of the sender address, since it included a sub domain: unityconnection@myservername.mydomainname.com. I quickly decided that changing the SMTP domain on the server would easily test that theory and seemed far less painful than opening a ticket with a large service provider*. I did open a TAC case just to see if there were any caveats in making this change I might want to be aware of. That’s a whole lot of voice experience talking…err, writing. The voice paranoia runs deep for a reason.
TAC indicated that not only was this a simple change as thought, but that only one service would have to be restarted – the Connection Conversation Manager, and that wasn’t to be a big deal. Well, finding that hard to believe**, I proceeded to make said change and found that there’s a little more to the story.
First – there are *three* services that have to be restarted, and since two of them are critical services, you experience a failover if you are running in HA. The system does warn you this will happen, and for what it’s worth I did not experience a loss of service doing this. Certainly don’t blame me, though, if you do have an outage and aren’t in a maintenance period when you attempt this change.
Of course, you get to rinse and repeat on the secondary server in an HA environment. Personally, nothing about the warning prompt I got on the secondary server indicates this is not a big deal, but hey, maybe that’s just me…
That being said, once the services were restarted, and my blood pressure returned to normal, I expected to see the SMTP domain updated and a happy dance to ensue. Alas, that was not the case. After consulting with TAC, and without the least bit of surprise whatsoever, I found that a reboot was “sometimes”, infer always, required.
This did fix my problem and the delayed happy dance was epic. And thankfully not recorded for the sake of my remaining pride.
Published 1/26/2015
*Almost all levels of hell are more pleasant than opening a case with a carrier. I suspect Satan actually admires the ingenuity of carriers and any future levels of hell are modeled on their expertise and innovation in human suffering.
**There is seemingly far more proof of the existence of the Loch Ness Monster, Big Foot, and the Abominable Snowman than of something involving voice being “easy”
Unfortunately/ it seems that is par for the course. But rest assured it’ll behave completely differently in the next version 😉
I recently had to perform this change, as well, on a production 10.1 cluster, because the customer’s hosted Exchange did not like the Unity Connection domain on inbound, relayed messages. As soon as I saw the pop up, I knew that it would be an after-hours, remote support deal. I also had to reboot the cluster instead of simply restarting services. Voice: If you LOVE working after-hours.
Thanks for sharing, will keep this in mind if we run into a similar issue.
Isn’t it amazing how many times in our engineering lives that these tasks should be ‘pretty straight forward and simple’ turn out to be the longest weekend of your life?
Thanks for making it fun to read about. 🙂
What version of Unity Connections where you using and did you use the same domain as your corporate email.
9.1.2 for Unity Connection, I did use the same domain as our corporate email. Fortunate that I only have to deal with one domain…