How to Configure Exchange 2010 SP1 Federation

Monday, July 18, 2011
Exchange federation allows different Exchange organizations to share free/busy information with each other.  It does this without having to configure a one- or two-way trust between the organizations.


Federation is accomplished using the Microsoft Federated Gateway server, a free cloud-based service offered by Microsoft.  The Microsoft Federated Gateway (MFG) server acts as a trust broker between federated organizations, similar to the way a trusted root CA works for certificates.  All organizations that use federation must configure a one-time federation trust with the MFG, and orgs that share free/busy information must have an Organization Relationship with the other org(s) they want to share with.  Organization Relationships (sometimes called sharing policies) can be one-way, meaning that CompanyABC can share free/busy info with CompanyXYZ, but not necessarily the other way around.  Usually, each org will have a reciprocal Organization Relationship with the other org so they can see each other's calendar data.

There are a number of articles that explain how to configure federation, but all of them are for Exchange 2007 or Exchange 2010 RTM.  Exchange Server 2010 SP1 simplifies federation configuration, primarily by eliminating the requirement for a trusted-CA certificate and providing most of the federation configuration from the Exchange Management Console (EMC).

Microsoft also changed the Microsoft Federation Gateway servers in Exchange 2010 SP1.  The RTM version uses what Microsoft calls the "consumer instance" of MFG and requires a trusted certificate for federation.  SP1 uses the same Microsoft Online Services MFG used by the Business Productivity Online Suite (BPOS) and Office365, Microsoft's cloud offerings.  This new Online Services MFG uses self-signed certificates for federation (recommended), but can also still use trusted third-party certs.

If you are using the new SP1 MFG and try to create an organization relationship with an external org that uses the RTM MFG, you will see the following warning:

Warning:
The token issuers for the domain extrateam.com (uri:WindowsLiveID) don't match the issuer for your organization (urn:federation:MicrosoftOnline).


The following guide explains how to configure federation between two Exchange 2010 SP1 organizations.

Note: This article assumes there is a working autodiscover record for the partner organization.  Federation uses autodiscover to automatically configure the Organization Relationship for the remote org.  If autodiscover is not working, you will need to enter that information manually.

Create a new Federation Trust
  • Open the Exchange Management Console (EMC) and select the Organization Configuration node.
  • In the Actions pane, select New Federation Trust.  The New Federation Trust wizard will run.
  • Click New to form the new trust with the Microsoft Federation Gateway.  The wizard will create a new self-signed certificate called Exchange Delegation Federation with the subject name of Federation.  The Federation and SMTP services will be assigned to this certificate, but it will not change the default SMTP certificate.  The Microsoft File Distribution service will automatically copy and install this self-signed certificate to all of your Exchange 2010 client access servers.
  • Click Finish to close the wizard.

Create Domain Proof Records
Domain Proof records are TXT records created in your domain's external DNS zone.  The purpose of these TXT records is to prove the identity of your domain for the trust with the MFG server.  Exchange SP1 requires that you have at least two TXT records, one dedicated for domain delegation (typically, exchangedelegation.companyabc.com) and another for each SMTP domains you use for users (for example, companyabc.com).

Run the following cmdlets from the Exchange Management Shell (EMS) to generate the domain proof values:

Get-FederatedDomainProof -DomainName exchangedelegation.companyabc.com
Get-FederatedDomainProof -DomainName companyabc.com

Repeat the second cmdlet for additional SMTP domains you want to federate, if any.

Each cmdlet will generate a unique Proof value, based on a hash using the Exchange Delegation Federation self-signed certificate.  If the MFG can read the domain proof value in an external DNS record and it matches the calculated value, it proves domain ownership and validates the trust.


You must create one TXT record in external DNS for each of the Proof values.  How you do this depends on your external DNS management platform.  Here's how that looks for Microsoft DNS:


And here's how it may look in a managed DNS web GUI:


Remember, these TXT records should be entered in your external DNS, not internal.  You may need to wait a bit for the new TXT records to propagate across the Internet.  You will be unable to manage the federated domains until the MFG servers can access the domain proof TXT records.

Manage the Federated Domains
Once the domain proof TXT records have propagated you can add the federated domains to the Federation Trust.  But before we can add the federated domains, we must first add the new exchangedelegation.companyabc.com namespace to the Accepted Domains on the hub transport configuration.
  • Back in the EMC navigate to Hub Transport in the Organization Configuration node.
  • Click the Accepted Domains tab and click New Accepted Domain in the Actions pane.
  • Enter Exchange Federated Delegation for the Name and enter exchangedelegation.companyabc.com for the Accepted Domain, then click New.  This new authoritative accepted domain will never be used by users - it is only used by the federated trust.

  • Click the Organization Configuration node and select the Microsoft Federation Gateway trust under the Federation Trust tab.
  • Click Manage Federation in the Actions pane.  You will see the current federation certificate status.  You can click Show distribution state to check that the federation certificate is installed on all Exchange 2010 client access servers. 
  • Click Next to bring up the Manage Federated Domains window. 
  • Click Add and select the Microsoft Federated Trust accepted domain you created earlier.  I recommend adding just the Microsoft Federated Trust first, which creates the delegation namespace on the MFG server, the unique Application Identifier (AppID) and Application URI.  Then go back and add the SMTP domain(s) you want to federate (i.e., companyabc.com).
  • Click Next and Manage to configure Microsoft Federated Trust.  When the configuration is successful you will see the federation trust has an Application Identifier and Application URI.

  • If the TXT records you created earlier are incorrect or have not propagated yet to the MFG server, you will get the following error:
