Configure a Hybrid Exchange 2013 environment with Oauth

Since there are already a lot of howto’s on the web on how to build a hybrid setup for Exchange 2013, I came across this alternative way to configure this whole thing with Oauth.

The problem I had and many others with me is that after configuring the Hybrid setup (manual or with the HCW) free/busy lookups were not working or maybe only working in a one way direction. Even after working with Microsoft Escalation Engineers for several days on what seems as such a small issue I needed a fast way to make this working. Microsoft recommended Oauth. Here is briefly how it works:

OAuth is an open standard for authorization that enables client applications to access server resources on behalf of a specific Resource Owner. OAuth also enables Resource Owners (end users) to authorize limited third-party access to their server resources without sharing their credentials. This technique can also be used to simply configure free/busy lookups for Hybrid environments. When created, the default organization relationship is not used but will be kept in place. So if you decide to remove the Oauth configuration the normal organization relationship will be used again.

First of all we need to connect to a local Exchange 2013 hybrid server on-premise. To create an Oauth configuration you need at least Exchange Server 2013 SP1. In the EMC create the Oauth configuration by typing the following command. Replace by your own Office 365 domain.

New-AuthServer -Name “WindowsAzureACS” -AuthMetadataUrl


The command below is also done on-premise in the EMC (the application identifier is default and should not be changed)

Get-PartnerApplication | ?{$_.ApplicationIdentifier -eq “00000002-0000-0ff1-ce00-000000000000” -and $_.Realm -eq “”} | Set-PartnerApplication -Enabled $true


on-premise on the CAS server (save the script below here as export.ps1) you can run this from powershell by navigating to the desktop and run the script.
It will create an oauth folder on the c drive with an oauth cert. It’s not needed to change anything on this script as everything is default.

$thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint

if((test-path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
md $env:SYSTEMDRIVE\OAuthConfig
cd $env:SYSTEMDRIVE\OAuthConfig

$oAuthCert = (dir Cert:\LocalMachine\My) | where {$_.Thumbprint -match $thumbprint}
$certType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$certBytes = $oAuthCert.Export($certType)
$CertFile = “$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer”
[System.IO.File]::WriteAllBytes($CertFile, $certBytes)


The best thing to do afterwards is to copy that folder temporary to your own computer including the certificate. Save the script below as upload.ps1 and run it from your own pc connected to the customer tenant in Office 365 with the Windows Azure Active Directory-module voor Windows PowerShell.
It’s not needed to change anything on this script as everything is default.

Import-Module msonlineextended;

$CertFile = “$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer”

$objFSO = New-Object -ComObject Scripting.FileSystemObject;
$CertFile = $objFSO.GetAbsolutePathName($CertFile);

$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
$binCert = $cer.GetRawCertData();
$credValue = [System.Convert]::ToBase64String($binCert);

$ServiceName = “00000002-0000-0ff1-ce00-000000000000”;

$p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
New-MsolServicePrincipalCredential -AppPrincipalId $p.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue


Copy the script below and save it as register.ps1 and run the script also in the customer Office 365 tenant. Adjust the externalauthority domain to your own one.


$ServiceName = “00000002-0000-0ff1-ce00-000000000000”;

$p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName;

$spn = [string]::Format(“{0}/{1}”, $ServiceName, $externalAuthority);

Set-MsolServicePrincipal -ObjectID $p.ObjectId -ServicePrincipalNames $p.ServicePrincipalNames;


Now we will switch back to on-premise to create an IntraOrganizationConnector with the following command. Note that for the TargetAddressDomains you will need the of your own tenant which you can retrieve from the following command in Powershell –> Get-AcceptedDomain

New-IntraOrganizationConnector -name ExchangeHybridOnPremisesToOnline -DiscoveryEndpoint -TargetAddressDomains


For the other way around we first need to retrieve the autodiscover link which you can get in Powershell which is connected to the customer’s tenant.
Get-FederationInformation –> Now copy the TargetAutodiscoverEpr value which is your DiscoveryEndpoint address in the command below. TargetAddressDomain is your domain used on-premise.

New-IntraOrganizationConnector -name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint -TargetAddressDomains


We should have a ProxyURL for the Availability Addresspace. To check if you already have this can be done with the following command –> Get-AvailabilityAddressSpace | fl –> The ProxyURL value should be populated. If this is not the case you can add it with the command below. Note that the ProxyURL is your own mail/webmail address used for Exchange /EWS/Exchange.ASMX as you can see. The ForestName is your own tenant in Office 365

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl -ForestName -UseServiceAccount $True


How to test if everything is properly configured:


You can test if your configuration is successful from Powershell connected to Office 365 with the following command: Note that the following command is done with a cloud (migrated mailbox). In the example below this is TargetURI is the ProxyURL we also used in the last step of the configuration.

Test-OAuthConnectivity -Service EWS -TargetUri -Mailbox -Verbose | fl


To test the other way around (on-premise) you can do it with the following Powershell command. Note that the TargetURI now is the Office 365 EWS (default). The mailbox used for testing is one which is not migrated (so locally on Exchange 2010/2013), in this example

Test-OAuthConnectivity -Service EWS -TargetUri -Mailbox -Verbose | fl -> 2013 mailbox


To check IF Oauth authentication is used for your virtual directories. Note that if you have a load balancer scenario you should check this on all Hybrid Servers –>
Get-WebServicesVirtualDirectory | fl

For the Hybrid 2013 CAS servers you should see something similar like this:
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

If Oauth is not listed as a configuration method you can correct this with the following command –>
Get-WebServicesVirtualDirectory -Server internalservername | Set-WebServicesVirtualDirectory -OAuthAuthentication $true

Share this blog!

Leave a Reply

Your email address will not be published. Required fields are marked *