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.
Important
If you disable the federated organization identifier for your Exchange 2010 organization, all federation features are disabled for your organization.
To learn more about the Microsoft Federation Gateway and federation trusts, see the following:
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.
Note
Office Outlook 2007 users can't specify SMTP addresses of external recipients to display availability information. Recipients must be picked from the GAL, which requires GAL synchronization with the external organization. Outlook 2007 users with mailboxes on Exchange 2007 Service Pack 2 (SP2) Mailbox servers can use Office Outlook Web Access on an Exchange 2007 SP2 Client Access server.
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.
Note
If users don't want to share their free/busy information with others, they can modify the Default permission entry in Outlook. To do this, users navigate to the Calendar Properties > Permissions tab, select the Default permission, and select None from the Permission Level list. Their free/busy information won't be visible to internal or external users, even if an organization relationship exists with an external organization. The organization relationship honors the permissions set by the user.
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.
Important
To participate in federated delegation, the external user's organization must also have a federation trust established with the Microsoft Federation Gateway, and the federated organization identifier must be configured.
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
.gif "Creating a Sharing Policy")
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
| Functionality | Organization relationship | Sharing policy |
|---|---|---|
Requires a federation trust for your organization |
Yes |
Yes when sharing with other federated domain organizations. Not required for Internet sharing policies. |
Recommends that the external domain be federated |
Yes |
Yes when sharing with other federated domain organizations. Not required for Internet sharing policies. |
Allows sharing of free/busy information (including subject and location) with external organizations for a set of many users. |
Yes |
No |
Allows sharing of Calendar folders with free/busy information |
No |
Yes |
Allows sharing of Calendar folders with free/busy information, including subject and body |
No |
Yes |
Allows sharing of contacts |
No |
Yes when sharing with other federated domain organizations. Not required for Internet sharing policies. |
Requires users to send a sharing invitation to external recipients |
No |
Yes |
Provides an access method |
Your Client Access server accesses the Client Access server of the external organization and retrieves free/busy information for the external user when requested. |
Your Client Access server accesses the Client Access server of the external organization and subscribes to the external user's Calendar or Contacts folder for federated domain organizations. For Internet sharing policies, external users access either a restricted or public URL on the Client Access server. |
Can be applied to all external domains |
No (a one-to-one relationship between two Exchange 2010 organizations) |
Yes |
Provides users with different sharing experiences with external recipients |
No |
Yes, based on the sharing policy that's applied |
Disables sharing for some users |
Yes, by specifying a security distribution group for the organization relationship |
Yes, by disabling the sharing policy that's applied |
Requires that the mailbox reside on an Exchange 2010 Mailbox server |
No |
Yes |
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:
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.
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.
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.
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.
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.
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.