Exchange High Availability and Site Resilience

Exchange High Availability and Site Resilience

I have a Multi-Tenant Exchange organisation with customers added using Control Panel software

The site consists of two Exchange 2013 servers and all servers are physical machines.  I was unable to create a DAG as when the OS’s were installed server A was installed with 2012 standard and Server B was installed with 2012R2 standard.  When we add new customers using the Control Panel everything is fine and mailboxes get created on one or other of the two Exchange servers which I have read in various articles is usual practice unless otherwise configured not to.

This situation is not satisfactory as I cannot create I cannot create a DAG for high availability which was the original intention.
Therefore, I have created two more Exchange 2016 servers in the organisation with Server 2012R2 Standard OS on each one – so server C and server D now have Exchange 2016 and I have created a DAG with Servers C and D as members and added DBC01 and DBD01 databases to the DAG.

My aim is to move all mailboxes from server A and B databases to server C (DBC01) so they are replicated to database DBD01 on server D and then to de-commission server’s A and B from the organisation.

So for now I have four exchange servers each with externally facing AD and different URL’s for example... - - -

I have migrated a few mailboxes already to server C and Outlook clients have detected the change in the server name to connect to but it has not been entirely without problems, some users say that email doesn’t leave the outbox unless they restart Outlook and not all new emails are showing as quickly as they should.  I have also noticed that some Outlook clients are connection to server D instead of server C where the migrated mailboxes reside.

My question is this.  Have I not done something I should have for example created a Namespace rather than have individual server URL’s something like Office 365 which uses 

All servers have a send connector configured to send to a smart host relay server and all receive connectors are configured out of the box I am led to believe.

When server’s A and B are gone we will be introducing another two exchange servers on our second site for site resilience. So I am thinking of an Unbound namespace.

Can someone tell me how my Exchange server external URL’s should be configured and how to do it should they all be the same on each server with a common namespace?

Late note:  I have just had this feedback from a customer I have migrated to server C Exchange 2016 - "Emails stored in ‘Outbox’ but not sent.  I have to close Outlook and reopen it to clear the problem"
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

Simon Butler (Sembee)Connect With a Mentor ConsultantCommented:
If you are going to have site resilience, how are you going to direct the traffic to the site that is up? DNS cannot do it.
You will need to look at introducing a load balancer, possibly in a third party location (I have three in Azure for example). The external traffic will all point to that location, then be directed to the appropriate place depending on load and site availability.

As for a single namespace - at this point - it isn't something I would do. During a coexistence/build phase I will always have version specific URLs. That makes troubleshooting easier and allows me to manipulate URLs on the client (host files for example) to ensure it is going where I want it to.

As for your specific issues, ensure that you are on the latest version of Exchange 2016 - CU3 was released this week, but I would be on CU2 if possible.
Emails sitting in the Sent Items have nothing to do with the Receive or Send Connectors. Those are for SMTP traffic. Outlook to Exchange isn't using SMTP. Something is probably blocking the traffic. If you have AV on the servers, ensure that it has the correct exclusions. If you have a firewall, make sure it is setup appropriately for Outlook Anywhere (both RPC over HTTPS and MAPI over HTTPS). I have seen firewalls get hung up over the extended HTTP session those protocols use.
jonluvvieAuthor Commented:
Hello Simon - Thanks for the reply.

Maybe I'm looking too far ahead with the site resilience (not considered load balancers yet) so for the moment I'll just concentrate on the single site high availability with the DAG.

What is concerning to me is that I know for sure that a users mailbox is definitely on server C where I moved it to and yet an Outlook client is connecting itself to server D or server B and I'm not sure why this would be.

At what point would you consider a single namespace?

I did install Exchange 2016 CU2 on the two new Exchange servers
Simon Butler (Sembee)Connect With a Mentor ConsultantCommented:
The location of the mailbox has nothing to do with the server the client connects to.
Exchange will use all servers with the client access role in an AD site. If you look at the client configuration in Outlook you will see that the mailbox doesn't have a server address, it has a unique end point.

Get away from the thinking of a mailbox belonging to a server - that doesn't exist any longer.

If you have multiple sites then you cannot use a single name space. It would be a name space per AD site. However if you have multiple servers then you really need to look at deploying a load balancer.
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

jonluvvieAuthor Commented:
Hello Simon - Thanks for the reply

Can you comment on this from the Exchange Server Pro website.  "The recommended practice is to change the URLs configured on your Exchange 2016 servers to aliases or generic host names such as “” after you first install the server.
Todd NelsonConnect With a Mentor Systems EngineerCommented:
When you install Exchange by default the external URLs are not set, and the internal URLs are set with the server name (i.e. https://server.domain.local/...).

What Paul Cunningham is saying it that it is important that the external and internal URLs are set almost right after the install completes.  They should be set to something with a "routeable" FQDN (i.e.  However, keep in mind that the FQDN will (may) vary based on organization and based on how many AD sites there may be and whether the unbound or bound namespace model is used.

What Paul is also implying, is that the SSL certificate be configured and installed (or imported) to the new server soon after installation to prevent security pop-ups with the Outlook clients.
jonluvvieAuthor Commented:
Currently all four Exchange servers (two Exchange 2013 and two Exchange 2016) have the same internal and external FQDN's and all four names are in the SSL as well as an additional name and all four servers have the SSL installed.

server1 -
server2 -
server3 -
server4 -

Does this need changing?

There is one Active Directory site

Mailboxes from server 1 and 2 will be moved to servers 3 and 4 which are in a DAG and Exchange 2016 and servers 1 and 2 will be decommissioned.
jonluvvieAuthor Commented:
Can anyone give me a definitive answer to my last posting please
Simon Butler (Sembee)Connect With a Mentor ConsultantCommented:
Having read your post, it isn't clear what you have configured within Exchange.
You can only have one URL configured in Exchange for each of internal and external. Therefore the fact that they have their own FQDN matters not if they are all configured the same. It wouldn't be used.

Therefore if you have each server with its own FQDN configured, then the question of whether they  NEED changing would be answered with I wouldn't say so. If you added your generic name to the SSL certificate, then had that name go to all four servers (or a load balancer) then it would be pot luck which server the user hit. However once they hit a server Exchange would correct the URL to the one defined on the virtual directory.
Not something I have done myself.

If they have the same URL across all servers, then you probably don't have to change anything, but you don't have control over which server the user connects to. A load balancer would be my recommendation there.
All Courses

From novice to tech pro — start learning today.