Error:
Proof of domain ownership has failed. Make sure that the TXT record for the specified domain is available in DNS. The format of the TXT record should be "example.com IN TXT hash-value" where "example.com" is the domain you want to configure for Federation and "hash-value" is the proof value generated with "Get-FederatedDomainProof -DomainName example.com".
The proof of domain ownership is not valid or is missing.
  • Once you have configured the original Microsoft Federated Trust you can repeat these steps to add your other accepted domains.  You can only add accepted domains that you have created domain proof TXT records for.

Create Organization Relationships
Now that the federated trust has been created and then validated by the MFG, you can create organization relationships.  These are the federation sharing policies that determine what is shared with whom.
  • Click the Organization Relationships tab on the Organization Configuration node in the EMC.
  • Click New Organization Relationship in the Actions pane.  The New Organization Relationship wizard will start.
  • Enter a name, such as Share with CompanyXYZ.
  • Select the Enable free/busy information access checkbox and specify the free busy data access level you wish to share using the dropdown box.
  • You may select a security group for which this relationship should apply.  If you do not select a security group the settings will apply for all users.

  • Click Next to enter the External Organization details.
  • Enter the domain you want to federate with (i.e., companyxyz.com), then click Next and New.  Exchange will create a new organization relationship using the data results from the Get-FederationInformation cmdlet.  If the external domain does not have a valid federation trust with the MFG or autodiscover record, you will see an error:
Error:
Federation information could not be received from the external organization.
  • When the organization relationship has been successfully configured you will see it listed under the Organization Relationships tab.  Sharing Enabled and Calendar enabled will show as True.

Testing and Troubleshooting
Use the following command to query for TXT records in DNS:

nslookup -q=txt companyabc.com [DNS server name to query]

Use the following cmdlets to get or test Exchange federation configuration information:
  • Get-FederatedOrganizationIdentifier - gets the Microsoft Exchange Server 2010 organization's federated organization identifier and related details, such as federated domains, organization contact, and status.  The Enabled attribute will show as False until the MFG has validated the trust using the domain proof TXT records in external DNS.
  • Get-FederationInformation - gets federation information, including federated domain names and target URLs, from an external Exchange organization.  It does this using the autodiscover record of the external domain.  This cmdlet will not work until you have a valid Federated Trust configured.
  • Get-FederationTrust - displays the federation trusts configured for the organization.  Use with Format-List to display the ApplicationIdentifier and ApplicationUri attributes, details about the federation certificates. and token information.
  • Get-OrganizationRelationship - gets settings for a relationship that has been created for free/busy information access or secure e-mail delivery using federated delivery.
  • Test-OrganizationRelationship - verify that the organization relationship is properly configured and functioning as expected for a given user.
  • Test-FederationTrust - runs the following series of tests to ensure that federation is working as expected:
    • A connection to the Microsoft Federation Gateway is established.  This test ensures that communication between the local Exchange server and the Microsoft Federation Gateway is working correctly.
    • Certificates are checked to ensure they're valid and can be used with the Microsoft Federation Gateway.
    • A security token is requested from the Microsoft Federation Gateway.  This test ensures that a token can be properly retrieved and used.

    Note that you must run the Test-FederationTrust cmdlet from either an Exchange Server 2010 Hub Transport or Client Access server.

If you're federating with a mixed-mode Exchange organization with Exchange 2003 users (as in a migration scenario) you will need to populate the TargetSharingEpr attribute of the Organization Relationship with that domain.  If you don't populate this value the free/busy information for Exchange 2003 users will be unavailable.  Populate the TargetSharingEpr value  in both organizations with the following cmdlet:
Set-OrganizationRelationship "CompanyABC" -TargetSharingEpr https://mail.companyabc.com/EWS/Exchange.asmx/WSSecurity
Replace mail.companyabc.com with the FQDN used by the external organization's Exchange Web Services (EWS) ExternalURL.  For example, run the following cmdlet in CompanyABC:
Get-WebServicesVirtualDirectory -Server ex2010 | fl ExternalUrl

ExternalUrl : https://email.companyabc.com/ews/exchange.asmx

CompanyXYZ should set Organization Relationship's TargetSharingEpr for CompanyABC to https://email.companyabc.com/EWS/Exchange.asmx/WSSecurity

Continuing the example, run the same cmdlet in CompanyXYZ:

Get-WebServicesVirtualDirectory -Server exchange01 | fl ExternalUrl

