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
I'm happy to say that I definitely will be entering into the next Exchange MCM rotation in September. My three week training begins September 12, 2010 and ends October 1st.
Time synchronization across a Windows domain is very important. If a member server's clock varies more than 5 minutes from other domain servers, Kerberos tickets will fail. This causes random authentication errors for users and/or applications which are sometimes difficult to troubleshoot.
