Understanding Federated Delegation

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Information workers frequently have to collaborate with partners, customers, vendors, or other contacts outside their Exchange organization. For effective cross-organization collaboration, your users may have to share their free/busy (also known as calendar availability) information for scheduling meetings. Depending on the nature of the business relationship, users may have to share more detailed calendar information. Similarly, users may also have to share their contacts with these external recipients. In Microsoft Exchange Server 2010, federated delegation helps accomplish these goals.

Looking for management tasks related to federated delegation? See Managing Federated Delegation.

Contents

Collaboration Before Exchange 2010 and Federated Delegation

Federated Delegation

Firewall Considerations for Federated Delegation

Coexistence with Exchange 2007

Coexistence with Exchange 2003

Establishing an Organization Relationship and a Sharing Policy

Collaboration Before Exchange 2010 and Federated Delegation

Earlier versions of Exchange had limited sharing capabilities and required complex set up and ongoing maintenance. For example, to share availability information with users in another Exchange organization, you had to use the Inter-Organization Replication tool to replicate public folders between Exchange organizations. This process required you to create Active Directory trusts between both organizations, as well as manage service account credentials.

For recipients to be visible in Exchange address lists, many organizations used different tools such as GALSync to synchronize one organization's recipients to another organization. Setting up trusts, managing credentials, and replication with multiple external organizations was difficult and cumbersome. Creating Active Directory forest or domain trusts and credential management also had security implications. Opening additional ports on firewalls between the two organizations or establishing a virtual private network (VPN) was also required.

With the introduction of Exchange Web Services, the Availability service, and the Client Access server role in Exchange Server 2007, the replication of public folder free/busy data wasn't necessary. However, trust or credential information and global address list (GAL) synchronization was still necessary to make free/busy information available to external organizations.

Sharing a Calendar or Contacts folder also involved assigning permissions to access the folder to users in trusted organizations. The only way to accomplish this was by creating Active Directory trusts between the two organizations, which had additional security implications.

For more information, see How to Configure the Availability Service for Cross-Forest Topologies.

Return to top

Federated Delegation

Using federated delegation in Exchange 2010, users can share information with recipients in external federated organizations by establishing a federation trust and creating organization relationships between Exchange 2010 organizations. Organizations can also use sharing policies to allow users to create individual sharing relationships with recipients in other organizations. Federated delegation uses the Microsoft Federation Gateway, a Microsoft cloud-based service, as the trust broker between two federated organizations. To enable federated delegation, the organizations between which you want to share information only have to establish a one-time federation trust with the Microsoft Federation Gateway and configure either an organization relationship or sharing policies with each other.

To learn more about the Microsoft Federation Gateway and federation trusts, see the following:

• Microsoft Federation Gateway

• Understanding Federation

• Create a Federation Trust

• Manage Federation.

Federated delegation offers two ways for users to share calendar and contact information with external recipients: Organization relationships and sharing policies.

Organization Relationships

Organization relationships allow you to enable federated delegation with another federated organization for the purpose of sharing calendar free/busy information between users in both organizations. Organization relationships are one-to-one relationships between two organizations. Rather than requiring a complex Active Directory forest or domain trust configuration between the two organizations (which may also require opening multiple ports on firewalls in both organizations or establishment of a VPN), both organizations are required to establish only one federation trust with the Microsoft Federation Gateway and to configure their federated organization identifier prior to configuring the organization relationship with each other.

Requirements for Organization Relationships

The following are required for organization relationships:

• An Exchange 2010 Client Access server exists in each Exchange organization.

• Each Exchange organization has created a federation trust with the Microsoft Federation Gateway.

• Each Exchange organization has configured a federated organization identifier. Domains used for generating users' e-mail addresses have been added to the organization identifiers.

• An organization relationship exists in each corresponding organization.

• The Mailbox servers that are hosting user mailboxes can reach the Microsoft Federation Gateway servers and the federated partner organizations CAS servers.

