On every Exchange server you need SSL certificates for authentication, validation and encryption purposes. For SMTP you can use the self-signed certificate. Exchange 2010 uses opportunistic TLS, so the self-signed certificate will do in this scenario. If you need to configure domain security (mutual TLS) on Exchange, you need a proper 3rd party SSL certificate for this.
SMTP communication between Office 365 and Exchange in a hybrid scenario is an example of mutual TLS or domain security. A proper 3rd party SSL certificate is needed on your Exchange server.
I was always under the impression that mutual TLS can only use the Common Name of the certificate, which in my scenario is CN=webmail.inframan.nl. After a previous blogpost there was an interesting discussion (see the comments of this particular blogpost) about this, so now it’s time to do some testing.
Originally I had a Digicert SSL certificate with Common Name CN=webmail.inframan.nl, and a Subject Alternative Name entry autodiscover.webmail.com. During the HCW I entered webmail.inframan.nl and selected the proper certificate.
It was time to renew my SSL certificate, so I added an additional SAN entry o365mail.inframan.nl.
Continue reading Exchange 2010 hybrid, SMTP, SSL Certificates and Subject Alternative Names
When configuring an Exchange 2010 hybrid environment a Receive Connector is created on the Exchange 2010 server. This Receive Connector is configured with the FQDN entered in the Hybrid Configuration Wizard (see previous blog post on Exchange 2010 Hybrid) and the source IP addresses of the Microsoft Exchange Online servers. If one of these servers access the Exchange 2010 environment, they end up on the Office 365 Receive Connector (based on the IP address) and the correct SSL certificate is returned. This way mutual TLS is established between Exchange 2010 on-premises and Exchange Online.
It sometimes happens that the wrong certificate is used for SMTP communication between Exchange on-premises and Exchange Online, thus resulting in SMTP mail flow failure between the two.
You can check this in the Exchange Admin Center (EAC) in Exchange Online. Logon to the EAC in Exchange Online, select Mail Flow and click the Connectors tab. You’ll see two connectors. One connector for mail from Exchange 2010 to Exchange Online, and one connector for mail from Exchange Online to Exchange 2010.
Continue reading Exchange 2010 Hybrid cannot establish Mutual TLS wrong certificate is used
After building a hybrid Exchange environment as outlined in a couple of previous blog posts we have an Exchange 2013/2016 environment where some Mailboxes exist on-premises and some Mailboxes exist in Exchange Online. Autodiscover is still pointing to the on-premises environment, and so are the MX records. Inbound SMTP mail flow from the Internet is still accessing the on-premises Exchange 2016 Edge Transport servers before being delivered to the intended recipients.
Figure 1. The Exchange hybrid environment with Mailboxes on-premises and in Exchange online.
Continue reading Change SMTP mail flow in hybrid scenario
In the previous articles I showed you how to implement DirSync, create an Exchange hybrid environment with a migration endpoint and how to migrate Mailboxes from Exchange on-premises to Exchange Online. Not a single word on autodiscover though, and even when autodiscover is pointing to your on-premises Exchange environment, it continues to work for Mailboxes that have been migrated to Exchange Online. This is one of the advantages of an Exchange hybrid scenario.
This is what happens: when you move a Mailbox from Exchange on-premises to Exchange Online, the Mailbox on-premises is converted to a Mail-Enabled User (Remote Mailbox) and a target address is set to Exchange Online (i.e. email@example.com).
When an Outlook client does an Autodiscover request to the Exchange environment it detects the user is a Mail-Enabled User, and that a target address is set. Based on this target address a new Autodiscover request is initiated. So, Outlook does a request for a user called firstname.lastname@example.org, Autodiscover returns a Mail-Enabled User with target address email@example.com. Next, Outlook wil try an Autodiscover request for this SMTP address.
Continue reading Autodiscover in a hybrid scenario
Before you start moving mailboxes you have to make sure that all accepted domains used by mailboxes on-premises are configured in Office 365. This can be tricky, you wouldn’t be the first admin that experience failed migration because of a domain.local email address on an on-premises Mailbox J
Now, when you want to move a mailbox from Exchange on-premises to Exchange Online, navigate again to the Exchange Admin Center, and under recipients select migration. Click the + icon and select migrate to Exchange Online to start the new migration batch wizard.
For the migration type, select Remote move migration which is supported by Exchange 2010 or later.
Click Next to continue. Select the mailboxes you want to migrate to Exchange Online, you can use the people picker feature (click the + icon under Select the users that you want to move) for this, or you can use a CSV file to select the mailboxes you want to move.
Continue reading Moving Mailboxes in a Hybrid Configuration – Part II