Exchange 2010 SP1 and Exchange Online (Office 365) incorporate federation to enable secure organization-to-organization free/busy and calendar sharing with other Exchange organizations. Also new is the ability for users to publish their calendar in iCal format to anyone, and for them to subscribe to internet calendars. With Exchange now providing options for how your users can share calendar data with others inside and outside your organization, we've received a number of common questions about the differences in setup and functionality between sharing methods. These questions and their responses below can provide clarity as you consider calendar sharing in your organization.

-David Alexander, Technical Product Manager

What is the difference between Federated Calendar Sharing and Internet Calendar Sharing, and why do Federated Sharing instead of Internet Sharing?

• Exchange 2010 SP1 provides organizations with options for how their users can share calendar data with others inside and outside the organization, based on organizational requirements.
• Internet Calendar Sharing allows users to share (and subscribe to) calendar data in iCalendar format with any anybody, inside or outside the organization, whether those recipients are using Exchange, another platform, or simply a web browser. Internet Calendar Sharing does not require authenticated access or Federated Trust, and the only setup required is for the Exchange administrator to turn the feature on.
• Federated Calendar Sharing enables authenticated access to users' calendar data, and it is available only between Online and/or on-premises Exchange organizations who have established a Federation Trust with the Microsoft Federation Gateway, which acts as a broker between Federated organizations.
• In the case of both Federated Calendar Sharing and Internet Calendar Sharing, the on-premises or Online Exchange administrator can control with what level of granularity users are able to share calendar data (free/busy only, free/busy with titles/locations, or full calendar details). Administrators can define a Sharing Policy and apply that to the entire org, certain divisions, or even individual users. Within the scope of what the administrator has allowed, a user has the option to publish their data with even less granularity.
• Why do Federated Sharing vs. Internet Sharing? Not all organizations wish to enable anonymous (unauthenticated) access to calendar data at any level of granularity, in which case Federated Sharing is the way to go. Federated Sharing can also allow org-wide access to free/busy information between orgs based on org-org relationships set up by the admin, as well as the sharing of contact folders.

In Internet Calendar Sharing, can a privately shared calendar really be private? What if somebody forwards the link I sent to another person who shouldn't have access to my calendar?

• In order for Exchange 2010 SP1/Exchange Online (Office 365) to deliver on the promise to let Exchange users share/consume calendars with anybody, even non-Exchange users, we had to relax the requirement for authenticated access and allow for the anonymous access to users' calendar data (within the scope allowed by the Exchange administrator).
• Exchange has a number of built-in features to address security concerns an organization might have with anonymous access. For one, Internet Publishing is OFF by default, and an admin can decide whether the whole org, certain divisions, or even individual users have Internet Calendar Sharing enabled or not, and at what level of detail. Exchange also bases the Calendar Sharing from a dedicated calendar sub-virtual directory off the OWA vdir, and this calendar vdir is set with HTTP access while OWA is set with HTTPS, so admins do not allow anonymous access to the OWA parent vdir by turning this on.
• When Internet Calendar Sharing is turned on, Exchange can provide a level of security for those wishing to privately share their calendar, by obfuscating the calendar sharing URL, or formatting it such that it cannot be guessed or discovered by searching on the internet. Exchange does not control how a URL owner or recipients distribute this restricted URL. However, if a restricted URL is distributed further than originally intended, or if an owner wishes to update with whom their calendar is shared, they can reset the URL at any time. The owner simply stops and then restarts publishing, which generates a new obfuscated/restricted URL, and then chooses a new set of URL recipients. The old URL no longer allows access to the owner's calendar data.
• If anonymous access to users' calendar data at any level of granularity does not meet an Exchange organization's security needs, Exchange 2010 SP1/Exchange Online (Office 365) has made it even easier to set up Federated Calendar Sharing between Exchange orgs wishing to share calendar data in an authenticated fashion.

How do Exchange 2010 SP1/Exchange Online (Office 365) organizations set up Federated Calendar Sharing?

