Exchange Federation to Office 365 without Hybrid

Exchange Federation to Office 365 without Hybrid">

Twan van Beers
07 April, 2017

Exchange Federation has been around a long time, but of course more recently any time you talk about integrating with Office 365 people start going down the hybrid route. What if you don’t want hybrid though, what if all you want is to be able to share free/busy information?

Let’s set the scene. We have a tenant called contoso.onmicrosoft.com which has some accepted domains abc.com (default), def.com and ghi.com. We also have an On-Premises Exchange 2010 or later organization which also has some accepted domains, abc.com (default), klm.com, nop.com. Notice that abc.com is in both Office 365 and On Premises. This could be because the desire is to migrate to or from Office 365, or there are other reasons that prevent the use of Hybrid.

How does Exchange process Free/Busy requests… At a high level from what I can work out it goes

Is there a mailbox for the recipient you’re after, if so get availability from that mailbox
Is there an object for the recipient you’re after, if so use the targetAddress (externalEmailAddress) else use the smtp address typed in
Find an Organization Relationship that has that email domain listed in Domain Names and that allows Free Busy lookups
if one found, then see if the organizer object has a proxyAddresses entry where the domain matches a federated domain, if so then use that entry as the source, otherwise use the smtp address
Get a token from the Federation Gateway
If the organization relationship has a TargetSharingEpr then use that, otherwise if there is a TargetAutodiscoverEpr then use that to find the SharingEpr, otherwise do an autodiscover process to try to find it, each time passing the federation token for authentication
In the target organization it receives the incoming request and checks if the domain of the from address is in an organization relationship. If so then it allows the request (based on the pieces that are enabled) if not then HTTP 401 is returned (error 5037 in the free/busy screen)
If the request is allowed and if the recipient is a mailbox then return the availability information

Now I’m a PowerShell guy so I’ll be talking in cmdlets not GUI images…

Step 1 is On-Premises Federation Trust

The on-premises Exchange Organization must have a trust with the Microsoft Federation Gateway

New-ExchangeCertificate -FriendlyName “Exchange Federated Delegation” -DomainName abc.com -Services Federation -KeySize 2048 -PrivateKeyExportable $true -SubjectKeyIdentifier $ski
Get-ExchangeCertificate | ?{$_.subject -eq “CN=abc.com”} | New-FederationTrust -Name “Microsoft Federation Gateway”

Get-FederatedDomainProof -DomainName abc.com
# add the DnsRecord values from the output above to external DNS

Step 2 is On-Premises Organization Identifier

This is done after the DnsRecord above has propagated throughout DNS. It effectively completes the trust and pulls down some additional values to the Exchange Organization

Set-FederatedOrganizationIdentifier -DelegationFederationTrust “Microsoft Federation Gateway” -AccountNamespace “abc.com” -Enabled $true

Step 3 is On-Premises Organization Relationship

Now the key points with Organization Relationships are:

DomainNames should be the domains that are allowed to use this relationship (i.e. the caller domains)
*AccessLevel and *AccessEnabled flags should ideally be the same on both side, but the least restrictive will apply
Target* is how to reach the target or foreign organization

For relationships with Office 365 we can often use DomainNames xxx.onmicrosoft.com as the only domain. The TargetApplicationUri for Office 365 is always outlook.com

New-OrganizationRelationship -Name “O365” -FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails -DomainNames contoso.onmicrosoft.com -MailTipsAccessLevel All -MailTipsAccessEnabled $true -DeliveryReportEnabled $true -TargetApplicationUri outlook.com -TargetSharingEpr “https://outlook.office365.com/ews/Exchange.asmx”

Step 4 is Office 365 Federation Trust

Microsoft kindly takes care of this part for us and so there is nothing to do here

Step 5 is Office 365 Organization Identifier

When you run the Hybrid wizard it sets the DefaultDomain attribute in order to keep the Organization Relationships simpler and to allow hybrid to function. So we need to do something similar (note Hybrid would use contoso.mail.onmicrosoft.com but we can’t assume that AAD Connect is in play here)

Get-FederatedOrganizationIdentifier | Set-FederatedOrganizationIdentifier -DefaultDomain contoso.onmicrosoft.com

Step 6 is Office 365 Organization Relationship

Again the key points with Organization Relationships are:

DomainNames should be the domains that are allowed to use this relationship (i.e. the caller domains)
*AccessLevel and *AccessEnabled flags should ideally be the same on both side, but the least restrictive will apply
Target* is how to reach the target or foreign organization (in this case the on-premises environment)

New-OrganizationRelationship -Name “EXCHANGE” -FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails -DomainNames abc.com, klm.com, nop.com -TargetApplicationUri FYDIBOHF25SPDLT.abc.com -TargetAutodiscoverEpr “https://autodiscover.abc.com/autodiscover/autodiscover.svc/wssecurity” -TargetSharingEpr “https://mail.adb.com/EWS/exchange.asmx/wssecurity” -MailTipsAccessLevel all -Enabled $true -DeliveryReportEnabled $true -MailTipsAccessEnabled $true -TargetOwaURL ‘https://mail.abc.com/owa’

Step 7 is On-Premises grab a coffee

And that’s it, you’ve configured federation between Office 365 and Exchange without using Hybrid at all!

Twan van Beers

Twan is a senior consultant with over 30 years of experience. He has a wide range of skills including Messaging, Active Directory, SQL, Networking and Firewalls. Twan loves to write scripts and get deep and dirty into debugging code, in order to understand and resolve the most complex of problems.