All posts tagged Federation


Federation always fun as you may have read in one of my previous blogs. Starting this week we had some issues at a customer where the Free/busy lookups across environments stopped working. Not only to other Exchange environments but also Office 365.

Both the Outlook logging and event logs on the CAS provided the same error. The complete error message is displayed below:

Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <johan.veldhuis@domain.com>SMTP:johan.veldhuis@domain.com failed. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: Autodiscover failed for e-mail address <johan.veldhuis@domain.com>SMTP:johan.veldhuis@domain.com with exception System.Web.Services.Protocols.SoapHeaderException: An error occurred when processing the security tokens in the message.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3()
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation). —> System.Web.Services.Protocols.SoapHeaderException: An error occurred when processing the security tokens in the message.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3()
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation)
   — End of inner exception stack trace —
. Name of the server where exception originated: EXC01. This event may occur when Availability Service cannot discover an Availability Service in the remote forest.

The bold part marks the error in this case An error occurred when processing the security tokens in the message. This error tells you there is an issue with the security token which your server has received from the Microsoft Federation Gateway. So probably this customer is not the only customer facing this issue.

Microsoft has acknowledged there were some issues earlier this week which not only affected this functionality but also some Office 365 services.

Office 365 status

Currently a work around is available to fix this issue. To fix the issue you will need to refresh the federation trust metadata. This can be done by using the following Powershell cmdlets:

Get-Federationtrust|Set-Federationtrust -Refreshmetadata

It is important to know that this cmdlet will need to be run on both sides else it may not fix the issues. Once the cmdlet have been executed it may take some time before the free/busy lookups start to work again.

During the implementation of a rich-coexistence environment between an Exchange 2010 On-Premise environment and Office 365 I had an issue with the Free/Busy which didn’t work correctly. Using the On-Premise environment I could retrieve the Free/Busy information from an Office 365 user but it didn’t worked from Office 365 to On-Premise. The error I got was that it couldn’t connect to the On-Premise environment

Because the Cloud couldn’t connect I decided to have a look at the TMG. In the logging no requests could be seen in the logging. So the requests where blocked somewhere else. To troubleshoot this issue I decided to connect to Office 365 via Powershell.

To check if the organization relationshop works correctly you can use Test-OrganizationRelationship, for example:

Test-OrganizationRelationship -identity “To_OnPremise” -UserIdentity johan@domain.com

When I ran this cmdlet it gave the following error:

 So there was an issue with the delegation token. The delegation token is provided by the Microsoft Federation Gateway. There are two gateways:

  • Consumer, used by Windows Live and Live.edu
  • Commerciële, used by Office 365 and Exchange On-Premise environments

To check which federation gateway is used by the solution you can use the Get-FederatedOrganizationIdentifier cmdlet. This cmdlet returned the following output:

As you can see the DelegationTrustLink has the value WindowsLiveID this means that the consumer version of the federation gateway is used. Because this gateway can’t be used by Office 365 you won’t get a token from the federation gateway.

A correct federation from Office 365 side will look like this:

As you can see the DelegationTrustLink has the value MicrosoftOnline, the commercial version of the Microsoft Federation Gateway.

To fix the issue you will need to contact Office 365 support. Support can recreate the federation trust which ensures that a token can be retrieved from the Federation Gateway

Exchange Federation – part II

Exchange Federation

In the first part of the article we did had a look at how Exchange Federation Works. After that we had a look at how to configure a Federation Trust and Organizational Configuration.

In this part of the article we will continue with configuring the federation. Most Exchange CAS Servers are placed behind a firewall and in most cases a reverse proxy is placed in front of it too.

Reverse proxy configuration

You can for example use the Threat Management Gateway of Microsoft.  We will assume that the default rules for publishing the Web Services are already configured. The authentication is performed by the TMG instead of the CAS Servers. In most cases Form Based Authentication, Basic or NTLM/Kerberos is used for authentication

The authentication methods can’t be used for the Federation Trust and Organizational Configuration. Because the credentials of a user will be verified by the Microsoft Federation Gateway (MFG) and not by a domain controller.

