Office 365 is finally out of beta and ready for primetime! The question we think is one of the more important ones is this:
How do we, as a company, move from 100% on-premises Exchange to a cross-premises (hybrid) Exchange setup with Office 365? Not necessarily “all-in” but rather through a pilot (over time) or a permanent hybrid setup without disrupting the status quo.
In this post we’ll explore the preliminary steps you need to take in order to smoothly transition Exchange services from a full on-premises deployment to a cross-premises model.
Note: Hybrid deployment requires an Office 365 Plan E – it does not work with the P (Professional) plan. See plans here.
Assess current infrastructure
Most IT organizations know fairly well what they have running in their networks at the moment. They are also painfully aware of the pain points. There might be legacy servers and services, homebrew workstations acting as servers and lost or forgotten file shares.
The assessment is not about fixing everything – it’s about realizing if you are even ready to move beyond on-premises. Assess first, fix what you can and move forward.
The Office 365 Deployment Readiness Tool is an assessment tool you can run on a Windows 7 workstation joined to your Active Directory domain. You need to run the tool once per AD forest.
During initial run, C:office365reskit –folder is were the results are saved.
The Deployment Readiness Tool tries to determine and extract the following information about your environment:
- AD structure (forests, trusts, domains, schema etc)
- Exchange setup (email domains, public folders, delegates etc)
- Networks (gateways, IP configuration)
In addition several checks for prerequisites in case you are planning a hybrid/coexistence setup with Office 365:
- Directory Synchronization (AD <> MS Online)
- Single sign-on (SSO)
- Lync Online, SharePoint Online and Exchange Online statistics
The generated report is somewhat conclusive. In our (single forest, small environment) infrastructure the following information was gathered:
- Email domains: 21 (I know, we love UPN suffixes)
- Primary email domains: 13 (what? who owns the other 12?)
- Total number of users: 115 (a lot of service accounts)
- Total number of groups: 71 (and we love groups!)
- Estimated objects for AD synchronization: 187
- No AD trusts
- Forest schema level: Windows Server 2008 R2
- Exchange schema level: Exchange Server 2010 SP1
- Domain functionality: Windows Server 2003
- Forest functionality: Windows Server 2003
- Domain Controller functionality: Windows Server 2008 R2
The verdict based on these findings is good: Our domain and infrastructure is prepared for Exchange Rich Coexistence. Still a bit miffed about that domain functionality level though.
A lot of additional checks are also captured in the report. Here’s a few:
- Estimate of computer operating systems ready for Office 365: 8
- Current SIP domains: 1
- Exchange servers: 1
In a nutshell this means we can deploy a hybrid environment, where we employ whatever services from Exchange Online (via Office 365) while we still retain our existing Exchange 2010. Why keep both? Several reasons spring to mind:
- We can test upcoming service packs faster than Office 365 would probably roll them out
- We still ‘own’ the mailboxes, even if we decide to move away Office 365 in the future
- We can control and manage Outlook Web Access, if needed
- We can decide how mail is routed – for example, by enforcing our custom rules for any outgoing email, even for mailboxes residing in the cloud
Design your model
Armed with this information you can now design your future Exchange deployment model with the Exchange Server Deployment Assistant:
You can choose between three models:
- On-Premises only
- Coexistence (On-Prem + Cloud)
- Cloud only
I’ll skip #1 (On-Premises only), since that’s what majority of companies already have.
When you choose #2 (Coexistence), you can now design your model:
- Current Exchange version: 2003, 2007 or 2010
- For illustrative purposes I’ll select Exchange 2010
- Next, several options to choose from:
- Do you want the ability to use on-premises credentials everywhere?
- Do you want a shared email address base (company.com for everyone, both on-prem and cloud)?
- Do you want to route email from the cloud through your on-premises Exchange?
- Do you want to share free/busy and calendars between on-prem and cloud?
- Do you want to use a single URL for all email needs (OWA and Outlook Anywhere)?
If you answer yes to all, you’ll get a list of action points to complete:
In essence, this scenario and deployment model requires your organization to set up the following:
- Active Directory Federation Services 2.0 (ADFS) for identity federation
- Active Directory Federation Services 2.0 Proxy (ADFS Proxy) for added security
- Directory Synchronization (DirSync) for synchronizing AD user accounts to the cloud
- Connect current Exchange 2010 management tools to Office 365
- Additional items such as:
- Outlook Web Access configuration
- DNS changes
- Mail flow
Also, verify that your current infrastructure can meet the prerequisites:
- 1 or more ADFS servers
- 1 or more ADFS proxy servers
- 1 DirSync server (has to be 32-bit for now)
- Exchange Coexistence requirements
For piloting purposes you can virtualize most, if not all of these services.
You are now ready to start building your pilot implementation for a rich coexistence scenario. More on that in part 2.
This article on the Exchange Team blog introduces the PST Capture tool, that was designed to help you get rid of PST files. It’s an interesting read, since apparently lots of people are still using PST files for archiving and sorting email. It’s 2012 – ditch the PST!
