Understanding Federated Sharing
Applies to: Exchange Server 2010
Information workers frequently need to collaborate with partners, customers, vendors, or other contacts outside the Exchange organization. For effective collaboration, your users may need to share their availability (free/busy) information for scheduling meetings or, depending on the nature of the business relationship, share more detailed calendar information. Similarly, users may also need to share their contacts with these external recipients. In Microsoft Exchange Server 2010, federated sharing helps accomplish these goals.
Looking for management tasks related to federated sharing? See Managing Federated Sharing.
Contents
Collaboration Before Exchange 2010 and Federated Sharing
Federated Sharing
Firewall Considerations for Federated Sharing
Coexistence with Exchange 2007
Establishing an Organization Relationship and a Sharing Policy
Collaboration Before Exchange 2010 and Federated Sharing
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 cumbersome. Creating Active Directory forest or domain trusts and credential management also have 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. For more information, see How to Configure the Availability Service for Cross-Forest Topologies.
Sharing a Calendar or Contacts folder 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 has security implications.
Return to top
Federated Sharing
Using federated sharing in Exchange 2010, users can share information with recipients in external federated organizations by creating organization relationships between two Exchange 2010 organizations, or by using a sharing policy so allows users to create sharing relationships on an individual basis. Federated sharing uses the Microsoft Federation Gateway, a cloud service offered by Microsoft, as the trust broker between two federated organizations. The organizations you want to share information between must only establish trust with the Microsoft Federation Gateway once. To learn more, see Microsoft Federation Gateway.
Important
If you disable the federated organization identifier for your Exchange 2010 organization, all federation features are disabled for your organization.
To learn about federation trusts, see Understanding Federation. For details about how to create a federation trust, see Create a Federation Trust. For details about how to configuring the federated organization identifier, see Manage Federation.
Federated sharing offers two ways to share information with recipients in external organizations: Organization relationships and sharing policies.
Organization Relationships
Using an organization relationship, you can establish a federated sharing relationship with another federated organization for the purpose of sharing availability (free/busy) information or enabling federated delivery of e-mail. 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), the organizations are only required to establish a single federation trust with the Microsoft Federation Gateway and to configure the federated organization identifier.
Requirements for Organization Relationships
The following are required for organization relationships:
- An Exchange 2010 Client Access server exists in the Exchange organization.
- A federation trust has been created.
- The federated organization identifier has been configured. Domains used for generating users' e-mail addresses have been added to the organization identifier.
- An organization relationship exists in each corresponding organization.
- 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 synchronization of the GAL 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' availability information. This helps external users schedule meetings with your users. No replication 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.
For users in your organization to have access to external users' availability information or to allow for one-way sharing of their availability information with the external organization, the administrator in the external organization must create an organization relationship with your organization. However, when creating their organization relationship, the external administrator can specify that their users' availability information not be shared with users in your organization (for example if they want the relationship to be used only for federated delivery).
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 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 with an external organization, you can specify the users for which you want availability information to be exposed to the external organization. For example, if users in your Finance department need to collaborate with users in the external organization, you can select the Finance distribution group. Availability information for your users who are members of the selected distribution group will be visible to all users in the external organization. Similarly, the external organization can create an organization relationship with your organization and specify which user's availability information should be available to your users.
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
Sharing policies allow users to share calendar and contact information with users in external federated organizations. Think of a sharing policy as a user-established, people-to-people policy. Your users specify which external recipients they want to collaborate with. Using Outlook 2010 or Outlook Web App, a user can invite external recipients to share their Calendar or Contacts folder. With sharing policies, you control the domains with which your users share information, including how much 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 domains. After you create a federation trust with the Microsoft Federation Gateway and configure the federated organization identifier, users can send invitations to share their availability information with users in any external organization.
Important
To participate in federated sharing, 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.
Sharing policies contain pairs of domain names and the sharing actions allowed for users from that domain. 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:
- 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 domains (represented by the asterisk [*] symbol)
Users who have this policy applied can either share only their availability information or can share 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 Sharing Policies
The following are required for sharing policies:
- An Exchange 2010 Client Access server exists in the Exchange organization.
- A federation trust has been created.
- The federated organization identifier has been configured. Domains used for generating users' e-mail addresses have been added to the organization identifier.
- User mailboxes are on Exchange 2010 Mailbox servers.
- Only Outlook 2010 and Outlook Web App users can create sharing invitations.
Comparing Organization Relationships and Sharing Policies
Although organization relationships and sharing policies allow sharing of availability information with external users, they're intended for different scenarios. Organization relationships are created to collaborate with external organizations and include the capability to enable federated delivery of e-mail between the two organizations. Sharing policies govern what information your users can share with users in external organizations, including organizations with which an organization relationship doesn't exist.
The following table illustrates the differences between an organization relationship and a sharing policy.
Organization relationship vs. sharing policy
Functionality | Organization relationship | Sharing policy |
---|---|---|
Requires a federation trust for your organization |
Yes |
Yes |
Recommends that the external domain be federated |
Yes |
Yes |
Allows sharing of availability information (including subject and location) with external organizations for all or a set of users |
Yes |
No |
Allows sharing of calendar folders with availability information |
No |
Yes |
Allows sharing of calendar folders with availability information, including subject and body |
No |
Yes |
Allows sharing of contacts |
No |
Yes |
Requires users to send a sharing invitation to external recipients |
No |
Yes |
Allows federated delivery |
Yes |
No |
Provides access method |
Internal Client Access server accesses the Client Access server of the external organization and retrieves availability information for the external user when requested. |
Client Access server accesses the Client Access server of the external organization and subscribes to the external user's calendar or contacts. |
Applies to all external domains |
No (a one-to-one relationship between two Exchange 2010 organizations) |
Yes |
Provides users with different sharing experiences with external recipient |
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 Sharing
Federated sharing features require that the 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) to all Exchange 2010 Client Access servers in the organization.
For an external organization to access your organization's availability 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 that have a mailbox on an Exchange 2007 Mailbox server can use organization relationships. The Mailbox server must have Exchange 2007 SP2 installed, 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 availability information and require GAL synchronization.
When using Outlook 2010 or Outlook Web Access to scheduling a meeting on an Exchange 2007 server, a user with a mailbox on an Exchange 2007 server can see availability information for a user in the external organization. Availability 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
Establishing an Organization Relationship and a Sharing Policy
In this example, you're the administrator for Contoso, Ltd. Your organization has 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 minimum 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 calendar availability information should be allowed. No additional calendar information should be shared.
Lastly, sharing should occur without having to:
- Create any Active Directory forest or domain trusts.
- Exchange credentials between the organizations.
- Establish a VPN between the organizations.
To accomplish this scenario, you must take the following steps:
- Create a federation trust with the Microsoft Federation Gateway (if one hasn't already been created). 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. Do the following:
- 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.
After you create the organization relationship with Fabrikam, Inc. and the sharing policy for Litware, Inc., 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 sharing invitations to users from Litware, Inc.
Return to top