Because this authentication type is not permitted by the TMG for the several sites the traffic will be blocked. This can be solved by creating separate rules in the TMG for the following sites:

  • /EWS/Exchange.asmx/wssecurity
  • /Autodiscover/Autodiscover.svc
  • /Autodiscover/Autodiscover.svc/wssecurity

The TMG will need to passthrough the traffic  directly to the CAS Server instead of authenticating.

Troubleshooting cmdlet’s

Such as with most things configuring a Federation Trust and Organizational Configurational will not work smoothly always. For example you may think it works but when testing it you will get an error.

Exchange 2010 SP1 contains several test cmdlets to verify the functionality:

  • Get-FederationOrganizationIdentifier
  • Get-FederationInformation
  • Get-FederationTrust
  • Get-OrganizationRelationship
  • Test-OrganizationRelationship
  • Test-FederationTrust


With this cmdlet we will retrieve the following information:

  • Who is the organization identifier for the Exchange organisatie;
  • What are the additional domains which are configured for federation;
  • Who is the contact for the trust;
  • Is the domain proof TXT validated by the MFG


This cmdlet can be used after a configuration trust has been configured. The cmdlet will retrieve the following information:

  • Federated domain names;
  • Target URLs of the external Exchange organisation;


Get-FederationInformation –DomainName domain.com


Using this cmdlet an overview will be displayed of the configured federation trust of the organization. The following information will be used when the |FL parameter is used:

  • ApplicationIdentifier;
  • ApplicationUri attributes;
  • Certificaat details;
  • Token details;


Using this cmdlet the settings for the configured organization relationship will be displayed. Information which is being displayed by using this cmdlet:


Get-OrganizationRelationShop –Identity TrustedDomain


Using this cmdlet you can test the organization relationshop is configured correctly and i fit Works. This cmdlet needs to be run i.c.w. a valid useraccount.


Test-OrganizationRelationship –UserIdentity johan@domain.com –Identity domain.com –Confirm

The UserIdentity parameter is the account for which a security token will be requested. The Identity is the name of the organization relationship which needs to be tested.


Performs several tests to validate that the federation trust works correctly. The following tests will be performed:

  • Can a connection be made to the MFG;
  • Are the certificates valid;
  • Can a security token be requested from the MFG.


Test-FederationTrust –UserIdentity johan@domain.com

In the example above the useraccount will be specified as the UserIdentity. When no UserIdentity is specified the default test mailbox will be used. The default test mailbox can be created by using the New-TestCasConnectivityUser.ps1 script.



One of the issues you will propably not see many times is an invalid certificate. This can be caused because the certificate is not valid anymore because the certificate is expired.

But it may also occur when you try to request a new certificate. It sounds a bit strange but I did had this issue one. The MFG’s are placed in the GMT timezone. When the Exchange environment is located in another timezone it can occur that the certificate will be generated in the future from MFG perspective. The solution for this issue is wait. In the case of GMT+1 you will have to wait one hour and then try it again

Incorrect external URL for EWS

Because federation is depending on the Exchagne Web Services it is important that the correct external URL’s are configured. When this is not the case the EWS url will not be available and so no free/busy information will be displayed.

To solve this issue you will need to configure the external URL by using the Exchange Management Shell:

Set-WebServicesVirtualDirectory -Identity Server\EWS* -ExternalUrl https://mail.domain.com/EWS/exchange.asmx

Besides this it’s important that the URL is published correctly by the reverse proxy.

Changes are not active immediately

In case a change is made in the federation it might not be effective immediately. This is caused by the fact that caching is used which will result in the old configuration to be used till the cache expires.

For a federation between two Exchange 2010 environments or an Exchange 2010 and Office 365 this can take up to 7 hours.

Autodiscover doesn’t work

Although the autodiscover functionality is not required for configuring the federation it is important to let the federation work eventually. Verify the autodiscover service url is accessible on the lan but also from the internet. If autodiscover doesn’t work correctly this will cause that the other Exchange 2010 environment can’t resolve the necessary information.