• To set up Federated Calendar Sharing between Exchange 2010 SP1/Exchange Online (Office 365) organizations, both must have Federated Trust established with the Microsoft Federation Gateway.
• Trust with the gateway is automatically established for Exchange Online (Office 365) organizations. On-premises organizations must manually establish Trust with the gateway, but this has become even more simplified in Exchange 2010 SP1. Information on how to create a Federation Trust can be found on this TechNet site.
• Once Federated Trust is established with the gateway, the Default Sharing Policy allows individual users to make calendar sharing invitations to users of other Federated orgs at only the most basic level of detail (free/busy only). Users will need Outlook 2010 or OWA to set up sharing.
  • The Exchange admin can then modify that Sharing Policy, or create an additional Sharing Policy, to allow more detail to be shared. The admin can apply that more detail-visible policy to all users in the org, certain subsets of users, or even just specific users.
  • The admin can also disable the Default Sharing Policy altogether so users without an explicit policy assigned cannot share their calendar at any level of detail.
  • To configure these Sharing Policies, Online tenant admins will need to use Remote PowerShell, while there is EMC support for on-premises admins.
  • More information about configuring Sharing Policies can be found on this TechNet article.
• Instructions for how enabled users can do Federated Calendar Sharing are available for those using Outlook Web App and Outlook 2010.
• Another option the admin has is to create an org-org relationship with another Federated org. That relationship allows the free/busy information for every user to be available to the other Federated org without the need for individual users to make a sharing invitation of any kind. The admin can also choose the level of free/busy detail shown when defining that org-org relationship. More information about configuring org-org relationships can be found on this TechNet article.
• A comparison between Sharing Policies and org-org relationships can be found on this TechNet article. Within the scope of admin-defined Sharing Policies, org-org relationships, or both, users can always individually choose to limit the detail of their sharing further.
• Some customers wonder how much information about them and their users the Microsoft Federation Gateway stores. The gateway only keeps track of the organization IDs and domains for which those orgs have proven ownership. It does not keep track of users or what free/busy requests they have made.

Can an Exchange Online (Office 365) customer establish Federated Calendar Sharing with another Exchange Online customer, as well as a third customer who is running on-premises Exchange Server 2010 SP1?

• Yes. An Exchange Online (Office 365) customer can set up Federated Calendar Sharing with other Exchange Online organizations, in addition to Exchange 2010 SP1 on-premises orgs. More information about Federated Calendar Sharing specifically between Office 365 customers can be found at this help.outlook.com article.

How does setting up Internet Calendar Publishing differ for Online vs. on-premises?

• For both Exchange 2010 SP1 and Exchange Online (Office 365), it is important to remember that no data can be published until the admin has set the sharing policy.
• Steps for enabling Internet Calendar Publishing can be found on this TechNet article. It is important to note that for Online tenant admins, configuring the Web proxy URL for the Mailbox server, and running the cmdlet which enables calendar publishing and turns on the calendar virtual directory, have both been done in the datacenter already.
• Instructions for how enabled users can publish their calendars to the internet are available for those using Outlook Web App. Outlook 2010 uses the Autodiscover service to light up a publishing option for its Exchange users (besides publishing to Office.com or a WebDAV server). On the Home tab, in the Share group, Outlook 2010 users can click "Publish this Calendar," which will redirect them to Outlook Web App to complete the publishing process. On-premises and tenant admins can publish a calendar for a user using PowerShell, using the cmdlet set-mailboxcalendarfolder and associated parameters. The user must have a Sharing Policy assigned that allows publishing.

When Federated Sharing is set up between Exchange 2010 SP1/Exchange Online (Office 365) organizations, will that include Federated GAL?

• While Federated Sharing between two Exchange 2010 SP1/Exchange Online (Office 365) organizations can allow the sharing of an individual user's calendar folders (as well as contact folders), Federated GAL sharing between the two orgs is not possible whether they are Online or on-premises.
• For customers wishing to share GAL information between on-premises Exchange organizations, they can use a tool like Microsoft Forefront Identity Manager 2010 to enable custom syncing between orgs. For Office 365 customers, the Directory Synchronization (DirSync) tool maintains unified GAL between users on-premises and in the cloud.

