Exchange Federation to Office 365 without Hybrid
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-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
# 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!
