Office 365 – Exchange 2010 hybrid environment set up

DNS settings in an Office 365 Hybrid environment 

Some entries suggested by Office 365 do not apply in a hybrid environment. These are:

  1. cname for autodiscover to continue pointing to the on-premise server and not Office 365 as Office 365 uses it to locate the on-prem server which it continues using.
  2. New SPF records will be needed if Skype for Business is implemented
  3. SPF record pointing to Office 365 is not required. Keep it pointed to Mimecast

Unfortunately with the above, Office 365 may continue to alert that there are domain issues causing “possible service issues”. To prevent this, go to the domains section of the Office 365 Admin Center and click fix issues next to the domain reporting the problems. Then, on the right-hand side of the page, click the checkbox next to “Don’t check this domain for incorrect DNS records”. It should stop alerting for domain issues once this is set.

Also, DNS tests using Microsoft’s remote connectivity analyser and some of the Office 365 health, readiness and connectivity checks may appear to fail in a hybrid environment.

Hybrid environment and SMTP domain name space 

Each of the physical infrastructure – Online and on-prem – relates to the other by using a different domain name space, the smtp domain name space.

Public domain name 

Exchange Online relates to objects located in on-prem by using the PDN, or shared domain name, e.g. microsoft.com

Office 365 tenant built-in domain namespace 

Automatically creates two names when sign-up occurs:

onmicrosoft.com and mail.onmicrosoft.com

The organisation name gets attached, so the domain name which represents us as an Office 365 tenant is instituteforgovernment.onmicrosoft.com

This domain namespace is used only by the Office 365 and Exchange Online environment.

Hybrid domain namespace 

Exchange on-prem relates to objects in Online by using the HDN. The registered Office 365 organisation name is attached to the mail domain name & the Office 365 default domain name. For us, microsoft.onmicrosoft.com

In other words, it is used by the on-prem for routing purposes as a point of authority: mail flow and autodiscover (e.g. when a user whose mailbox is located at Exchange Online tries to get autodiscover information, he will get redirected to Exchange Online through receiving a reply which includes the HDN. An example would be mike@microsoft.mail.onmicrosoft.com)

If someone called Jonathan tries to create a new Outlook mail profile, Outlook will query the on-prem Active directory for the name of the on-prem Exchange server which provides the required autodiscover services. The on-prem Exchange will be asked for the required autodiscover information but it will not know who Mike is. the on-prem e-mail server contacts Active Directory asking for information about Mike. The answer from AD includes the fact that Jonathan’s mailbox is a remote mailbox and that he has the following routing e-mail address: jonathan@microsoft.mail.onmicrosoft.com. The autodiscover client starts a new DNS query looking for a host called microsoft.onmicrosoft.com. The name will then be resolved through the creation of an https session to the destination autodiscover endpoint, autodiscover.microsoft.onmicrosoft.com

High-level steps (assumes you use a third party scanning service such as Mimecast’s Cloud offerings)

  1. Take out the Office 365 subscription
  2. Execute the Office 365 Deployment Readiness Tool to check for any organisational issues and registering the accepted domains in Office 365 and Exchange on-prem to be used in the hybrid deployment
  3. Run the Office 365 Network Analysis Tool (EMEA: http://em1-fasttrack.cloudapp.net) to help analyse if there are any network issues before the deployment of O365 services
  4. Install the Exchange client Performance Analyser on Mike Brass’ computer which does thorough testing from client computers on the network to our O365 service
  5. Run the Exchange Server Deployment Assistant which will spit out the checklist steps to follow to undertake migration
  6. Setup and test outbound connectivity from O365 to Mimecast
  7. Setup and configure the Active Directory Connect tool for local AD accounts to be bi-directionally synchronised to O365
  8. Test autodiscover and Exchange web services using Microsoft’s Remote Connectivity Analyser
  9. Set Firewall to allow O365 ip address ranges through (http://onlinehelp.microsoft.com/Office365-enterprise/hh373144.aspx) on smtp port 25
  10. Communication between O365 and on-prem occurs over https, so set Firewall to permit this communication by placing a https rule higher than the http proxy scan rule
  11. Connect the Exchange Management Console on-prem to O365, which will also test the https settings just configured. It is also necessary for running the hybrid wizard
  12. Run the hybridisation wizard, with O365 mailboxes set to send out via O365 to Mimecast.
  13. Verify the new send and receive connectors setup automatically by the hybridisation wizard by sending test e-mails between on-prem and the test O365 mailbox
  14. Use the Remote Connectivity Analyser again to test hybrid autodiscover and core functionality
  15. Test external connectivity by sending and receiving e-mails from Outlook
  16. Test webmail to O365 and on-prem
  17. Go into the health center and disable any alerts for services like incorrect MX DNS records which Office 365 want pointed at itself but which are pointed at Mimecast
  18. Set Mimecast to route inbound messages to O365 which will then forward them to on-prem, and test
  19. Check that the Global Address Book and distribution groups are visible in O365
  20. Configure journaling for Office 365 to Mimecast
  21. Verify Office365’s default receive message limit size
  22. Move a test mailbox from on-prem to O365
  23. Test sending and receipt of e-mails on mobile devices and document steps
  24. Check that the test user can still see on-prem shared calendars and other staff can still see my calendar
  25. Setup voicemail facilities
  26. Use an Office 365 backup service such as UKBackup
  27. Proactive monitoring of the Office 365 service

Autodiscover 

Leave unchanged.

Mimecast 

To configure Mimecast to work with Office 365 and testing:

Inbound: https://community.mimecast.com/docs/DOC-1608 and https://community.mimecast.com/docs/DOC-1611

Outbound: https://community.mimecast.com/docs/DOC-1623

In a hybrid environment (journalling etc): https://community.mimecast.com/docs/DOC-2016

Other for inbound and outbound from Office 365: https://community.mimecast.com/docs/DOC-1134#jive_content_id_Europe_Region

Gateway>policies>delivery  routing . First create a new definition to point to Office 365 and then change the existing plicy to use the new definition. Delete the “<office> on-site” definition when it is working.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s