Creating Organization Relationships

When you create an organization relationship with an external organization, users in the external organization can access your users' free/busy information. No replication of GAL information is required. With this configuration in place, Outlook 2010 and Office Outlook Web App users can simply enter the SMTP address of an external recipient when scheduling meetings.

When creating an organization relationship, you can specify one of the following three levels of calendar availability access:

• No free/busy access

• Free/busy access with time only

• Free/busy access with time, plus subject and location

For users in your organization to have access to external users' free/busy information or to allow for one-way sharing of their free/busy information with the external organization, the administrator in the external organization must also create an organization relationship with your organization. However, the external administrator can specify a different level of access for their users that's different from the level you specified. In a one-way sharing example, the external administrator would configure their organization relationship so that their users' free/busy information isn't shared with users in your organization, but the free/busy information for your users would be visible to the users in the external organization based on your organization relationship settings.

When you create an organization relationship, Exchange 2010 connects to the Autodiscover Web service published by the external organization to obtain the Availability service endpoint. You can also specify the external organization's Availability service endpoint manually when creating the relationship.

To create an organization relationship with an external organization, you can use the New Organization Relationship wizard in the Exchange Management Console (EMC) or the New-OrganizationRelationship cmdlet in the Exchange Management Shell.

For details instructions about how to create an organization relationship, see Create an Organization Relationship.

Sharing Policies

Unlike organization relationships, which only enable sharing of free/busy information with recipients in other federated Exchange organizations, sharing policies enable user-established, people-to-people sharing of both calendar and contact information with different types of external users. Sharing polices allow your users to share both their free/busy and contact information (including the Calendar and Contacts folders) with recipients in other external federated organizations. For recipients that aren't in an external federated organization or are in non-Exchange organizations, sharing policies allow people-to-people sharing of their calendar information with anonymous users through the use of Internet Calendar Publishing.

With sharing policies, you won't need to manage your users' collaboration relationships. Instead, they get to decide which external recipients they want to collaborate with. Using Outlook 2010 or Outlook Web App, users can invite external recipients in other federated domains to access their Calendar or Contacts folder and also request that they share theirs in return. Users can also grant anonymous access to their calendar information to any individual who has Internet access. With sharing policies, you only control what types of users they can share information with and how much information they can share. If necessary, you can also disable a user's or group's sharing policy.

Sharing policies are assigned to mailbox users. The default sharing policy applied to users allows availability information to be shared with all external federated domains. After you create a federation trust with the Microsoft Federation Gateway and configure the federated organization identifier, users can invite users in any external federated organization to share their calendar and contact information.

To allow access to user's calendars by recipients in non-federated domain organizations, such as family members, friends, or users in non-Exchange organizations, a separate sharing policy should be created that allows for anonymous calendar access through the use of Internet Calendar Publishing. For details, see Enable Internet Calendar Publishing.

Sharing policies can contain pairs of domain names and the sharing actions allowed for users from those domains. As shown in the following figure, you can specify the following actions that apply to the external domain specified in a sharing policy:

• Calendar sharing with free/busy information only

• Calendar sharing with free/busy information, plus subject and location

• Calendar sharing with free/busy information plus subject, location and body

• Contacts sharing

• Calendar sharing with free/busy information only, Contacts sharing

• Calendar sharing with free/busy information, plus subject and location, Contacts sharing

• Calendar sharing with free/busy information plus subject, location, and body, Contacts sharing

Calendar sharing actions

When creating a sharing invitation, your users can select the information they want to share, provided that the action is allowed by the user's sharing policy. For example, let's say you create a sharing policy with the following settings for Fabrikam and other federated domain organizations:

• Calendar sharing with free/busy information, plus subject and location for external users in Fabrikam.com

• Calendar sharing with free/busy information only for external users in all other federated domain organizations (represented by the asterisk [*] symbol)

Users who have this policy applied can either share their calendar free/busy information with other federated domain organizations or can also share additional limited details if they invite users from Fabrikam.com.

