Office 365 Hybrid Deployment / Exchange Rich Coexistence – Sharing Availability (Free/Busy)
** IMPORTANT: This blog includes old instructions for manual configuration of Exchange Hybrid. This method is no longer supported and instead you should be using the Hybrid Configuration Wizard as documented here: https://technet.microsoft.com/en-us/library/hh529921(v=exchg.150).aspx
** Updated 24-08-2011 to include enable-OrganizationCustomization step as an optional extra.
I have been working with a number of customers and consultants recently who have been keen to explain to me just how difficult they are finding the configuration of Exchange Rich Coexistence or Hybrid Deployment as its now known with Office 365, and to be fair I agree, its definitely not as simple as we would like. We do have improvements coming in Exchange Server 2010 SP2 that will simplify this process, but I thought that I would post this to attempt to help out with some basics…
During the early adopter programs and beta this was known as Exchange Rich Coexistence and it is essentially a way to share availability data between your on premises Exchange Organisation and your Office 365 tenant. This type of deployment is extremely useful both for large migrations and where organisations wish to split their users permanently into a hybrid configuration, where some users are provisioned in the Office 365 service and some remain on premises. The basic idea behind the solution is that users shouldn't need to know where their mailbox is located and instead should just be able to arrange meetings and see availability data for everyone, regardless of their location.
To keep this post relatively brief I have decided not to walk through tasks that are relatively well understood, such as installing Exchange Server 2010 and publishing EWS. Instead I have assumed that several tasks have already been completed…
Cross organisation availability sharing uses the availability service, which is built on Exchange Web Services (EWS). This means that your on premises Exchange organisation must have a published EWS endpoint with a valid public certificate attached, plus a few other things.
So.. with that in mind, this is what we really need…
- Admin access to your Office 365 tenant
- Admin access to your Exchange organisation on premises
- Ability to edit your DNS Zones
- An established Microsoft Federation Gateway Trust
- A published EWS endpoint with public certificate
- An Exchange Server 2010 deployed into your on premises Exchange organisation
In reality of course most Office 365 enterprise deployments require ADFS and Directory Synchronisation to meet design requirements, which adds to our list..
- ADFS 2.0
- Directory Synchronisation
Note: Since all of my customers are working with ADFS and Directory Sync the rest of this post assumes that you have already configured them and they are working correctly…
It is assumed that the following tasks have been completed…
- Trust has been established with the Microsoft Federation Gateway : https://technet.microsoft.com/en-us/library/dd335198.aspx
- All required SMTP domains have been verified in Office 365
- Exchange Web Services have been published on premises : https://blogs.technet.com/b/exchange/archive/2010/07/16/3410408.aspx
- ADFS 2.0 is configured and working
- Directory Synchronisation is configured and working
Before we begin it is important that we verify that a few things are working….
Microsoft Federation Gateway Trust
To test the MFG trust we need to issue the “test-federationtrust” PowerShell commandlet from our on premises Exchange Server 2010 server… it is vital that all of the test outputs show as “Success”
Exchange Web Services
To test Exchange Server 2010 EWS on premises use the Exchange Remote Connectivity Analyzer…
Complete the “Microsoft Exchange Web Services Connectivity Tests”
TIP: The EWS test requires an empty mailbox, so create a new “ewstest” mailbox and logon to it via OWA or Outlook prior to running the test to ensure that it is functioning properly… once you have logged on to the mailbox and checked that it is empty, then progress on to the RCA EWS test…
OK, so now we are ready to begin some configuration… we will follow this order to get things up and running…
- Create service domain
- Create on premises –> Office 365 organisation relationship
- Create Office 365 –> on premises organisation relationship
- Test
Create service domain
The service domain is used primarily for forwarding SMTP E-mail from on premises to the Office 365 tenant. We cannot use the *.onmicrosoft.com namespace given to all users since that name is blocked from the Office 365 DIRSYNC process. This is a problem since we need to stamp the service domain as a proxyAddress for all on premises users to ensure that when we migrate a user and set the service domain to be the targetAddress it matches the right user in the Office 365 tenant. The service domain also acts as targetAddress for availability requests for Office 365 mailbox.
TIP: To make things easier it is recommended to use a subdomain of your primary SMTP domain for the service domain. In my lab the primary smtp domain is groovycloud.co.uk, so I will use service.groovycloud.co.uk as my service domain.
Use the following blog to establish a remote PowerShell session to your Office 365 Tenant –
NOTE: This is NOT the same as connecting to your Exchange tenant PowerShell in Office 365..
Tip: This is a useful thing to remember, so save the blog URL for future administration tasks with Office 365…
Once you have established your Office 365 remote PowerShell session, lets check some settings by running…
- Get-MsolDomain –DomainName <primary SMTP domain>
We are looking primarily for the authentication type of the parent domain, in my case it is a federated domain that passes authentication requests back to an on premises ADFS 2.0 infrastructure.
Now we can create our service domain. Note that you need to replace the Authentication type to be the same as reported in the previous step.
- Add-MsolDomain –name service.<primary SMTP domain> –Authentication federated
Note: Since this is a subdomain of a previously verified domain, Office 365 will not require that you re-verify the domain.
Now we have our service domain, we need to provide it with DNS information for MX record to ensure that SMTP traffic destined for the domain is routed appropriately and an Autodiscover CNAME record to ensure that Autodiscover works correctly…
Contact your DNS Registrar and ask for the following records to be created…
- Create MX Record for your Service Domain that points to : mail.outlook.com
- Create CNAME record in your Service Domain for “autodiscover” that points to : autodiscover.outlook.com
Note: You can continue the configuration while waiting for these records to be created.
The final things we need to do with our service domain is to add it as a Remote Domain, Accepted Domain and add a proxyAddress for our on premises Exchange users.
Adding the Service Domain as an Accepted Domain…
- new-AcceptedDomain -Name 'Office 365 Service Domain' -DomainName 'service.groovycloud.co.uk' -DomainType 'InternalRelay'
Adding the Service Domain as a Remote Domain and setting it as our “BPOS” Domain (TargetDeliveryDomain $true)
- New-RemoteDomain -Name 'Office 365 Service Domain' -DomainName 'service.groovycloud.co.uk'
- Set-RemoteDomain -Identity 'Office 365 Service Domain' -TargetDeliveryDomain $true
Adding the service domain to all users proxyAddresses…
The easiest way to achieve this is to edit the E-mail Address Policy. In my case I only have a single “Default Policy”, so I will add the service domain in there…
Tip: If this is the first time you have attempted to edit your E-mail Address policy since installing Exchange Server 2010 you may need to upgrade it. If like me you only have a single policy you can upgrade with the following Exchange Server 2010 PowerShell command…
- Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients -Confirm:$false
Once upgraded, edit the policy and apply to all users.
Note: If you cannot do this, then you will need to either script the proxyAddress update or perform a manual update on each user.
Once all of these tasks are completed, either wait for your scheduled directory synchronisation to complete or force directory synchronisation by following the instructions here..
This process is performed on premises in the Exchange 2010 Management Console. However, before we continue we need to know what our Office 365 tenant POD name and EWS namespace is…
- Logon to portal.microsoftonline.com with your tenant Admin account
- Click on “Outlook” in the top menu bar
- In the far right hand side top menu, click on the drop down next to the “?”
- Select “About”
- Scroll down until you find your External SMTP Setting
- Record your POD name, in my case this is : pod51007.outlook.com
- Your EWS Namespace will be : https://<POD>/EWS/Exchange.asmx
Configuring the Org Relationship…
- Open the Exchange Server 2010 Management Console
- Expand Organization Configuration
- Open the Organization Relationships tab
- Click on New Organization Relationship
- When prompted, select to Automatically discover configuration information and enter in the *.onmicrosoft.com domain for your tenant.
Once the Org Relationship has been created we need to modify a few settings in PowerShell…
Firstly we need to see what the settings are…
- Get-OrganizationRelationship -Identity "Office 365" | fl
Enable Mailtips…
Thesesettings enables mailtips to work between Exchange Org’s
- Set-OrganizationRelationship -Identity "Office 365" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True
Check that the correct domain names are listed on the Organisation Relationship…
As general rule the following should be listed as a minimum…
- Primary SMTP Domain (groovycloud.co.uk in my example)
- Service Domain (service.groovycloud.co.uk in my example)
- Office 365 Domain (neiljohn.onmicrosoft.com in my example)
Use the following command to write the correct domain names on the Org Relationship…
- Set-OrganizationRelationship -Identity "Office 365" –DomainNames groovycloud.co.uk, service.groovycloud.co.uk, neiljohn.onmicrosoft.com
Set the TargetOwaURL to enable OWA redirection…
Note that the URL should end with your federated namespace to ensure that users are directed to the correct authentication platform. This should match the domain portion of the UPN that users use to login to Office 365 with.
- Set-OrganisationRelationship –Identity “Office 365” –TargetOwaURL https://outlook.com/owa/groovycloud.co.uk
Example of a working OnPrem Organisation Relationship…
- Primary SMTP Domain Name : groovycloud.co.uk
- Service Domain Name : service.groovycloud.co.uk
- Tenant Root Domain : neiljohn.onmicrosoft.com
- Tenant POD Name : POD51007.outlook.com
[PS] C:\Windows\system32>Get-OrganizationRelationship | fl
RunspaceId : 75c03ec6-47bb-4070-807d-ec2a09d112f1
DomainNames : {service.groovycloud.co.uk, groovycloud.co.uk, neiljohn.onmicrosoft.com}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel : LimitedDetails
FreeBusyAccessScope :
MailboxMoveEnabled : False
DeliveryReportEnabled : True
MailTipsAccessEnabled : True
MailTipsAccessLevel : All
MailTipsAccessScope :
TargetApplicationUri : outlook.com
TargetSharingEpr :
TargetOwaURL : https://outlook.com/owa/groovycloud.co.uk
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
OrganizationContact :
Enabled : True
ArchiveAccessEnabled : False
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
Name : Office 365
DistinguishedName : CN=Office 365,CN=Federation,CN=GroovyCloud,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=groovycloud,DC=local
Identity : Office 365
Guid : 3da3da88-22fa-444a-ac4e-4eaafe84d917
ObjectCategory : groovycloud.local/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship
ObjectClass : {top, msExchFedSharingRelationship}
WhenChanged : 15/08/2011 10:39:28
WhenCreated : 15/08/2011 07:23:48
WhenChangedUTC : 15/08/2011 09:39:28
WhenCreatedUTC : 15/08/2011 06:23:48
OrganizationId :
OriginatingServer : DC1.groovycloud.local
IsValid : True
Now we need to create a relationship between our Office 365 tenant and our Exchange on premises infrastructure. This process is very similar to the previous Org Relationship…
First we need to create a remote PowerShell session to our Exchange tenant in Office 365, follow the instructions in Mike’s post here to sort that out..
Once we have that session established we need to create a new Org Relationship…
- New-OrganizationRelationship -DomainNames groovycloud.co.uk -Name "Exchange OnPrem"
Once created we need to check the same settings as previously..
- Get-OrganizationRelationship -Identity "Exchange OnPrem" | fl
Again, we will need to configure some settings here to make the relationship work…
Set TargetApplicationURI to delegated OnPrem Namespace
If you followed the documentation to establish your federation trust this will be "federation.<primary SMTP domain>”
- Set-OrganizationRelationship -Identity "Exchange OnPrem" -TargetApplicationUri exchangedelegation.groovycloud.co.uk
Enable Mailtips
This setting enables mailtips to work between Exchange Org’s
- Set-OrganizationRelationship -Identity "Exchange OnPrem" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True
Enable Free/Busy Access
- Set-OrganizationRelationship -Identity "Exchange OnPrem" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel LimitedDetails
Check that the correct domain names are listed on the Organisation Relationship
As general rule the following should be listed as a minimum…
- Primary SMTP Domain (groovycloud.co.uk in my example)
Use the following command to write the correct domain names on the Org Relationship…
- Set-OrganizationRelationship -Identity "Exchange OnPrem" –DomainNames groovycloud.co.uk
NOTE: By default your tenant will be provisioned as a “tiny tenant”, this means that many of the configuration attributes are non writeable. If you intend to customize your address policies or RBAC polices then it is probably worth “hydrating” your tenant at this stage by running the “enable-OrganizationCustomization” cmdlet. This is not necessary to get hybrid availability working, but it may save you some headaches later on! (Thanks for the recommendation Tim!)
Example of a working Office 356 Organisation Relationship…
- Primary SMTP Domain Name : groovycloud.co.uk
- OnPrem EWS URL : https://mail.groovycloud.co.uk/EWS/Exchange.asmx
PS C:\LiveMesh\Tools\RemotePS> Get-OrganizationRelationship -Identity "Exchange OnPrem" | fl
RunspaceId : 94f72750-98a0-495d-91cc-bb26a88611da
DomainNames : {groovycloud.co.uk}
FreeBusyAccessEnabled : True
FreeBusyAccessLevel : LimitedDetails
FreeBusyAccessScope :
MailboxMoveEnabled : False
DeliveryReportEnabled : True
MailTipsAccessEnabled : True
MailTipsAccessLevel : All
MailTipsAccessScope :
TargetApplicationUri : exchangedelegation.groovycloud.co.uk
TargetSharingEpr :
TargetOwaURL :
TargetAutodiscoverEpr :
OrganizationContact :
Enabled : True
ArchiveAccessEnabled : False
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
Name : Exchange Onprem
DistinguishedName : CN=Exchange Onprem,CN=Federation,CN=Configuration,CN=neiljohn.onmicrosoft.com,CN=ConfigurationUnits,CN=Microsoft Exchange,CN=
Services,CN=Configuration,DC=eurprd02,DC=prod,DC=outlook,DC=com
Identity : Exchange Onprem
Guid : e3f00a9d-1534-479d-a439-d187aa02e05a
ObjectCategory : eurprd02.prod.outlook.com/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship
ObjectClass : {top, msExchFedSharingRelationship}
WhenChanged : 15/08/2011 09:48:18
WhenCreated : 15/08/2011 07:39:43
WhenChangedUTC : 15/08/2011 08:48:18
WhenCreatedUTC : 15/08/2011 06:39:43
OrganizationId : eurprd02.prod.outlook.com/Microsoft Exchange Hosted Organizations/neiljohn.onmicrosoft.com - eurprd02.prod.outlook.com/Config
uration/Services/Microsoft Exchange/ConfigurationUnits/neiljohn.onmicrosoft.com/Configuration
OriginatingServer : AMSPRD0202DC004.eurprd02.prod.outlook.com
IsValid : True
Ok, so now were all set up so the next step is to logon as some users to see what happens…
I am going to use the following accounts
- On premises User : ewstest@groovycloud.co.uk
- Office 365 User : office365User1@groovycloud.co.uk
On premises to Office 365
For this test I am going to log on to my ewstest account via Outlook 2010 and attempt to view availability data for my Office365User1 account. I have created a test meeting in each mailbox and set the default calendar permission level to “Free/Busy time, subject, location”.
A new meeting request running on premises logged on as user ewstest with Office 365 user Office 365 User 1 added as an attendee. You can clearly see that both users are returning rich availability data… yay!
For this test I am going to log on to my Office365User1account via Outlook 2010 and attempt to view availability data for my ewstest account. I have created a test meeting in each mailbox and set the default calendar permission level to “Free/Busy time, subject, location” the same as before…
As you can clearly see, the experience is exactly the same for an Office 365 user collaborating with an on premises user…. double yay!
Hopefully this article shows that it is possible to get availability to work cross premises. It does show however that even in this extremely simple example where I only have a single Exchange 2010 server and a handful of users, there were still a number of steps to complete and plenty of scope to get something wrong. I for one cant wait for Exchange Server 2010 SP2 to come along and simplify the whole thing!
In my experience working in labs and with customers the following are the most common areas of misconfiguration…
- Incorrect DomainNames on the Organization Relationship configuration
- Missing DNS Records for the Service Domain will stop client Autodiscover working for on premises clients accessing mailboxes in the cloud.
- TargetApplicationURI missing from Organization Relationship configuration – note: it doesn't seem to matter what you set this to as long as its not $null!
For further information and detail around more complex configurations please see
- Exchange Server Deployment Assistant https://technet.microsoft.com/en-us/exdeploy2010/default.aspx
Anonymous
January 01, 2003
Great article and good use of images!Anonymous
August 15, 2011
Awesome :-)Anonymous
August 16, 2011
The comment has been removedAnonymous
August 26, 2011
Thank you for another great and useful post! One question though: what are your thoughts about the possibility of using the Office 365 logon page to enter users’ wrong credentials multiple times in order to try and lock their AD account? I know they are some ways of trying to prevent this like DoS prevention at the ISP level, for example, but with Integrated Authentication (for Lync Online), your ADFS Proxy has to accept connections from any IP address in the world (to allow users to use the service from home). So there’s not actually a way of preventing this, is there? Thank you once again for the great post! Best regards, NunoAnonymous
February 15, 2012
Thank you for all the work. You rock.Anonymous
March 11, 2012
Hi Neil, Tremendous piece! Are ADFS 2.0 and Directory Synchronisation necessary to make a Lync Online user see free/busy from an on-premise Exchange 2010 server, or optional? If optional, do the steps you list above change much? ThanksAnonymous
March 12, 2012
Are ADFS and/or DirSync required to make this work? If not, what changes to your process are necessary to simply get on-prem Exchange 2010 to provide f/b to Lync online users with the Lync URI matching the Exchange SMTP addy? ThanksAnonymous
September 14, 2012
The comment has been removedAnonymous
February 06, 2015
This is a link throw-down for the items that we discussed during a recent Office 365 workshop that IAnonymous
February 27, 2015
One of the customers I was working with last week encountered an error whilst attempting an operation