Planning Office 365 Internet (Anonymous) and Federated (Authenticated) Calendar Sharing

    This post has matured and its content may no longer be relevant beyond historical reference. To see the most current information on a given topic, click on the associated category or tag.

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

    Read the whole article @> Exchange 2010 SP1 and Exchange Online (Office 365) Calendaring FAQ - Exchange Team Blog - Site Home - TechNet Blogs