Exchange 2010 federation trusts: Basics and requirements

Exchange 2010 federation trusts: Basics and requirements

Federation trusts give Exchange 2010 administrators an easy way to share calendar and contact information across organizational boundaries, but there are various requirements be aware of before using this feature.

When two Exchange-based companies form a strategic partnership, they may want to share calendaring and contact information.

Companies have been sharing information this way for quite some time, but setting it up is cumbersome. The process involves Active Directory-level trusts, opening firewall ports and in some cases, public folder replication.

    Requires Free Membership to View

    Login

    When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by Exchange professionals today working with Exchange, Outlook and other related technologies.

    Margie Semilof, Editorial Director

    By submitting your registration information to SearchExchange.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchExchange.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Premium Access

Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in September 2011

Exchange Server 2010 simplifies this process through federation trusts. Once a trust is established, there are two ways to collaborate with a trusted organization.

The most common collaboration method involves organizational relationships, which allows calendar sharing across organizational boundaries. You can choose to share free/busy information one time only, or you can include subject and location information. There is also an option to disable free/busy access.

Additionally, users can create sharing policies. Sharing policies let internal users share calendar and contact information with users in an external organization.

Here are some requirements and best practices for creating a federation trust between two organizations.

Exchange 2010 federated trust requirements

  • Client access server. Both organizations must have at least one Exchange 2010 client access server (CAS) in place. Although it is preferred for all Exchange servers to be running Exchange 2010, it is not required.

  • Outlook/OWA. Users should also be on Outlook 2007 or higher (or using OWA). Although Outlook 2007 works, Outlook 2010 provides a much better end user-experience.

    Users running Outlook 2007 can’t manually specify the SMTP address of external recipients when they want to access availability information. They can only access the information by picking the external recipient from the global address list (GAL). This also requires GAL synchronization with the external Exchange organization, which is another issue altogether.

  • Microsoft Federation Gateway. The federation trust is not established directly between the two Exchange organizations. Instead, each organization must establish a trust with the Microsoft Federation Gateway. The Microsoft Federation Gateway is a cloud service that acts as a trust broker between organizations.
  • DNS requirements. When an organization establishes a trust with the Microsoft Federation Gateway, it must prove that it owns the domain. To establish this proof, Microsoft provides each organization with an AppID. When an organization receives the ID number, it creates a special TXT record on its DNS server and includes the AppID. Microsoft uses this DNS record for verification purposes.
  • The Organization Identifier. The Exchange organization must also establish an Organization Identifier (OrgID). The OrgID is a list of accepted domains that is e enabled for federation. Larger organizations that use a complex domain structure may decide they only want to enable federation for certain domains. Domains will not be federated unless they’re included in the AppID.
  • The federated delegation namespace. Regardless of whether an organization is federating some or all of its domains, it must create a special namespace for federated delegation. This namespace must be different from any of the accepted domains. Microsoft recommends using ExchangeDelegation as the federated delegation name. For example, if an organization’s primary accepted domain name is Contoso.com, then the federated delegation namespace would be ExchangeDelegation.contoso.com.

  • Certificate requirements. The Exchange server that the federation trust is created from must be provisioned with either a self-signed certificate or an X.509 certificate. Microsoft normally advises against self-signed certificates in production environments, but a self-signed certificate is actually preferred over an external CA certificate when it comes to setting up federated trusts.

    Microsoft doesn’t elaborate on this recommendation, but it probably has to do with the complexities of managing certificates from external CAs. Regardless of which type of certificate you use, the certificate is only used for signing and encrypting delegation tokens. Additionally, the certificate is automatically replicated to any additional Exchange servers that need it.

ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

Back to top