If this is a new install, stop now and start over. Ubuntu 16.04 is quite old and should not be being deployed. Zimbra's main install option is CentOS 7 which is current. Those directions are not good, use the actual Zimbra directions, Zimbra installation the correct and current way is plenty easy. There are guides on this site, too.
If you add SA to the original licenses - because you know the plan is the keep using Exchange going forward - it will raise the costs noticeably in the beginning, but come renewal time it will make it significantly less. Less enough to be under O365? not likely, hell, even the 5 year plan would be more expensive for onprem vs O365... but it might lower itself over time because of the SA difference.
SA is a scam to get more money. Always has been for the SMB. With negotiated pricing for Enterprise, it is the right thing.
If you're a company that only upgrades once every 10 years - then yeah... SA is a waste of money, but you're already talking about upgrading again in 5 years, so SA could very much make financial sense - show me the numbers before you poo poo it.
What is it causing on your Zimbra? mine are unaffected.
For me, everything is working smooth, the only thing I worry about is restart notice messages that are written to zimbra.log every minute.
Jul 2 00:47:20 mail zmconfigd: Fetching All configs
Jul 2 00:47:20 mail zmconfigd: All configs fetched in 0.07 seconds
Jul 2 00:47:26 mail zmconfigd: Watchdog: service antivirus status is OK.
Jul 2 00:47:26 mail zmconfigd: All rewrite threads completed in 0.00 sec
Jul 2 00:47:26 mail zmconfigd: All restarts completed in 0.00 sec
Jul 2 00:48:26 mail zmconfigd: Fetching All configs
Jul 2 00:48:26 mail zmconfigd: All configs fetched in 0.10 seconds
Jul 2 00:48:33 mail zmconfigd: Watchdog: service antivirus status is OK.
Jul 2 00:48:33 mail zmconfigd: All rewrite threads completed in 0.00 sec
Jul 2 00:48:33 mail zmconfigd: All restarts completed in 0.00 sec
Perhaps, such a behavior is OK (zmconfigd fetches configs,checks them for not being changed and assumes no restarts needed for services)?
I think so. Nothing in there suggests a restart happened.
I came across that article and it's the most promising. Though it's still a iptables based fail2ban configuration. I'm not sure if it's as simple as changing the references to iptables or if tweaking it to work with firewalld is more involved.
I suppose an option is to disable firewalld and install iptables. I've done that before in the past.
That's probably what they did, because you need to disable firewalld to enable iptables.
Since acquiring and renewing a certificate can be automated with Certbot, would it make sense to have the cert in two places? HTTP/HTTPS traffic passes through your ngingX VM, which receives its certificate through its own instance of Certbot. And you have a second instance of certbot that functions on the Zimbra server itself, so you have a cert for IMAP and SMTP connections.
Or, for you, does it not matter that IMAP and SMTP connections are unencrypted? Since beyond your own mail server, there's no guarantee that encrypted connections will exist.
You could, but it would still be such a pain to automate as certbot can't renew the certs alone for Zimbra, that you might as well just use one.