Freigeben über

Office 365 Hybrid Deployment / Exchange Rich Coexistence – Sharing Availability (Free/Busy)

  • Artikel

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…

What is Office 365 Hybrid Deployment?

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.

What do I need to make it work?

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…

 

Prerequisite Tasks…

It is assumed that the following tasks have been completed…

  1. Trust has been established with the Microsoft Federation Gateway : https://technet.microsoft.com/en-us/library/dd335198.aspx
  2. All required SMTP domains have been verified in Office 365
  3. Exchange Web Services have been published on premises : https://blogs.technet.com/b/exchange/archive/2010/07/16/3410408.aspx
  4. ADFS 2.0 is configured and working
  5. Directory Synchronisation is configured and working

 

Pre Flight Checks…

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”

2011-08-15_0541

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…

2011-08-15_0545

2011-08-15_0557

 

Configuration…

OK, so now we are ready to begin some configuration… we will follow this order to get things up and running…

  1. Create service domain
  2. Create on premises –> Office 365 organisation relationship
  3. Create Office 365 –> on premises organisation relationship
  4. 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>

2011-08-15_0619

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

2011-08-15_0622

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'

2011-08-15_0649

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

2011-08-15_0653

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.

2011-08-15_1033

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..

 

Create on premises –> Office 365 organisation relationship

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

2011-08-15_0721

  • 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

2011-08-15_0715

  • When prompted, select to Automatically discover configuration information and enter in the *.onmicrosoft.com domain for your tenant.

2011-08-15_0716

2011-08-15_0724

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

2011-08-15_0726

Set TargetSharingEPR…
This value overrides the autodiscover URL and instead hard codes the EWS endpoint that will be used.  This is not required, however hard coding this URL has proven to be more reliable in most deployments.  Note, use the “POD” server name that you recorded earlier via OWA.

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.

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      : https://pod51007.outlook.com/EWS/Exchange.asmx
 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

Create Office 365 –> on premises organisation relationship

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

2011-08-15_0745

Again, we will need to configure some settings here to make the relationship work…

TargetSharingEPR

Set this to be your published on premises EWS endpoint that you verified with the Exchange Remote Connectivity Analyzer earlier in the process…

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

Example of a working Office 356 Organisation Relationship…

**

 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      : https://mail.groovycloud.co.uk/EWS/Exchange.asmx
 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

 

Testing…

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 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”.

2011-08-15_1004

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! Smile

2011-08-15_1001

 

Office 365 to On premises

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…

2011-08-15_1009

As you can clearly see, the experience is exactly the same for an Office 365 user collaborating with an on premises user…. double yay! Smile

Conclusion

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.
  • Incorrect URL for TargetSharingEPR
  • 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