For details about how to create a sharing policy, see Create a Sharing Policy.

For details about how to apply a sharing policy to users, see Apply a Sharing Policy to Mailboxes.

Requirements for Federated Sharing Policies

The following are required for sharing policies between federated domain organizations:

• An Exchange 2010 Client Access server exists in each Exchange organization.

• Each Exchange organization has created a federation trust with the Microsoft Federation Gateway.

• Each Exchange organization has configured a federated organization identifier. Domains used for generating users' e-mail addresses have been added to the organization identifiers.

• User mailboxes are located on Exchange 2010 Mailbox servers in each Exchange organization.

• Only Outlook 2010 and Outlook Web App users can create sharing invitations.

Requirements for Non-Federated Sharing Policies

The following are required for sharing policies with non-federated domain organizations or individual anonymous access:

• An Exchange 2010 Client Access server exists in the Exchange organization that's sharing user's calendar information.

• User mailboxes are located on Exchange 2010 Mailbox servers in the Exchange organization that's sharing user's calendar information.

• The Client Access server must be enabled for Outlook Web App access.

Comparing Organization Relationships and Sharing Policies

Although organization relationships and sharing policies allow sharing of free/busy information with external users, they're intended for different scenarios. Organization relationships are created to collaborate with external federated organizations and are limited to sharing only free/busy information. Sharing policies govern what calendar and contact information your users can share with users in external federated organizations, non-federated Exchange organizations, non-Exchange organizations, and anonymous users.

The following table lists the differences between organization relationships and sharing policies.

Organization relationships vs. sharing policies

Return to top

Firewall Considerations for Federated Delegation

Federated delegation features require that the Mailbox and Client Access servers in your organization have outbound access to the Internet by using HTTPS. You must allow outbound HTTPS access (port 443 for TCP) from all Exchange 2010 Mailbox and Client Access servers in the organization.

For an external organization to access your organization's free/busy information, you must publish one Client Access server to the Internet. This requires inbound HTTPS access from the Internet to the Client Access server. Client Access servers in Active Directory sites that don't have a Client Access server published to the Internet can use Client Access servers in other Active Directory sites that are accessible from the Internet. The Client Access servers that aren't published to the Internet must have the external URL of the Web services virtual directory set with the URL that's visible to external organizations.

Return to top

Coexistence with Exchange 2007

In organizations that contain both Exchange 2010 and Exchange 2007 servers, users who have a mailbox on an Exchange 2007 Mailbox server can use organization relationships to share free/busy information with recipients in external federated domain organizations. The Mailbox server must be running Exchange 2007 SP2 or later, and you must have at least one Exchange 2010 Client Access server in the Exchange organization. You can use organization relationships by introducing a single Exchange 2010 Client Access server in the organization, providing a more robust solution than solutions that synchronize free/busy information and require GAL synchronization.

When using Outlook 2010 or Outlook Web App to scheduling a meeting on an Exchange 2007 server, a user who has a mailbox on an Exchange 2007 server can see free/busy information for a user in the external organization. Free/busy information for Exchange 2007 mailboxes is visible to recipients in the external organization.

Sharing policies are assigned to Exchange 2010 mailbox users. To use sharing policies, a mailbox must be located on an Exchange 2010 Mailbox server. Only Outlook 2010 and Outlook Web App clients can be used to generate or respond to sharing invitations.

Return to top

Coexistence with Exchange 2003

In organizations that contain both Exchange 2010 and Exchange 2003 servers, users who have a mailbox on an Exchange 2003 server can use organization relationships to share free/busy information with recipients in external federated domain organizations. The Mailbox server must be running Exchange Server 2003 SP2 or later, and you must have at least one Exchange 2010 Client Access and public folder server in the Exchange 2003 organization. The Client Access server acts as a proxy for all inbound and outbound free/busy requests and is used to configure organization relationship properties. The public folder server contains and manages a replica of Exchange 2003 public folder data for access of free/busy information by other federated Exchange 2010 organizations.