ExternalUrl : https://webmail.companyxyz.com/ews/exchange.asmx

CompanyABC should set Organization Relationship's TargetSharingEpr for CompanyXYZ to https://webmail.companyxyz.com/EWS/Exchange.asmx/WSSecurity

11 comments:

  1. Live@Edu still uses the consumer instance. Since word out of WPC11 was that Office 365 for Education was going to be delayed, if true, Live@Edu will still be around for a while.

    ReplyDelete
  2. I am having problem creating an organizational relationship from O365 to on-premise. The autodiscover failed. But I've verified it's working fine on my on-premise exchange environment.

    ReplyDelete
  3. Anonymous, check your domain proof TXT records.

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. Hi Jeff,

    Thank you for your post! After days of trouble shooting our On-premises Exchange to Office 365 "free-busy" issue, I have been able to solve "half" our problem.

    We are able to successfully see free-busy info from our On-premises Exchange to Office 365. But not vice versa.

    We get quite an outlandish error message when trying to look up free-busy from the Cloud:

    "No Information (Error Code: -2146233088)"

    I have implemented the fixes you suggested for Error "No Information (Error Code: 1509)". Unfortunately no success.

    In our scenario we have DomainA as a vanity domain federated via Office 365 with the MFG.
    We have DomainB and DomainC federated via the EMC On-premises Exchange (all lights up green using the New Federation Trust under Organization Configuration).

    We are running Exchange 2010 SP2 On-premises. We tried the Hybrid configuration Wizard, but that really messed things up. Only re-creating from scratch following your HowTo got things working again.

    I am pretty stumped with that error I am getting currently. Have you got any pointers or seen this before?

    After adding our Office 365 to the EMC as an additional Exchange Forest I ran the New Organization Relationship wizard for the "To On-Prem" config. Is that correct?

    My reason for doing this is that we have Mail Users under DomainB and DomainC on-premises and Mail Users under DomainA in the cloud. So there is a distinct split.

    I would appreciate any pointers or feedback you could give me.

    Regards,

    Ralf Linka

    ReplyDelete
  6. Hi Ralf,

    Your error, "No Information (Error Code: -2146233088)", points to a certificate chain problem. The error code returns possible errors like "new record duplicates primary keys of existing record in table", "Successful auto update of third-party root certificate", "Certificate Services configuration information is corrupted", "Certificate Services could not find required Active Directory information", and "The Issuing Certificate could not be found. The Certificate Services may need to be reinstalled."

    There is no need to use public certs for Exchange federation with SP1 or better. You might try tearing out the whole federation config and try again.

    ReplyDelete
  7. Hi Jeff,

    Thank you for your reply. I proceeded to redo the whole config (this time using powershell - to make sure I get the steps right).

    Free/busy lookup is working again from on-prem to cloud. However once again the cloud to on-prem is a beasty. This time with a different error message:

    The attenndee's server could not be found (Error Code: 5016).

    I have the suspicion that it has something to do with Autodiscovery, however the Microsoft Remote Connectivity Analyzer tests successful when I run it against a mail user account on-premises.

    When I run "Test-FederationTrust -UserIdentity bob@domain.xyz -verbose" (on-prem domain), all tests return as successful.

    I have logged a ticket with Office 365 Support to help me look into this as I have not been able to dig up much on this error.

    ReplyDelete
  8. Can anyone tell me how the certificate should be deployed in a scenario where there is a load balancer in front of the CASs? We understand the process right up to and including the the point where the CASs redistribute the certificate to all CASs and HTSs in the organization.

    What is unclear to us is how the certificate is used with the MFG. I.E. Is the certificate only used when the internal CASs access the MFG, in which case they don't need to be on the load balancer. However if the MFG can initiate a new connection into the CASs, then the certificate should be on the load balancer to handle the HTTPS traffic specific to the Federation Trust.

    If the certificate does need to go onto the load balancer, what configuration is required on the load balancer to make it work? We understand the configuration the load balancer will be specific to each manufacturer, but we are asking for general ideas like setting up a specific virtual directory to use the MFG certificate.

    Thanks!

    ReplyDelete
  9. Hi, we are setting up Office 365 to work with our on-premises Exchange 2010. When we get to update-hybridconfiguration using the Wizard, it failes with: Error: Updating hybrid configuration failed with error 'Subtask CheckPrereqs execution failed: Creating Organization Relationships.
    Microsoft.Exchange.Data.Common.LocalizedException: Unable to identify a suitable account namespace for the federation trust. The account namespace must be a hybrid domain that does not contain the default cloud domain (.onmicrosoft.com) and is 32 characters or less in length."

    Any ideas?

    ReplyDelete
  10. Hi, I have successfully setup a federation trust from 2 different domains to the MFG. I have created the organization relationship between them. What do I have to do to share the GAL from DomainA to DomainB? I need some DomainB users to be able to see the GAL from the DomainA..... ANY HELP would be great!!!!

    ReplyDelete

Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.