Here ends the second part and last part of the Exchange Federation series. If you’ve got any questions about it don’t hesitate to contact me.

Exchange Federation – part I

Since Exchange 2003 it’s possible to setup a federation between Exchange organizations. Compared to older Exchange versions configuring a federation between two organizations became quiet easy in Exchange 2010.
Although you might encounter some issues while configuring the federation.

In this series of blog articles we will have a look at several issues and will look how to troubleshoot these issues.

But to solve an issue it’s important to understand the concept. There for we will start with an explanation of how federation and how to configure it.
To build a federation between two companies two things will need to be configured:

  • Federation Trust;
  • Organization Relationship;

Federation trust
Before creating the Organization Relationship we will first need to configure a Federation Trust. This Federation Trust will be setup between the Exchange 2010 on-premises environment and the Microsoft Federation Gateway (MFG).

The MFG is the component in the federation setup which is responsible for authentication and providing authentication tickets. In this case the MFG is also known as the trust broker. The on-premises Exchange environment uses a certificate to authenticate itself to the MFG. The MFG is available in two sorts:

  • Business instance, used by Exchange 2010 SP1 and Microsoft Online Services;
  • Consumer instance, used by Exchange 2010 RTM, organizations who decide to use a 3rd party certificate and Live@edu;

Microsoft recommends to ensure that both organizations are using the same MFG.
Before you configure a federation trust it’s important to know if you will use federated delegation.
Using federated delegation it’s possible to share information between users in both environments. To use this functionality one of the requirements is that you will create a subdomain which is used for federated delegation. This subdomain may not be the same as the primary SMTP domain which is being used. This subdomain must be set as Organization Identifier. Microsoft recommends to create a subdomain called exchangedelegation.domain.com for this purpose. The MFG will use this subdomain to assign a unique identity to every user. This identity will be used to get a Security Assertions Markup Language (SAML) delegation token. Using this token users can authenticate themselves to the other Exchange organization.

Configuring a Federation Trust can be divided in the following steps:

  1. Create a Federation Trust;
  2. Retrieve the Domain Proof;
  3. Create DNS TXT record;
  4. Configure the Organization Identifier and additional domains for Federation;

The first step can be performed by using the Exchange Management Console (EMC) or Exchange Management Shell (EMS). Keep in mind that when you want to use a 3rd party certificate you can only create the Federation Trust using the EMS.

Federation Trust

The method below will create a trust with the MFG and creates a self-signed certificate for authentication:

  • Open the EMC;
  • Select the Organization Configuration;
  • Select the option New Federation Trust;
  • Click the option New;
  • Click Finish to close the wizard;


Get-ExchangeCertificate | ?{$_.friendlyname -eq “Exchange Federated Delegation”} | New-FederationTrust -Name “Microsoft Federation Gateway”

Domain Proof
When the trust has been created we will need to retrieve the domain proof. The domain proof must be used to create a TXT record in the DNS. Using the domain proof a check will be performed if your really the owner of the domain.
The domain proof can only be gathered by using the EMS:

Get-FederatedDomainProof –DomainName domain.com

Keep in mind that if you are going to use Federated Delegation you will need to perform this step for both the subdomain and the mail domains.
Add domains to the Federated Trust
When both the trust and domein proofs are created we can continue by adding the domains to the Federated Trust.
Before you can perform this step you will need to add the subdomain to the accepted domains of Exchange:

New-AcceptedDomain -DomainName exchangedelegation.domain.com -Name FederationDomain

When the cmdlet above has been executed we can configure the federation trust. This will need to be performed in two steps:

Set-FederatedOrganizationIdentifier -DelegationFederationTrust “Microsoft Federation Gateway” -AccountNamespace exchangedelegation.domain.com -Enabled $True

Using the cmdlet above we will configure the trust to use the subdomain as the organization identifier. The organization identifier is being used for authentication. During this process a check will be performed if the TXT records can be found in the DNS. If the record can be found the configuration will be updated.
To finalize the federation trust configuration you will need to add all the other domains to the trust. This can be done by using the Add-FederatedDomain cmdlet. Just like the previous cmdlet a check is being performed for the TXT record.

