How To Do It: Microsoft Exchange Hybrid Directory Structures

 A typical Sumatra client deploys our Microsoft Exchange migration and calendaring solutions in either on-premises or the cloud (Office 365).  This deployment is supported by a straight-forward network topology: user, room mailboxes are setup in a Single Forest.  This simple topology gets more complicated, particularly as Office 365 makes inroads in larger enterprises and higher education segments.

Some client deployments require two different Active Directory configurations.  We see this implementation when only a portion of the enterprise needs Exchange (e.g., office worker vs manufacturing, retail store, etc).  This is called creating a Dedicated Exchange Forest (see http://technet.microsoft.com/en-us/library/aa997312(EXCHG.65).aspx);  

Other client deployments host Active Directory and Exchange on two physically separate forests (e.g., parent company, acquired subdivision.) In Exchange 2007  this configuration was called an Exchange Resource Forest Topology (see: http://technet.microsoft.com/en-us/library/aa998031(EXCHG.80).aspx).    

This Exchange Resource Forest Topology has evolved in these cloud-centric times to an Exchange hybrid deployment topology (e.g., where on-premises Exchange server and Office 365 coexist in one domain (e.g., professors on-prem Exchange; Students & Alums on Office 365.)

This requires clients synchronize Active Directory between these two physically discrete servers to ensure users have a seamless single-signon experience.  Thus, when the client signs in, they are redirected to either on-premises or the cloud, depending upon their configuration.  If cloud-based users start from a company intranet, they are often required to resubmit their credentials.  This adds a small wrinkle to a calendar migration.

Follow this guide

We do not duplicate efforts when we find an excellent how-to already published.  Such is the case with Step-By-Step: Configuring a Hybrid Office 365 Deployment via Hybrid Deployment Wizard.  It’s hard to go wrong following those steps.

For those of you who need a more detailed set of instructions for earlier Exchange 2007/2010 resource forest trust environments, please contact Sumatra.

Your mantra: Validate before you Impersonate!

Your slightly longer mantra: Validate on the on-prem before you impersonate in Office 365.

In the Sumatra user interface, use your service credentials.  Hazy on service credentials?  Check out our posting The Cookbook Version of Exchange 2013 Migration Rights  and do not be afraid to use our debugging guide.

But how do I migrate on-prem Exchange to the Office 365 environment?

Easy:  For email user imapsync.  In fact we wrote a DIY guide to on-prem to Office 365 migrations.

We can handle the calendars better than anyone else, keeping meetings from an on-prem environment as meetings in Office 365, including incremental sync!  Check out our video.

Questions?  Contact Sumatra.  Or visit our site or blog.