Internal and external Exchange mailbox users can view free/busy information in the Exchange 2003 organization by using Outlook 2003, Outlook 2007, Outlook 2010 or Outlook Web App. Sharing policies are assigned only to Exchange 2010 mailbox users. To use sharing policies, mailboxes must be located on an Exchange 2010 Mailbox server. You can't apply sharing policies to mailboxes located on Exchange 2003 servers.

Return to top

Establishing an Organization Relationship and a Sharing Policy

In this example, you're the administrator for Contoso, Ltd. Your organization entered into an agreement with Fabrikam, Inc. to develop a product that will be jointly marketed and sold by both organizations. To enable collaboration between the two organizations, users from the Marketing and Engineering departments of both organizations need to access each other's availability information. This collaboration should occur with minimal or no effort by users.

Contoso also collaborates with Litware, Inc. This collaboration is limited to a small subset of users. Users from both organizations should be able to establish sharing relationships with each other. Sharing of contacts and free/busy information should be allowed. No additional calendar information should be shared.

Additionally, Contoso users want to share their calendar information with family members to help coordinate outside activities that they manage in Outlook.

Lastly, sharing should occur without having to:

• Create any Active Directory forest or domain trusts.

• Exchange credentials between the organizations or individuals.

• Establish a VPN between the organizations or individuals.

To accomplish this scenario, take the following steps:

1. To configure federated delegation with Fabrikam and Litware, create a federation trust with the Microsoft Federation Gateway (if one hasn't already been created). This isn't required for sharing information with Contoso users' family members. This one-time procedure is required to use Exchange 2010 federation features. The process requires that an X.509 certificate be issued by a certification authority trusted by the Microsoft Federation Gateway. For details, see Create a Federation Trust.

2. Configure the federated organization identifier (if it isn't already configured). This process requires that you add the organization's accepted domains for which you want to enable federation to the organization identifier. This one-time procedure is required to use Exchange 2010 federation features. For details, see Manage Federation.

3. Create an organization relationship with Fabrikam, Inc. For details, see Create an Organization Relationship. Do the following:

   • To determine if the Fabrikam organization already has federation established, use the Get-FederationInformation cmdlet.

   • Select a distribution group that includes members from the Marketing and Engineering departments. Availability information for these users will be visible to Fabrikam users.

4. To allow users in both organizations to see availability information for each other, the administrator from Fabrikam, Inc. must also create an organization relationship with your organization.

5. Create a sharing policy for users who need to collaborate with users in the Litware.com domain. For details, see Create a Sharing Policy. Create the sharing policy with the following specifications:

   • To determine if the Litware organization already has federation established, use the Get-FederationInformation cmdlet.

   • Add the Litware.com domain to the sharing policy.

   • Select the Calendar sharing with free/busy information only, Contacts sharing action for the policy.

   • Assign the policy to users in your organization who need to collaborate with users from Litware. For details, see Apply a Sharing Policy to Mailboxes.

6. Create an anonymous sharing policy for Contoso users who need to collaborate with their family members. For details, see Create a Sharing Policy. Create the sharing policy with the following specifications:

   • Set the publishing virtual directory on the Client Access server. For details, see Set-OwaVirtualDirectory

   • Set the Webproxy URL for the Mailbox server. To do this, use the Set-ExchangeServer cmdlet with the InternetWebProxy parameter.

   • Enable the Client Access server virtual directory for anonymous publishing.

After you create the organization relationship with Fabrikam, Inc. and the sharing policy for Litware, Inc. and Contoso users, the following functionality will be available:

• All users will be able to view the availability information for users in the Marketing and Engineering departments of Fabrikam.

• Users in your organization who have the new sharing policy applied will be able send individual sharing invitations to users from Litware, Inc.

• Contoso users can invite their friends and family to view their calendar information by providing a link to their published calendar. Family members won't need special credentials to access the information.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.