Hybrids: The final frontier. These are the voyages of the starship Enterprise. Whether Exchange or Lync, hybrids are the wave of the future, something everyone will have to start dealing with at one point in their career.

With Exchange Hybrids in particular, we enable coexistence between our on-prem exchange environment and Office 365’s Exchange Online, enabling features such as:

The possibility to use message archiving in the cloud for on-prem mailboxes (Which could result in a huge cost savings!)

For those who have been in the exchange field a while, these all start to look fairly familiar with cross forest exchange deployments, don’t they? OK, not all these features are available in the same form if we do this between different on-prem forests, but Microsoft had to take its inspiration from somewhere now don’t they!

In essence there are a few deployment options we can consider for our Exchange Hybrid, but just to clarify, I’m talking about a full rich coexistence hybrid here, not some cutover migration plan.

Scenario 1: Direct connection in to the on-prem environment

The simplest of scenarios in that sense that we have a direct connection in to the on-prem environment. No hassle with reverse proxies and edge servers. Just open the ports, configure the hybrid and you’re ready to rock!

Scenario 2: Direct connection in to the on prem with mail routing through O365

A variation on scenario 1 would be to have your MX traffic going through the Exchange Online environment, which would have it protected by EOP.

Scenario 3: Direct connection in to the on-prem environment with edge server

In this scenario we still have a direct connection in to our exchange environment but are utilizing the edge server to have mail traffic filtered before coming in to the on-prem environment. A direct smtp connector still exists between Exchange Online and the Exchange on-prem environment.

Scenario 4: Direct connection in to the on-prem environment with mail routing through the edge server.

A variation on scenario 3 would be to let the edge server handle the mail routing to Exchange online.

Scenario 5: Direct connection in to the on-prem environment with mail arriving in O365 and routing down to the on-prem through the edge server

Or, we could have all the mail traffic come in to Exchange Online, using the awesome powers of EOP (Exchange Online Protection in case you have been wondering) and route the on-prem mail in through the edge server(s).

Scenario 6: No direct connection

And this is where things start to get slightly complex. There are a lot of companies out there that do not like opening up their internal network to O365 directly (I’m looking at you, security teams!). Whilst I can relate to some of the concerns that are raised with that setup, let’s not forget that Exchange is secure by design, and, if you let external users access you exchange servers directly, you should not have any concerns about O365 doing the same!

But how do we solve this conundrum? After all, in order to have rich coexistence Exchange Online will need to be able to access the on-prem EWS services for things like for free/busy lookups…

Enter the reverse proxy (Microsoft Application Request routing)!

Or, the mail routing alternative:

The attentive reader will have noticed two things. One, I didn’t put EWS traffic arrows on the last two images (we will cover that configuration and flow in a future article). And two, there is no directory sync in the diagrams. Nor are any ADFS servers displayed. I’ll cover all that and more in future articles!

Imagine a scenario where you acquire a company in a different country and they don’t want to be absorb in your IT environment (because they don’t like it, have regulatory requirements that can’t be met or are just trying to be difficult) but you do need some fashion of coexistence between the two Exchange organizations… After all, you’re part of the same company now and people should be able to find them in the GAL and do free/busy look ups!

? Note: This is required to keep both GALs up to date. If this hourly (or regular) synchronizations are not performed, eventually, the GALs will no longer represent accurate information.

? Note: The code for the synchronization scripts is located in the references chapter. No warranty is given on this code by the author of this document or Microsoft and it should be reviewed, as well as tested, before being placed in production environments.

Step 1: Open task scheduler (administrative tools > Task Scheduler).

Step 2: In the Actions Pane, click on Create Basic Task….

Step 3: Enter a Name and Description.

Step 4: As Trigger, use Daily.

Step 5: Have the task recur every day and select a start time.

Step 6: Use Start a program as action.

Step 7: Enter powershell in the Program/script field and –command .\start-sync.ps1 in the add arguments field. In the start in field, enter the directory where the script is located.

Step 8: In the Finish pane, tick the box next to Open the Properties dialog for this task when I click finish and click Finish.

Step 9: In the properties of the newly created task, click on the Triggers tab.

Step 10: In the Triggers tab, click the edit button to adapt the schedule of the task.

Step 11: In the Edit Trigger window, tick the box next to Repeat task every: and select 1 hour from the drop down box. Click on the drop down box next to for a duration of and select Indefinitely. Click OK.

Step 12: Click on Task Scheduler Library, select your task, right click it and select Run to test the execution of the task. A PowerShell window will open and show the progression through each synchronization step.

Another exchange related function (who could guess!) I recently finished is this one. It will download the exchange setup file and install the role you require to be installed. You have to provide the role you want to install, the exchange version and the organization name. Works for 2010 and 2013. Might update this in the future to include RU installations.

I’m not taking full credit for this one. This script was originally made by someone else (and as soon as I find the link to that post I’ll put it up!) to prepare for Exchange 2010 on windows 2008 and 2008 R2.

I’ve updated it for server 2012 and Exchange 2013, converted it to a function and make you choose th