Add-FederatedDomain -DomainName domain.com

Using this step the configuration of the Federation Trust has been completed.

Optionally you can also use the EMC to perform these steps. The advantage of this is that you can perform both steps via the same wizard.

Create an Organization Relationship
To share the free/busy information between the organizations its necessary to create an Organization Relationship.
Creating an Organization Relationship can be performed by using either the EMC or the EMS.


  • Open te EMC;
  • Select te Organization Configuration;
  • Select the option New Orginization Relationship;
  • Configure the name of the other organization on the Introduction page, activate the Organization Relationship and soecify which information you want to make available to the other organization. Optionally you can assign a security group which let’s you only share the information of the members of the group;
  • On the External Organization page either chose to manually or automatically configure the relationship. When chosing for the automatic way autodiscover will be used. If things change at the organization side you won’t have to change it manually.
    If selecting the manual method you will need to provide the following information:
    Federated domains of external Exchange organization: add both exchangedelegation.domain.com and domain.com;
    Application URI of the external Exchange organization: exchangedelegation.domain.com, this information will be used to request a  delegated token;
    o Autodiscover endpoint of external Exchange organization, this url will be used to retrieve the url’s of the CAS Server. This because the Free/Busy info will be retrieved by using EWS. The url will look like this:
  • On the New Organization Relationship page verify the configuration and press New to create the Organization Relationshop.

New-OrganizationRelationship -Name “External Company” -DomainNames “exchangedelegation.domain.com”,”domain.com” -FreeBusyAccessEnabled $true 
-FreeBusyAccessLevel LimitedDetails -TargetAutodiscoverEpr “https://autodiscover.domain.com/autodiscover/autodiscover.svc/wssecurity” -TargetApplicationUri “exchangedelegation.domain.com

In the example above we will configure the Organization Relationship manually. Autodiscover will be used to retrieve the EWS url’s.  If you would like to retrieve the Domainnames, TargetAutodiscoverExpr and TargetApplicationUri automatically you will need to create the Organization Relationship like this:

Get-FederationInformation -DomainName domain.com | New-OrganizationRelationship -Name “External Company” -FreeBusyAccessEnabled $true -FreeBusyAccessLevel -LimitedDetails

In the example above we will first retrieve the Federation Information of the domain. Next we will use the output of the Get-FederationInformation to create the Organization Relationship.

To use the features offered by the Organization Relationship you will need to use one of the following clients:

  • Outlook 2010
  • Outlook Web App/Outlook Web Access
  • Outlook 2007

When using Outlook 2007 there’s one thing you should keep in mind. Typing in the SMTP address, just like in Outlook 2010/OWA, doesn’t work with Outlook 2007.  If Outlook 2007 is the only Outlook version which is in use you will need to add all users from the other organization as contacts so they will appear in the Global Address List.

What happens when free/busy information is retrieved?
But what happens when a user request free/busy information of a user in another organization?

In the workflow below a complete overview of the process:

  1. User provides a SMTP adress of another user in another organization;
  2. The CAS Server checks if Federation is configured;
  3. The CAS Server send a token request to the Microsoft Federation Gateway;
  4. The Microsoft Federation Gateway verifies if the source organization is trusted by the target organization;
  5. The Microsoft Federation Gateway sends a token back to the CAS Server which requested the token. The token is signed and encrypted with the public key of the target organization;
  6. The CAS Server sends the free/busy request to the CAS Server of the target organization;
  7. The Target CAS Server receives the token;
  8. The Target CAS Sever verifies if the organization which sends the request is in the trust list;
  9. The Target CAS Server checks which free/busy information may be displayed;
  10. The Availability Service requests the information from the mailbox;
  11. The answer is send back to the client;

Here ends the first part of how Federations can be used in Exchange 2010. In the next part we will have a look at how you can safely publish it to the internet and will start with some troubleshooting.

Technet – Understanding Federation open

Technet – Creating a Federation Trust open