I'll spare the detail until later, but we upgraded from 14 to 15 and after we uninstalled 14 and rebooted, the IP on the NIC changed. Installed 15 and had a ton of issues try to get SM to start. We got it back up by changing ipHostnameMap and IPBindingInfo in mailconfig.xml to the new IP address and then the bindings in IIS to the new IP. IIS didn't catch the IP changes and site bindings were continuing to use the old IP's. We updated those items and managed to get SM to start up and get back to normal again. 

 

So my question is when an internal IP on a NIC changes like this, is there any other spots in SM that it needs to get updated manually to make it happy? Mail flow is fine and everything appears to be working correctly but I wanted to double check.

 

More back story:

We run two MX servers in two Azure data centers, one the secondary gateway for the primary. Our main MX server was getting full and we needed to increase the drive size. In Azure, you can only do that with the machine in a specific state called "stopped deallocated". Shutting down the VM inside the guest gets you stopped, but you also have to deallocate it to release the disk in order to resize it, which also releases its IP info. We have a reserved public IP on it so that wasn't an issue, but Azure uses carrier grade NAT internally so the actual NIC on the machine got a different IP, hence the hoops we jumped through above. We chose to do the disk resize and 14 to 15 upgrade in the same maintenance window so after the upgrade (and after the IP was changed), SM wouldn't run. Hacking around in the config at least got the SM service to behave properly so we could get back into it.