In Exchange Online (Office 365), is an org-org relationship required between two organizations which wish to enable Federated Calendar Sharing?

• An org-org relationship is not required between Exchange Online (Office 365) customers who wish to enable Federated Calendar Sharing.
• Trust with the Microsoft Federation Gateway is automatically established for Exchange Online (Office 365) orgs, so upon sign-up for the service, the Default Sharing Policy allows individual users of Online orgs to invite users of other Federated orgs to view/share their calendars at the most basic level of detail (free/busy only), without any administrator action. Users will need Outlook 2010 or OWA to set up sharing.
• Using Remote PowerShell, the tenant admin can modify that Sharing Policy, or create an additional Sharing Policy, to allow more detail to be shared. The admin can apply that more detail-visible policy to all users in the org, certain subsets of users, or even just specific users. The admin can also disable the Default Sharing Policy altogether so users without an explicit policy assigned cannot share their calendar at any level of detail. Visit TechNet for more details on disabling the Default Sharing Policy and creating a new Sharing Policy.
• An org-org relationship is required if the tenant admin wishes to allow free/busy information for every user in the Online org to be available to another Online org without the need for individual users to make a sharing invitation of any kind. The admin can again choose the level of free/busy detail shown when defining that org-org relationship.
• A comparison between Sharing Policies and org-org relationships can be found on this TechNet article. Within the scope of admin-defined Sharing Policies, org-org relationships, or both, users can always individually choose to limit the detail of their sharing further.

What (if any) calendar sharing or free/busy viewing capabilities do I get with federation through ADFS in Exchange 2010 SP1, vs. setting up Federated Trust with the Microsoft Federation Gateway?

• Federation through ADFS does not enable any type of calendar data exchange (neither full sharing nor free/busy viewing) between organizations, whether they are Exchange 2010 SP1 or older. ADFS only enables federated identity (and thereby single sign-on) across forests.
• Two organizations with trusted forests, federating through ADFS, wishing to allow free/busy viewing cross-org would need to use Add-AvailabilityAddressSpace objects to define the access method and associated credentials used to exchange free/busy data across their trusted forests (see TechNet article).
• Establishing Federated Trust with the Microsoft Federation Gateway is required to enable full Federated Calendar Sharing functionality. Federated Calendar Sharing does not require ADFS to enable any of its functionality, nor will having ADFS impact its functionality.

How can users in my Exchange organization share calendars with users in non-Exchange organizations?

• Internet Calendar Sharing might be an option for sharing between Exchange and non-Exchange organizations. If the non-Exchange organization has the ability to publish calendars in iCalendar format, then Exchange 2010 SP1/Exchange Online (Office 365) users can consume them (and publish their own reciprocally). This includes cloud users on Windows Live, Yahoo, and Google. Also an individual user of Outlook 2007 or 2010, whose calendar is not on an Exchange account, has the ability to publish their calendar to Office.com and can share it in that way (see more information).
• Exchange currently does not have a federation story with non-Exchange organizations, so Federated Calendar Sharing is not possible between Exchange and non-Exchange users.

Calendar Delegates: are there other folders that could get delegated?

• Calendar delegates work in Exchange 2010 SP1/Exchange Online (Office 365). Cross-premises delegates (e.g. where a manager is in the datacenter and the delegate is on-premises, or vice-versa) is not supported. Calendar delegates can only be set for your default calendar folder. Within Exchange 2010 SP1/Exchange Online (Office 365) you can grant other users editor (but not delegate) permissions to secondary calendar folders.

How can two different Exchange organizations (Org A and Org B) enable Full Calendar Sharing or org-org Free/Busy viewing?

• Please visit the Exchange Team Blog Files to review a calendar sharing matrix with requirements for calendar data exchange two different organizations.

For Office 365 organizations in a hybrid Exchange deployment (some users on-premises, some users in Exchange Online), what Free/Busy viewing and Calendar sharing options are available?

• Please visit the Exchange Team Blog Files to review a calendar sharing matrix with requirements for an organization in a hybrid deployment.