Forum Discussion
Exchange 2019 and IP-less DAG - how does failover work?
I'm also curious as we are getting a DAG setup. Currently with the IP DAG we have already run into issues when we pointed our firewall rules to the DAG instead of the main server itself. I've since been trying to get a clearer description/layout of the process of exactly what happens in ip-less and IP DAG. Deleted
Hey sbohmer
Regarding our existing IP-full dag, failover clustering is set up to change the IP of the dag01.domain.com DNS A record. We have our primary namespace (client connectivity) mail.ourdomain.com as a CNAME pointing to dag01.ourdomain.com, and dag01.ourdomain.com A record has the IP of the main server MAPI interface.
mail.ourdomain.com(CNAME) => dag01.domain.com(A) => IP of main server MAPI interface
In the event of main server death or disablement (or patching) failover clustering automatically changes the IP address of the dag01.domain.com A record to our backup server.
mail.ourdomain.com(CNAME) => dag01.domain.com(A) => IP of backup server MAPI interface
Works fine for our needs. Just not sure how an ip-less dag would work in this situation.
- Deleted We currently have all internal mail related dns pointed to the DAG IP address. We thought the issue was related to an incorrect firewall setting but it turns out our second server somehow was configured with 2 gateways. Once the second gateway was removed and corrected all works as expected. Server1 goes down server2 takes over with no issues. We still have a single point of failure as we have a single Spamtitan that all mail comes through on the way in but it would take minutes for us to restore that if something were to happen to it. In regard to patching the host that sits on it takes a minute or less to move it to another host prior to reboots.
- We have something similar! MailScanner running on Linux that does our incoming spam/virus as well as outgoing dkim. Also single point of failure but...
It would also take minutes to spin a backup of it's vm up, and it gets VRS'd to our remote site where the DR Exchange server sits.
