Wednesday, April 18, 2012

Office 365 with Exchange on-premises Hybrid Deployment and Migration - A COMPLETE HOW-TO GUIDE

Well, the title says it all! You will have to excuse my lack of use of images, I'll have to get back to this post and add some later on, but at the moment you'll have to make do - I'll try to be as descriptive as I can!!

I'm assuming that you've bought some Office 365 Licenses, and also that you have an Exchange 2010 installation on-premises. I'm also assuming that you've got an Internet Domain Name set up internally (i.e., not contoso.local). Let's get started:

At this point you are faced with three options, as described in this MS article:

Hybrid routing implies the extra cost of buying FOPE (Forefront Online Protection for Exchange) licenses, so although it's the best solution out of the three it's a no-go for now. Of the other two, the one that makes more sense is a decentralized shared address space, where email flows to cloud recipients through the on-premises server and sent from cloud recipients to Internet recipients directly from the cloud. A centralized shared address space would only make sense if strict compliance was to be enforced by a security protocol like SOX or ISO.

Implementing a Decentralized Shared Address Space scenario

Setting up Domains and DNS Records 

  1. Sign in to the Microsoft Online Services Portal with your Office 365 Administrator Credentials
  2. On the Admin page, under Management, click Domains
  3. Click Add a domain
  4. Type the name of the domain you would like to add (e.g.
  5. Click Next
  6. Click Verify domain
  7. Add a TXT record on your public DNS system

Now comes the part where you choose your newly added domain's intent, i.e. what you'll use it for. For the moment let's choose just Exchange Online, for two reasons: SharePoint Online must be added in a separate process and for Lync Online you cannot use a domain that's already set up on-premises in a hybrid scenario.

On the second step of this wizard comes the truly confusing part; You'll be presented with a table with 3 types of DNS records: TXT, MX and CNAME. You can safely create the TXT one, but for the other two, if you create them you'll be effectively cancelling out the DNS records that have your on-premises system working!!! Think about it: you already have an CNAME record, or else auto-configuration wouldn't work in your on-premise system. Similarly, if you overwrite your MX record, say bye-bye to incoming mail to your on-premise Exchange system. So here's what you should do for the example domain we all love,

CNAME Alias:
Destination Host:

MX Mail domain:
TTL: 3600
Preference: 10
Mail server:

You're welcome!!

Preparing your on-premises organization for Office 365

Let's kick this off by saying that your on-premises Exchange 2010 Server(s) should all be on SP2. This means the EDGE server(s) as well.

First step will be to update your exchange schema for hybrid deployment, and mind you, the domain controller on which you update your schema must be a 64-bit machine and be included in the same AD site as your schema master.

So, open a command prompt, navigate to the directory location of your Exchange Server 2010 SP2 binaries and type setup /prepareAD

Now it's time to deploy your Federation Server Farm. I'd normally opt out of creating a server farm as most of my clients' environments use clustered Hyper-V servers so the individual VMs are safe enough, but in this instance ADFS 2.0 is an ultra-light application that you can set up on any domain-joined server. Effectively, the only pre-requisite is that these 2 servers must not utilize IIS for port 443 (HTTPS). That's all!

There's a great step-by-step article here on how to set up your ADFS server farm:

But we'll do a quick step-by-step nonetheless:

Deploying a Federation Server Farm

What you'll need:

  • Two Windows 2008 or 2008 R2 hosts joined to your domain. One will server as the primary server (the one you will install ADFS first) and the other as backup.
  • One IP address that will serve as your NLB cluster IP Address
  • One DNS A record (in your internal DNS servers) in the form:
  • One trusted third-party SSL certificate

Let's go:

  1. Install the Network Load Balancing Feature on both servers and set up an NLB cluster. Make sure you define a port rule just for HTTPS (TCP port 443)
  2. Go to the primary ADFS server (i.e. the one you will install ADFS first), go to IIS Manager and create a certificate request. Tho points to pay attention to:
    1. As a certificate common name use:
    2. As a bit length use: 2048
  3. Now use the certificate request you created to obtain an SSL certificate from a third-party provider. (hint: if you're creating a lab or you just don't care too much about security give a go... one year SSL certificate 100% free!!!)
  4. Install the certificate in the primary ADFS server's IIS manager. Also go to bindings, and select the newly-imported certificate for HTTPS
  5. Now extract the certificate with its private key (.pfx) and repeat step 4 on the secondary ADFS server's IIS
  6. Create an ADFS service account
    1. Create it as a user in Active Directory Users and Computers
    2. Make sure "User cannot change password" and "Password never expires" is selected
    3. Set the SPN of the service account as described here
  7. Install ADFS 2.0 on both servers
    1. Obtain installation package here
    2. On the Server Role page of the ADFS 2.0 setup wizard, make sure you select "Federation Server"
    3. Install the ADFS Update Rollup 1
    4. Install Microsoft Online Services Sign-in Assistant
    5. Install Microsoft Online Services Module for Windows PowerShell
  8. Configure First Federation Server in Federation Server Farm
  9. Add Secondary Federation Server to Federation Server Farm

Enabling single sign-on:

Careful! The first three steps are not included in any guide !!

  1. Start Windows PowerShell as an administrator. To do this, right-click the Windows PowerShell shortcut, and then click Run As Administrator.
  2. To configure Windows PowerShell for remoting (this will enable Remote PowerShell on the ADFS server. Skipping this step will result in an authentication error), type the following command, and then press ENTER: Enable-PSRemoting -force
  3. Open Microsoft Online Services Module for Windows PowerShell as an administrator.
  4. Type cd\ and press Enter.
  5. Type $cred=Get-Credential and press Enter.
  6. Enter your Office 365 administrator name and password and click OK.
  7. Type Connect-MsolService –Credential $cred and press Enter.
  8. Type Set-MsolAdfscontext -Computer <AD FS 2.0 primary server> and press Enter
  9. Type New-MsolFederatedDomain -DomainName and press Enter
  10. Now type Get-MsolFederationProperty -DomainName and press Enter (this should bring up a bunch of data regarding certificates and sign in URLs)
  11. Download and run the Microsoft Office 365 Deployment Readiness Tool

If the tool has found any discrepancies, you'll need to fix them before continuing.

Great! Now log on to Microsoft Online Services, and:

  1. Go to Admin
  2. Click on Management, then Users
  3. Click on "Single sign-on: set up"
  4. On step 6 "Activate Active Directory Synchronization" click on "Activate"
  5. On step 7, download the Directory Synchronization Tool.
  6. Choose a machine to install the Directory Synchronization Tool on. The constraints are:
    1. This machine must be a domain joined computer
    2. It must be a highly-trusted PC or server that only trusted administrators have physical or remote access to.
    3. It must not be a domain controller
    4. It must not be one the of the ADFS servers
  7. If you run the Directory Synchronization Tool straight away it will fail! You'll need to do this first:
    • Click Start, right-click Computer, and then click Manage.
    • Under Computer Management, expand Local Users and Groups, and then expand Groups.
    • Make sure that the MIISAdmins group exists. If the group is missing, create a group that is named MIISAdmins.
    • Add yourself to the group.
    • Log off from the computer, and then log on to establish the new group membership in the access token.
  8. Now install the Directory Synchronization Tool. After the installation has finished the Microsoft Online Services Directory Synchronization Configuration Wizard starts:
    1. You will need to type your Microsoft Online Services Admin Credentials as well as an on-premises Enterprise Admin Credentials
    2. On the Exchange hybrid deployment, check the box and click on Finish to Synchronize Directories
  9. To verify Directory Synchronization follow the instructions here
  10. To force Directory Synchronization:
    1. On the computer that is running the Directory Synchronization tool, navigate to the directory synchronization installation folder. By default, it is located here: %programfiles%\Microsoft Online Directory Sync.
    2. Double-click DirSyncConfigShell.psc1 to open a Windows PowerShell window with the cmdlets loaded.
    3. In the Windows PowerShell window, type Start-OnlineCoexistenceSync, and then press ENTER.
Configuring the ADFS Proxy

So, now that the integration with the on-premises Active Directory and Office 365 is complete, it's time to configure the ADFS Proxy. What Microsoft recommends, and you should take this recommendation seriously, is that you utilize 2 load-balanced proxy servers. For the purposes of this article we will use only one ADFS Proxy server, but all you need to do to get your load-balanced pair is essentially to configure a second ADFS Proxy and set up NLB on both as described previously in this article.

What you'll need for this part:
  • One Windows 2008 or 2008 R2 server
  • Access to modify your external DNS records
  • The certificate you used on your internal ADFS servers
  • A working DMZ Topology
  • Appropriate rules on your corporate firewall
Here we go:

  1. First of all, configure your Windows server, position it on the DMZ and make sure there is connectivity both to the Internet and your internal network
  2. Install the IIS Role with the default options, import the certificate you installed to the internal ADFS servers, and configure the bindings for port 443
  3. Add the respective Host Name and IP address of the ADFS NLB Cluster you created earlier to the ADFS Proxy server's Hosts file
  4. Create a new A record on your public DNS server with the name (exactly like the one you created on you internal DNS servers) and point it to the public IP address you will use for your ADFS Proxy
  5. Configure your firewall so that HTTPS requests on this IP will be forwarded to your ADFS Proxy
  6. Make sure you can:
  7. Now run the ADFS 2.0 setup and select Federation Server Proxy
  8. Once completed, make sure the "Start the ADFS 2.0 Federation Server Proxy Configuration Wizard when this wizard closes" check box is selected and click finish.
Once the AD FS 2.0 Federation Server Proxy Configuration Wizard starts, do the following:
  1. On the "Specify Federation Service Name" type:, i.e. the exact same name of the internal load-balanced ADFS server farm we configured earlier
  2. The "Use an HTTP proxy server when sending requests to this federation service" IS STUPID!!! Why on earth would we need yet another proxy, to proxy our proxy's requests!!!! Make sure this check box remains unselected and hit "Test Connection". If network connectivity is working you will get a "The specified Federation Service was contacted successfully" message.
  3. Hit Next, and you're prompted for the logon credentials for the internal ADFS server farm. Remember the ADFS service account you created? That's the one. You're supposed to enter the credentials in the form


    But first go to Server Manager's Main Page, click on "Configure IE ESC" and turn it off for both users and administrators. Don't, and you'll get "unable to establish a trust between the federation server proxy and the federation service" errors
  4. On "Ready to Apply Settings, click on Next and watch the magic happen!

To verify the federation server proxy is operational:
  • Open Event Viewer
  • In the details pane, double-click Applications and Services Logs, expand AD FS 2.0, then click on Admin
  • On the Event ID column, look for event ID 198

Try this one as well:
  • Log on to a computer that sits outside your corporate network (so that it will be directed to your ADFS Proxy server
  • In an Internet Explorer window, type
  • In the User ID field, type your corporate username (e.g.
  • The web page should update with the "You are now required to sign in at" message
  • Click the sign-in link and in the sign-in page and enter your domain credentials
  • If this takes you to the Microsoft Online Services Portal home screen, then you can pat yourself to the back; the ADFS system you just configured works
  • If not, re-check what we've done so far and that you haven't skipped a step. You can also check Adam Conkle's great post on this TechNet thread:

 Great, all done then?? Not quite! It's the on-premises Exchange 2010 server's turn!

  1. On your Hybrid Exchange server install Microsoft Online Services Sign-in Assistant (the one you installed on your ADFS Farm servers) AND Microsoft Online Services Module for Windows PowerShell
  2. Open the Exchange Management Console and click the Microsoft Exchange node (the top-most node in the tree)
  3. In the action pane, click Add Exchange Forest.
  4. In the friendly name type "Office 365". This name will display in the console tree.
  5. In the FQDN field just select "Exchange Online" from the drop-down list
  6. DO NOT check the "Logon with default credential" box
  7. Click OK and a credentials dialog box appears. Type the Office365 Admin account and corresponding password. For example:
  8. Watch in awe as your Office 365 organization appears on the EMC console!!

Now to create a Federation Trust:
  1. On EMC, go to Organization Configuration and on the Actions pane, click on New Federation Trust
  2. Click on New and then on finish and you're done

Last but most definitely not least, we need to create a Hybrid Configuration:
  1. Right click under Organization Configuration and choose New Hybrid Configuration
  2. Go through the 2 steps of the wizard and click on finish
    This was too easy, now comes the tricky part
  3. Right-click on the Hybrid Configuration and choose Manage. The Manage Hybrid Configuration opens
  4. On the credentials screen, type in the appropriate usernames and passwords. What I suggest you do is (since we've already synchronized Active Directory) to enable an Active Directory user that is member of the on-premises Organization Management role group, as a Global Administrator in Office 365. This way, you can use the same account for both fields
  5. Under Domains, choose your hybrid domain
  6. On the next step you will be asked to create a TXT record on your public DNS servers with a Record Value that is a lengthy string of alphanumeric characters. Check the box to confirm that the TXT record has been created
  7. Next up, choose your hybrid on-premises CAS and HUB servers
  8. Under Mail Flow Settings type the Public IP address of your on-premises Exchange server (i.e. the one on the public MX record), then type the FQDN of the HUB server you chose in the previous step
  9. Mail Flow Security is pretty much straightforward, the third-party certificate is already there, and for the Mail Flow Path choose the first option (as discussed in the beginning of this article).
  10. Click next but don't go any further just yet! If you continue you will most likely get an error and the wizard will fail with something like:

Execution of the Get-FederationInformation cmdlet had thrown an exception. Federation information could not be received from the external organization.


Exception has been thrown by the target of an invocation

What on earth is wrong? Well, either the MRSProxy is disabled, or WSSecurity is disabled, or the MRSProxy is unreachable from the Internet.

Regardless of where exactly the fault lies, do all of the following:

  • On your Hybrid Server's Exchange PowerShell, enter this command:
    Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication $true
    to enable WSSecurity authentication for autodiscover on your hybrid server, and...
  • On your Hybrid Server's Exchange PowerShell, enter this command:
    Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSProxyMaxConnections 100
    The rule of thumb is that the larger number you use for the MRSProxyMaxConnections parameter, the less chances there are that a timeout will occur for large simultaneous mailbox moves.
  • Create a new publishing rule for Autodiscover in your TMG server.
    To get your hybrid scenario working, you will need to set up an additional ISA/TMG rule pointing to the hybrid server, using the proper public names (don’t forget autodiscover), bound to the OWA listener. You need to allow All Users (as opposed to Authenticated Users), set authentication to “No Authentication, but users can authenticate directly” and configure the following paths:
    • /EWS/mrsproxy.svc/WSSecurity
    • /EWS/Exchange.asmx/WSSecurity
    • /Autodiscover/Autodiscover.svc
    • /Autodiscover/Autodiscover.svc/WSSecurity

After configuring the rule, you need to put it above all the other Exchange rules, making it the first matching rule when federation traffic hits ISA/TMG.

Now you're ready to go through with the wizard and bask in the glory of your success!!!

We're almost done. What have we done so far?

  • We've configured our SSO domain with Office 365
  • set up public DNS records
  • installed an internal ADFS server farm
  • enabled Single Sign-On
  • configured Active Directory Synchronization
  • installed our ADFS proxy on the DMZ
  • verified the ADFS bit is all interoperable
  • configured our on-premises Exchange 2010 hybrid server for Office 365

Only thing left to do is to move our mailbox(es) up to the cloud!

  1. On the EMC console, go to the on-premises node --> Recipient Configuration --> Mailbox
  2. Right-click the mailbox you want to move and choose New Remote Move Request
  3. On the Connection Configurations windows, under "FQDN of the Microsoft Exchange Mailbox Replication service proxy" type the Internet FQDN of your hybrid server. Definitely consider typing in a domain admin credentials for this test.
  4. Under Move Settings, for the Target Delivery Domain browse for ""
  5. If you followed this article to the letter, the move should go without a hitch.
You can follow the progress of the mailbox move from Recipient Configuration, Move Request in the EMC console (the Office 365 federated forest you added earlier)

For good measure, test moving that mailbox back to the on-premises server: 
  1. On the EMC console, go to the Office 365 node --> Recipient Configuration --> Mailbox
  2. Observe that the mailbox you just moved appears with a green arrow. This means that a move request exists for this mailbox (albeit a completed one). You will need to go to "Move Request" underneath select the move request and click on "Clear Move Request". This will enable you to move the mailbox back to the on-premises organization. 
  3. Now right-click the test mailbox and click New Remote Move Request
  4. On the Connection Configurations windows, under "FQDN of the Microsoft Exchange Mailbox Replication service proxy" type the Internet FQDN of your hybrid server. Definitely type in a domain admin credentials for this test, then consider using delegated permissions
  5. Under Move Settings, for the Target Delivery Domain browse for "". For Remote Target Database, type the on-premises database you want to move the mailbox to. Contrary to what other guides might say, just type in the database name without the server name.
  6. This should be enough to get the test mailbox moving back to your on-premises exchange organization.

Finally, it's time to test email flow. Test for all possible cases:

  • From Office 365 users to Internet (external) recipients
  • From Office 365 users to on-premises recipients
  • From on-premises users to Office 365 recipients
  • From Internet (external) email users to Office 365 recipients

One potential issue here that has emerged on several of my clients; If you are using TMG with Exchange Edge collocated on the same server then you might have an issue with your Edge Receive Connector. By default, TMG controls (i.e. blocks) all changes made on the Edge Role. So if you have E-Mail Policy Integration mode enabled on your TMG server chances are that the creation of the Receive Connector for Office 365 on your Edge Server has been blocked by TMG.

Check for EventID 31506 from Microsoft Forefront TMG Control service in the Application Log. If you see this error and the Receive Connector is then this is what you should do:
  • On the TMG Management Console, to to Troubleshooting and on the Tasks pane click on "Control E-mail configuration Integration"
  • Set the status to "Disabled" and enforce the policy.
  • Go to Forefront Online Protection for Exchange Administration center and make a note of the IP addresses listed under "IP addresses to configure on your firewall".
    • Login to with a Global Administrator account
    • Click on Outlook
    • On the upper right-hand side of the Outlook page click on Options and then "See All Options"
    • On the upper left-hand side click on the drop-down list arrow right from "Manage Myself" and under "Select What to Manage" click on "My Organization"
    • Go to Mail Control and on the right-hand side of the page, under Forefront Online Protection for Exchange click on "Configure IP safelisting, perimeter message tracing and email policies"
    • This takes you to Forefront Online Protection for Exchange for your organization. Under Information, click on Configuration.
    • Copy-paste the IP addresses and subnet ranges to a text document, then arrange them in a comma-separated way, like so:,,
  • Now open the Exchange PowerShell on the TMG/Exchange Edge server and type the following command:
    New-ReceiveConnector -Name "From Cloud" -Usage Internet -RemoteIPRanges <FOPE Outbound IP Addresses> -Bindings -FQDN -TlsDomainCapabilities
    where <FOPE Outbound IP Addresses>, copy-paste the comma-separated list from the text document

This will create the receive connector and reinstate email flow from Office 365 to your on-premises organization

Fine tuning?

Now that everything's working you might want to do some fine tuning. This article has great info regarding the Mailbox replication Service. MRS is the service responsible for moving mailboxes, importing and exporting .pst files, and restoring disabled and soft-deleted mailboxes. So, depending on how you want to plan your mailbox moves and your migration to your desired hybrid model, you may want to tamper with the MRS configuration accordingly.
That all! This is all everything you need to do to get your hybrid Office 365 working.
the ITGuy.


  1. Excellent post, I actually found it once I was done with my deployment and re checked several things.

    Have you had issues with single sign-on? such as "Your organization could not sign you in to this service"

  2. After numerous installations, no, SSO has worked without a hitch!

    Are you using an ADFS Proxy? If so, have you tried my troubleshooting steps under
    "Configuring the ADFS Proxy". It sounds like authentication issues

  3. Very interesting tutorial. But I've got a problem. I create the rule on my TMG and I check it. And I've got an error to "/EWS/mrsproxy.svc/WSSecurity" it can't be verified. But for the others paths, no problem.

  4. one question !! on the hybrid emc the tarnsport hub
    fields are grayed out with a yellow this by design or i have failed to install the hybrid correctly.

  5. If you mean for example, in Office365 --> Organization Configuration --> Hub Transport --> Transport Settings General Properties, fields like 'Maximum Receive Size' etc.

    ...then yes, it's by design. Some of the grayed-out options are configurable from the Office365 administrative portal, and others are not meant to be tampered with.

  6. thank you for your answer , one last question the only way to change maximum receive size is by using power shell commands (set-recieveconnector). i could not find any other way.from office 365 is there any other option?

  7. Hi, Tanks for the awesome article.

    When clients with mailboxes in the cloud connect via Outlook Anywhere, is the data transferred via the on premise server internet connection or directly via the Microsoft datacentre?


  8. Hey,

    Awesome post. Just loved it.

    However have few questions for which help is much appreciated.

    1. How do i make ADFS proxy requests forwarded to ADFS server? Should i do a port forwarding kind of thing for my ADFS Proxy?

    2. I have already given firewall excemptions for Exchange Online IP address ranges. However, my ADFS confign was failing at Connect-Msolservice with the message "there was no endpoint listening at" Later the only way i could complete the activity was by having direct internet connectivity for my ADFS server. What could be the possible reason? Also should i retain this direct internet connnectivity forever/is there any work around?

  9. Hello all, first of all apologies for the late replies, I've just been swamped with work over the past few months.

    So here goes:

    Regarging the 06/11/2012 Anonymous user comment:

    OA works over HTTPS directly to the Microsoft datacenter for cloud mailboxes. This is true in all routing scenarios/topologies including the Hybrid Model we're discussing here.

    What changes is the email flow which in the case of the Hybrid model, all email has to go through the on-premises server.

  10. Regarding the 21/11/2012 coment:

    1. Simple port forwarding to the 443 tcp port of the ADFS proxy IP will do. If you've followed the full ADFS topology/configuration. Ideally you shoulf use Microsoft TMG to publish the public IP address of your ADFS proxy

    2. There are a lot of suggestions that come to mind... ADFS works over HTTPS (tcp port 443). It requires its own public IP address for which, at the very least, you should have a port forwarding rule on your firewall. Direct connectivity should be avoided at all costs, I cannot overemphasise this!

    If you like you can give me your email address and look over your issue in more depth

  11. hi there. i keep getting the error upon logging into the sts site, any insight?

    There was a problem accessing the site. Try to browse to the site again.
    If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
    Reference number: 56e84ec1-a00e-459f-b3c0-65b691dd6a03

  12. Does this happen internally, or on the ADFS Proxy? Are you using an LNB cluster for the internal ADFS server? Are you able to telnet to port 443?

  13. Thanks for great post!!

    I am getting the following error on Hybrid wizard.
    >>Execution of the Get-FederationInformation cmdlet had thrown an exception. Federation information could not be received from the external organization.<<

    I dont TMG/ISA in my network, I just have fortigate firewall and port 25,443 is allowed from external network.
    My question is how can i add web publishing rule on fortigate firewall? is it require as I don't have ISA/TMG?

  14. FWIW, I just spent a lot of time & effort troubleshooting a failed ADFS install in a lab environment. Each time I tried to configure my ADFS Proxy the 'Test Connection' succeeded, but the next step failed with an error stating the FS endpoints couldn't be contacted.

    The account I was using was valid, and connectivity to the ADFS server was fine. The ADFS service was running.

    I saw in event viewer on the ADFS server that the endpoints were not being created because the ADFS service couldn't access the Private Key for the certs. Eventually I figured out I'd imported the wrong private key into the certificate store on the ADFS, so the key didn't match the cert. Just an fyi in case this helps anyone.

  15. Andreas,

    Your feedback at was the closest material that matched what I'm currently experiencing; I'm hoping your wisdom can shine on my issue.

    We had some SSL certificates renewed on our Exchange on the same day that our Exchange server had its monthly MS patches installed, so not sure what's behind this issue, but all worked ok before that night.

    I can't move mailboxes from on-premise to O365, getting error The call to '' failed.'

    I've spoken with MS support, and we redid the connectors in O365 and hybrid setup in Exchange, among other smaller tasks.

    Any wisdom around what could be behind this?

    Thanks so much.

  16. If I change my TMG listener to no authentication and the rule to All Users my activesync breaks.
    I cant use a different listener and I cant get activesync to work without basic authentication so im stuck with the hybrid wizard. Any ideas?

  17. Ahmed, it sounds like federation issues... have you change certificates on you federation server(s) as well? Have you updated your TMG listeners with the new certificates?

  18. Any updates for this?
    I am stuck With 2010 SP3 hybrid config while trying to migrate mbx from onprem to O365 (cannot contact to mrsproxy)


Total Pageviews


Search This Blog

Popular Posts