Sharing in Exchange Online

Organization relationships allow you to enable federated sharing with another federated Exchange organization for the purpose of sharing calendar free/busy information between users in both organizations. Organization relationships are one-to-one relationships between two Exchange organizations, not a relationship between individual users in the Exchange 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 only to establish a single 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 2013 Client Access server exists in each on-premises Exchange organization. An Exchange Online organization can also establish an organization relationship with other Exchange Online organizations and Exchange 2010 organizations as long as the Exchange 2010 organization has Client Access servers that have Service Pack 2 (SP2) or higher installed.
  
• The external Exchange organization has created a federation trust with the Microsoft Federation Gateway.
  
• The external 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.
  

Note:
We highly recommend that users in both federated Exchange organizations use Outlook 2010 or later versions when using federated sharing features. Pre-Outlook 2010 client 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.

Creating organization relationships

---

When you create an organization relationship with another Exchange Online or external federated Exchange organization, users in the external organization can access your users' calendar 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 always honors the permissions set by the user.

When you create an organization relationship, Exchange Online servers connect 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 Administration Center (EAC) 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 in Exchange Online.

Unlike organization relationships, which only enable sharing of free/busy information with recipients in other federated Exchange organizations, sharing policies enable individual, user-established, people-to-people sharing of both calendar and contact information with 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 Exchange organizations.

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 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.

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 Create a Sharing Policy in Exchange Online.

Sharing policies can contain pairs of domain names and the sharing actions allowed for users from those domains. 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
  

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 in Exchange Online.

For details about how to apply a sharing policy to users, see Mailbox Features.

Although organization relationships and sharing policies both 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 on an organization-to-organization level and are limited to sharing only free/busy information. Sharing policies govern what calendar and contact information your individual users can share with other individual users in external federated organizations.

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

Organization relationships vs. sharing policies

The following limitations apply when sharing free/busy information between federated Exchange organizations:

1. Outlook Web Access 2003   When a user in an Exchange 2003 organization uses Outlook Web Access to access free/busy for users in a remote Exchange Online organization, the request will fail. Outlook Web Access connections from Exchange 2003 can’t make WebDAV (Web-based Distributed Authoring and Versioning) connections to a free/busy system folder to retrieve the free/busy information for remote users. Because Exchange 2013 doesn’t support WebDAV connections, the Exchange 2003 server can't connect to Exchange Online for Outlook Web Access requests. Outlook clients don’t experience this limitation because they use MAPI instead of WebDAV when connecting to Exchange Online.
   
2. Wide Area Network (WAN) latency   In Exchange 2003 organizations, the replicas for all free/busy folders must reside on Exchange 2010 SP2 Mailbox servers. In environments where Exchange 2003 public folder databases are located in multiple physical sites, there may be excessive latency and performance issues if internal free/busy queries have to traverse WAN links to access Exchange 2010 public folder databases not located in the same physical site.
   
3. Free/busy information period   Free/busy information requests to an external Exchange 2007 organization from an Exchange Online organization may fail due to a mismatch in the requested free/busy information period. By default, Exchange 2007 accepts availability requests for 42 days of free/busy information and Exchange Online may request 62 days of free/busy information. If the request exceeds the default 42 limit imposed by Exchange 2007, the request will fail.
   An Exchange 2007 administrator must follow these steps to configure their Exchange 2007 Client Access servers to accept longer period free/busy information requests from Exchange Online:
   
   1. On all Exchange 2007 Client Access servers, open the following file with a text editor such as Notepad: <Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config
      

      Caution:
      Before the administrator makes any changes to the web.config file, they should first make a copy of the file and store it in a safe location.

   2. Locate the appSettings section in the web.config file.
      
   3. Add a new key “<add key="maximumQueryIntervalDays" value="62" />” and save the web.config file.
      

      Note:
      By default, the maximumQueryIntervalDays value isn’t present. When this value isn’t present, Exchange 2007 uses the default interval of 42 days.

   4. Stop and restart Microsoft Internet Information Services (IIS) on all the Exchange 2007 Client Access servers.
      
4. Exchange organizations that have both on-premises and cloud users   If you configure federated sharing with another Exchange organization that’s configured in a hybrid deployment with Office 365, free/busy availability lookups for Office 365-based or remote users that have been moved to the cloud will fail. Because the organization relationship for your Exchange Online organization is with the remote on-premises Exchange organization, not the Office 365-based Exchange Online organization, the free/busy request can’t query the Office 365-based users. Exchange Online doesn’t support functionality to proxy these availability requests through the on-premises organization to the Office 365 service.