In my previous blogpost, I’ve discussed the prerequisites for moving from Exchange 2010 to Office 365 when using Directory Synchronization (using Azure AD Connect). In this blogpost I’ll discuss how to create an Exchange 2010 hybrid environment.
Exchange 2010 Hybrid
Now that Directory Synchronization is in place using Azure AD Connect we can focus on connecting the on-premises Exchange environment to Exchange Online, this a called an Exchange Hybrid Configuration.
Hybrid configurations can consist of Exchange 2010, Exchange 2013 or Exchange 2016 or a combination of versions, so it is possible to have an Exchange 2010 and Exchange 2013 coexistence scenario on-premises, and connect this to Exchange Online. However, when using multiple versions of Exchange in a Hybrid configuration there’s always add complexity, and when configured incorrectly you can get unexpected results. Therefore, I typically recommend using only one version, so if you’re running Exchange 2010 on-premises, there’s no need to add an Exchange 2013 or Exchange 2016 server to your configuration, just as a ‘hybrid server’. Despite what other people tell you, there’s no need to add a newer version, and Exchange 2010 Hybrid is fully supported by Microsoft. Better is to create an Exchange 2010 hybrid environment, and when the mailboxes (or most the mailboxes) are moved to Office 365 upgrade your existing Exchange 2010 environment to Exchange 2016. But that might be an interesting topic for a future blog post .
Basically, we will create the following configuration (again, there is no Exchange 2016 server installed in the existing organization):
Figure 14. Exchange 2010 hybrid configuration.
Continue reading Moving from Exchange 2010 to Office 365 Part II
There are a lot of articles on the Internet on how to create a hybrid environment, where Exchange 2016 is connected to Office 365. Now that’s fine, but when you’re running Exchange 2016 you most like are NOT going to move to Office 365 anytime soon I guess. If you are running Exchange 2010 chances are that you will move to Office 365 (soon), but there aren’t that much articles about moving from Exchange 2010 to Office 365. And a lot of the articles available don’t have the right approach I’m afraid, and will result in you (the customer) having to pay way too much money to your system integrator.
In this article, I’ll try to outline the recommended approach when moving from Exchange 2010 to Office 365 in a hybrid scenario. With Azure AD Connect for synchronization purposes. Cliffhanger: I’m not going to install Exchange 2016 into the existing Exchange 2010 environment
Existing Exchange environment
Our organization is called Inframan and they have their own on-premises Exchange 2010 environment which they have been running for 5 years now without too much issues. There are internal Outlook clients using Outlook 2010 and higher, and there are external clients using Outlook Anywhere. There are also mobile clients using ActiveSync to connect to their Mailboxes. Of course, there is Outlook Web Access, but POP3 and IMAP4 are not used.
Figure 1. Overview of the Inframan Exchange 2010 environment.
Continue reading Moving from Exchange 2010 to Office 365
Microsoft has implemented DKIM, DMARC and SPF in Exchange Online, the only thing you have to do is enable it. The only thing for DKIM you have to do is create two CNAME records in DNS and enable DKIM in the Exchange Admin Center.
DKIM CNAME records
The CNAME records you have to create for DKIM look like this:
Selector1 and selector 2 are the 2 selector tags (in Office 365 these will always be selector1 and selector2), the _domainkey is a default tag that will be added. Of course you have to replace the contoso.com with your own domain.
The CNAME records have to point to the following locations:
Continue reading DKIM in Office 365
Autodiscover can be a lengthy process, especially if you are in a hosted environment or if your mailbox is in Office 365.
The autodiscover process consists of five different steps, it depends on your environment where autodiscover stops and returns the information. Autodiscover is using the following mechanisms:
- Service Connection Point (SCP) in Active Directory. This is used by domain clients.
- Root domain discovery, used by non domain joined clients or clients not being able to access Active Directory. All other steps are used by these clients as well.
- Autodiscover.contoso.com (standard autodiscover mechanism)
- Autodiscover redirect to autodiscover site (often used by hosting companies)
- Autodiscover SRV records in DNS (sometimes used by hosting companies)
- Autodiscover redirect to Office 365 (outlook.com)
If your mailbox is in Office 365, outlook will go through all these steps until it finds the information in Office 365. All steps will fail with the accompanying time-out and this will take quite some time. This can be seen in the Outlook Test Email AutoConfiguration option:
Continue reading Improve autodiscover performance
This blogpost is more a note to self, but sigh, I hate it when it does this…. show the 412 Cookies are Disabled error message when trying to open the Exchange Admin Center (EAC) in Exchange Online:
I’m not sure if this issue shows up every time, but at least it shows up when you want to configure an Exchange Hybrid Configuration and you select Hybrid in the On-Premises EAC and select Sign In to Office 365.
To solve this, select the Tools menu in Internet Explorer, select Internet Options and click the Privacy tab.
Lower the slider just one click to Low and click Apply or OK.
Now when you refresh the page in Internet Explorer it should continue with the Hybrid Configuration page: