Set up Federated Free/Busy and Calendar Sharing between Exchange 2010 SP1 and Outlook Live [Updated]

imagePLEASE NOTE: This is NO LONGER supported and provided as-is for information ONLY. The information here relates to pre-Hybrid configurations that used the Consumer MFG. It does give you some background as to how Office 365 does Federation, though some steps have changed. For a modern “under the hood”, see this article.

As organizations move to make use of cloud based services, like Exchange Online or Outlook Live, it’s pretty important to be able to integrate both the on-premises service and the cloud service so that end-users can continue to work as normal. That’s especially important with a service like Outlook Live, aimed at Education institutions, where typically staff, faculty and some students will continue to be hosted on-premise and the majority of students will be hosted in the cloud. A seamless experience makes life easier for users and thus easier for IT…

So, with Outlook Live and Exchange 2010 On-Premises there is a pretty good opportunity to get Exchange working seamlessly between both systems. I’ll be covering a unified login in a further article (once I’ve re-written the code we use in-house into a re-distributable form). But for now, I’m focusing on the user experience with free/busy and calendar sharing.

One of the areas users might expect to image“just work” is free/busy and calendar sharing between on-premise and cloud. The options are there, it looks like it tries to do it.. But the end user just gets unfriendly error messages and “permission denied” errors. To get this up and running in Exchange 2010 SP1 is actually now pretty simple. Although SP1 allows self-signed certificates for Federation, you cannot use these with Outlook Live federation, and you’ll need to perform an extra step. However it’s still fairly straightforward…


First things first, we need a few things in-place and working already before we can get going. The main pre-req is Autodiscover, but I won’t cover how to set this up, as it’s is covered in detail elsewhere on the good old ‘net..

  • Autodiscover working for On-Premises for the domain you want to use (using DNS names, not a service records)
  • Autodiscover working for Outlook Live for the domain you want to use (again, using DNS names, not a service record)
  • Separate domains for on-premises and Outlook Live (I’m testing getting shared working – follow up article to come)
  • Exchange 2010 CAS Connectivity to *
  • Org admin rights on Exchange 2010 SP1 and Tenant Admin rights on Outlook Live, along with Powershell access to both.
  • Access to manage the DNS for both domains and add TXT records.
  • External URL setup and tested for Exchange Web Services / WebServicesVirtualDirectory

Once that’s all setup and available, you should be ready to go..

Setting it up

To keep things simple, we’re not going to do anything too complicated, we’re going to set things up so all users in both on-premises and Outlook Live can see each other’s free/busy and share calendars (and contacts). Also, for the purposes of this article it’s assumed no Sharing Policy is setup already.

On our test setup, we’ve got two domains:

On Premises:
Outlook Live:

Basically we need to create four things on-premise:

  • A Federation Trust to authenticate us against the MS Federation Gateway
  • A new sub-domain ExchangeDelegation for the account namespace (in this example,
  • An Organization Relationship to say Outlook Live can see in for Free busy
  • Finally a Sharing Policy to allow on-premise users to share their calendars with Outlook Live users.

In Outlook Live the trust with MS’s Federation Gateway is there by default so we just need the Organization Relationship to allow On-premise to see in and the Sharing Policy to allow the Outlook Live users to share with On-premise users.

First, we’ll setup the on-premise config, then get the Outlook Live stuff done. Afterwards we’ll test everything works.

On Premises Config

Step One – Setup a New Federation Trust using a trusted certificate [Updated 10th Nov 2010]

To setup a Federation Trust for use with Outlook Live, you need to use a certificate from an approved certificate authority. As this list is quite short, you may find it doesn’t include you current SAN/UCC certificate provider (for example, if you use the JANET Certificate Service), however this isn’t a major issue. The certificate you use for Federation doesn’t have to be the same one you currently use for your other Exchange services, so fear not – you don’t need to buy a new, expensive SAN/UCC certificate. I’ve found the cheapest one from GoDaddy works just fine.

If you’ve already got a supported certificate, you can skip this part and just use your existing certificate thumbprint for the New-FederationTrust command. Otherwise, to generate a new request for a single domain certificate just to use for Federation, use New-ExchangeCertificate:

New-ExchangeCertificate -GenerateRequest -SubjectName ',' -DomainName -FriendlyName 'Third Party Federation Certificate' -PrivateKeyExportable $true


Next, follow the standard process for your CA, by requesting, then downloading the certificate from the third party certificate provider:


After downloading the certificate, you now need to complete the certificate request by importing the certificate into Exchange:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\cert\certificate.crt -Encoding byte -ReadCount 0))


Note down the Thumbprint in the output, and then create the Federation Trust using that thumbprint value. Note that we’re choosing the “Legacy Provisioning Service” as part of this process. This is why we can’t use a self-signed request – these only work against a new “Business” gateway. Outlook Live currently works against a legacy “Consumer” gateway and the -UseLegacyProvisioningService parameter switches us to use that one.

New-FederationTrust -Name 'Microsoft Federation Gateway' -Thumbprint 'thumbprint' –UseLegacyProvisioningService


NB.. You’ll see in that example above I got an error the first time. This does happen occasionally and I’ve seen it reported in forums too. The error is “The request failed with HTTP status 403: Forbidden”. Just retrying the command should work.

Next, we need to setup a record in DNS for the application ID using the ExchangeDelegation sub-domain and the main On-Premises domain we wish to use for federation. As of SP1, it’s possible to use the “Federated Domain Proof” DNS TXT record, but as we’re using the legacy method, we will use the Application ID method.

To add the App ID, you need to add a DNS record that contains your Application ID (shown as “ApplicationIdentifier” in the output from “New-FederationTrust”, or by entering “Get-FederationTrust”) and enter it in the form “AppID=”.

If you use Windows DNS, it goes a little something like this:

image image imageimage

Once those are both in, reload/HUP your DNS and make sure you can resolve it, both from your Exchange servers and from the outside world. The following command should work:

nslookup -querytype=TXT
nslookup -querytype=TXT


Now we’ve got the Federated Trust and DNS record sorted, we can get ourselves properly setup with the Federated Gateway. To do this, we first need to add the accepted domain of the Federated namespace:

New-AcceptedDomain -Name 'Federated Namespace' -DomainName '' -DomainType 'Authoritative'


Next, we first use the Set-FederatedOrganizationIdentifier command to configure the account namespace:

Set-FederatedOrganizationIdentifier -DelegationFederationTrust 'Microsoft Federation Gateway' -AccountNamespace -Enabled:$true

Finally, add the main domain name of the On Premises domain:

Add-FederatedDomain -DomainName ''

Assuming that completes successfully, we can move onto the next step..

Step Two– Setup the On-Premise Organization Relationship

The next step is to allow our Outlook Live domain to see our On-premise Free/Busy info. You can do this via Powershell or the Exchange Management Console:

Via Powershell:

Test that you can get the federation info for your Outlook Live domain. If you get an error, run the command again with the -Verbose parameter for a detailed error and check your autodiscover setup for Outlook Live:



Next, configure the relationship. The LimitedDetails option below is the most open setting for the relationship, which means any user who has chosen to show that much detail will also make it available to the Outlook Live tenant.

Get-FederationInformation | New-OrganizationRelationship -Name "Outlook Live" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel:LimitedDetails


If you’d rather configure via Exchange Management Console:

Navigate to Organization Configuration, and select the Organization Relationships Tab. Right click in the whitespace and choose “New Organization Relationship”:


in the New Organization Relationship window, Give a the new relationship a friendly name (e.g. Outlook Live). Select the checkbok “Enable this organization relationship”, then choose to enable free/busy access. Choose “Free/busy access with time, plus subject and location” to select the widest access. This means any user who has chosen to show that much detail (i.e. people can see that on-premise right now) will also share it to Outlook Live.


Next enter the Outlook Live domain in the Automatically discover configuration information text box, and press Next.


Check for any errors, and press Finish. If there are errors, and it isn’t a typo, then it’s likely to be an Autodiscover issue – but you’ll find out most detail on the possible cause if you use the Powershell instructions above.


The new relationship should now be listed underneath Organization Relationships:


Step 3 – Setup the Sharing Policy

To enable our on-premise users to share their information with Outlook Live users we need a sharing policy setup. While you can setup multiple sharing policies and assign them to different users, for this basic sharing we’re going to modify the default sharing policy

Via Powershell:

First, check your settings. Note down the existing Domains value.

Get-SharingPolicy 'Default Sharing Policy'


Replace the domains value on the Default Sharing Policy setting the original value (or remove it, if you want) and adding the Outlook Live domain. For the Outlook Live domain we’re setting the maximum scope for sharing:

Set-SharingPolicy 'Default Sharing Policy' –Domains '*:CalendarSharingFreeBusySimple', ', ContactsSharing'

If you’d prefer to configure the sharing policy via the Exchange Management Console:

Navigate to Organization Configuration > Mailbox > Sharing Policies, then right click the Default Sharing Policy, then choose Properties:


In the Default Sharing Policy Properties, choose “Add”, then specify the Outlook Live domain. To allow for the maxium level of detail to be shared by individual users, select the last option “Calendar sharing with free/busy information plus subject, location and body, Contacts sharing:


And that’s it for On-Premise. Next.. We need to get the hosted environment setup with with the corresponding parameters:

Outlook Live Setup

For the Outlook Live setup you have to use Powershell – Exchange Management Shell isn’t supported when managing your hosted tenant. If you’re not sure how to connect Powershell see the guide on the help site, but it basically looks a little like this:


Step 1: Setup the Outlook Live Organization Relationship

We get to miss out the first step that we had to do on-premise, setup of the federation trust, because as a tenant of the Exchange environment this has already in place.. So we can skip to getting an organization relationship setup with our on-premise domain.

First, we check that we can indeed discover the correct settings by using the Get-FederationInformation command, specifying the on-premise domain:



The output from the command should show details matching the Organization Identifier and Application URI we setup earlier, along with the details of the on-premise Autodiscover environment.

If it returns a failure you may need to double check your Autodiscover settings for the on-premise environment, or in some cases you may need to give it a little while (if you just setup your Federation Trust on-premise) and try again. For example, in my production environment it took around an hour for my production Outlook Live tenant to be able to discover the Federation Information although my test domains could see the same information without any issues.

So.. After you’ve tested Outlook Live can discover the Federation Information, it’s onto actually creating the Organization Relationship. The command is exactly the same as on-premise,we are really just swapping the domain:

Get-FederationInformation | New-OrganizationRelationship -Name "On-Premise" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel:LimitedDetails


Step 2: Setup the sharing policy

Finally, it’s on to the final step – getting the sharing policy sorted. Check out what the Default Sharing Policy currently is before we go and add our on-premise domain:



Then replace the Domains list for the Default Sharing Policy with a value that includes the on-premise domain. In the example below, I’m keeping the settings that were already there and adding the on-premise domain. For consistency, I’m also keeping the same sharing level as set on-premise:

Set-SharingPolicy 'Default Sharing Policy' -Domains '*:CalendarSharingFreeBusySimple', ', ContactsSharing'

After that, it should all be done. Give it a little bit of time (say, 15 minutes) for everything to take effect and we should be ready to have a play..

Testing it out

For testing purposes on my two domains, on-premise “” and Outlook Live “”, I’ve created test accounts in each –“” and “”. For the screenshots I’ve used OWA, but it works equally well in Outlook.

The first test is for Free/Busy. I’ve created a few test appointments in both calendars and you’ll see availability works just as if the user was on-premise:

In Outlook Live, scheduling a new meeting with the on-premise user as an attendee:


Next, via on-premise Exchange 2010 SP1, with our Outlook Live user as an attendee this time:


The second test is to check it is possible to share a calendar either way, and this is where it strays slightly away from the full range of options available to users within a single environment.

The limitations we’ve got mean that the user must share the calendar using OWA or Outlook 2010, and must use the “share this calendar” options rather than setting permissions directly. The recipient of the permission must add the calendar using the resulting email (they can’t just add it by name) and it’s read-only. this of course means the process can’t be easily automated, but it does allow users to use a common workflow to share folders, via the “share” options.

Sharing a calendar in Outlook Live:



On-premise user receives the sharing invitation and chooses “Add this calendar” to add it:


After adding the calendar, it’s shown in red (in OWA, anyway) while the server retrieves the calendar:


After a minute or so, the Outlook Live calendar shows up alongside the On-premise calendar:


Finally, let’s test it from On-premise to Outlook Live:

Select the Calendar’s “Share” option to share the calendar (it’s worth noting that the OWA UI has changed between RTM and SP1.. but I digress):



Over in Outlook Live, the Outlook Live user receives the invitation and again, chooses the “Add this calendar” link:


After choosing to add the calendar, the on-premise calendar shows (again after a minute or so to do the first sync) alongside the Outlook Live calendar:


Contacts sharing is again a similar process, although it must be shared using Outlook 2010. Simply right click a contacts folder and choose Share>Share Contacts:


And that’s it – hopefully this will work for you, but if you have any questions or any issues, just use the comments form below.

Update – 10th November 2010: The original article used the -MetaDataURL parameter to use a self-signed certificate with the old “consumer” gateway. This is no longer valid. The article has been updated to reflect the new process, which requires an acceptable third-party certificate and the -LegacyProvisioningService parameter. If you have used the -MetaDataURL parameter to setup Federated Sharing you should remove and re-create both the organizational relationship (both sides) and the federation trust (on premises) using the updated information in “Step 1” of the On Premises Config. You do not need to remove/re-create the sharing policy.

Update – 15th December 2010: The article has been updated to use for the Federated Namespace based on advise from the Exchange team. This is a best practise and pre-req for cross-premises Free/Busy.

40 thoughts on “Set up Federated Free/Busy and Calendar Sharing between Exchange 2010 SP1 and Outlook Live [Updated]

  1. Pingback: Federate Exchange and Exchange Online for Calendar Sharing | ODDYTEE

  2. Pingback: Godaddy Setup Outlook 2003 – Times Info

  3. Pingback: Federated Calendar Sharing error 5039 and 5037 | Catapult Systems

  4. Pingback: When running the Hybrid Configuration Wizard in Exchange 2010 SP3 UR1, the Domain Proof of Ownership is not populated | Steve Goodman's Exchange Blog

  5. Steve, we followed your steps here to get calendar sharing working in our organization last year. Now we’re ready to initiate the upgrade to O365. Is this the same Federated setup that will be replacing the SSO toolkit in December 2014? Am I still using the SSO toolkit if this federation is in place? Just a little confused by the “federation” terminology because I know we have it setup for calendar sharing, but not sure if there’s more that has to be done. Hope I’m clear enough. Thanks for all your great advice. ~Jason

    • Hiya sorry for the delay in replying.

      No it’s not the same SSO toolkit federation or certificates and should work entirely independently, post update to Office 365 though I would probably recommend you removed this federation and moved to a standard Hybrid Config. That’s what I’ve done for seem customers.

  6. Pingback: IT Team - Federated Calendar Sharing error 5039 and 5037

  7. Is there a way to set the sync interval for calendars between two federated organizations? I am noticing that the calendar sync between two organizations is very slow. It looks like calendars are synced every hour or so.

  8. Pingback: Configure Microsoft Exchange Server 2010 SP2 with Microsoft Federation Gateway | Exchange Blog

  9. Pingback: Configure Federated Delegation in the Cloud –Establishing Federation with other Exchange Online Tenants | msryanph

  10. Also shouldn’t your command
    Set-SharingPolicy ‘Default Sharing Policy’ -Domains ‘*:CalendarSharingFreeBusySimple’, ‘, ContactsSharing’

    be instead of The EMC screenshots suggest it should but since I’m having problems I just wanted to make sure I’m not miss understanding something.

  11. Thanks for the article. Couple of questions. First of in the images (image171.jpg, image173.jpg, and image174.jpg) it says but your powershell commands say I for whatever reason created it as ExchangeFederation so I assume that as long as I stick with that I just need to edit your powershell commands?

    Next when I issue the nslookup -querytype=TXT for my root domain I get what I think is the SPF information. Rather than the AppID… assuming that’s not a problem I moved on , but when I get to the Add-Federation command I get an UnableToReserveUriException error:

    Unable to reserve the URI “” for the domain “” on application identifier “000000004808C008”. Detailed
    information: “An error occurred accessing Windows Live. Detailed information: “Unexpected Internal Error”.”.
    + CategoryInfo : InvalidResult: (:) [Add-FederatedDomain], UnableToReserveUriException
    + FullyQualifiedErrorId : ABFAC6FC,Microsoft.Exchange.Management.SystemConfigurationTasks.AddFederatedDomain

    is that because it’s not getting the AppID first?

    Thanks in advance.

  12. Pingback: Room and Equipment handling using MS-Exchange Resource Mailboxes: Sharing Resource Calendars with Students in Outlook Live « Thomas' Work Space

  13. Great blog; great article. Will this also work if we are still at Exchange 2007 for on-premises? Our migration to 2010 is still many months away…..

  14. Hi, one short questions. Does this support also if the on-premises would be in another forest than users where all the O365 configuratio has done (ADFS, DIR Sync) –> User migrated from resource domain to cloud must see non-migrated users calendar and F/B information
    Otherwise, good document Thanks.

  15. Pingback: Reader’s Problems: Can’t send a Calendar sharing message | Steve Goodman's Exchange Blog

  16. Steve,
    I enjoyed the article. I have been looking around to find some information on whether or not having the contacts pre-existing in the Directory would cause issues. AD was populated with contact records including SMTP. In reading all the articles i only find mention of the user having to enter a SMTP address to resolve the free busy query. In the end I am curious if the free/busy look up will work by selecting the contact we already have populated? Thanks in advance for your time and any response you may have.

    Jonathan Smith

    • Hi Jonathan,

      It should still work if you have contacts – I know that for Mail Users it still works fine and uses the targetAddress / ExternalEmailAddress attribute when resolving the final SMTP address to use for the lookup, my example is for that scenario where the GALs are synced using ILM.


  17. Pingback: Exchange 2010 Federation - yuval14

  18. Pingback: Free/Busy between Office 365 tenants | Explore the BPOSsibility - by Paradyne

  19. We have just moved to Exchange 2010 SP1 for our faculty and staff. Our MX records reside at FOPE and our Outlook Live domain is actually but we hide that by making mail enabled users in our domain, It appears that people are mailing but the mail ends up at What do I need to change in this setup for SP1, and anything for the problem with the domains appearing the same.


    Rick Clark

  20. Pingback: Want to setup exchange 2010 federation « Ucirl's Blog

  21. >>> New-FederationTrust -Name ‘Microsoft Federation Gateway’ -Thumbprint ‘thumbprint’ –metadataurl

    Please do NOT use the parameter -metadataurl. That is no longer valid when SP1 RTM. If you need to talk to Outlook Live for federation, remove the -metadataurl switch, but add -UseLegacyProvisioningService. The thumprint will need to be a third party cert trusted by the federation gateway.

  22. Hey Steve, did you ever get this working for a shared domain?

    We’ve got the following setup:

    primary Domain:
    Accepted domain, shared with on premise and used in all live IDs:
    Other accepted domains, such as

    On premise: 2010 SP1 + 2003
    -Live users are mail enabled users with target addresses of
    -Mailboxes can have serveral different primary SMTP addresses, but most are, and then
    -authoritivate for accepted domain:, primary domain is

    Thanks for any advice you have for us!

    • Hi Paul,

      Yes it works with shared domains – though on premises you need a unique domain to register.

      For discovery it uses targetAddress so On Premises users can share/discover out of the box; however the mail-users in Outlook live that represent the On Premises users need to have targetAddresses of that unique on premise domain (and therefore mail routing).

      I’ve put on hold a follow-up blog post for this, as with Office 365 for Education around the corner, which I believe will use the “business” instance of the Federation Gateway, things will change again.


  23. That seems really simple, and I love the screen shots but I am having trouble getting past:

    PS U:\> get-federationinformation
    Federation information could not be received from the external organization.
    + CategoryInfo : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
    + FullyQualifiedErrorId : AAEA5515,Microsoft.Exchange.Management.SystemConfigurationTasks.GetFederationInformation

    Do you have any ideas?

  24. Pingback: Office 365 – What does it mean for Exchange? | Steve Goodman's Tech Blog

  25. Pingback: Set up Federated Free/Busy and Calendar Sharing between Exchange 2010 SP1 and Outlook Live | Steve Goodman’s Tech Blog « JC’s Blog-O-Gibberish

  26. Pingback: How to setup Exchange 2010 Federation | windows server howto

  27. FAIL! I am running a shared namespace (now legacy, but I need to migrate the 55 students from my pilot off of it) with Outlook Live. When I get to Set-FederatedOrganizationIdentifier it fails w/ the error Unable to reserve domain “” for Application Identifier “000000004C035100”. Detailed information: “Windows Live returned a domain reservation error. Detailed information “DomainUnavailable: The specified domain is not available.”.”

    That’s what I get for not reading the pre-reqs carefully enough. I look forward to your article discussing it if you can make it work. In the meantime, I guess its back to preparing for the influx of students tomorrow. 🙂

    Thanks again for the fantastic articles.

      • Sorry, wrong type of legacy, I think.

        My on-premise namespace is
        My Live@EDU primary namespace is but I set up the shared namespace of and deployed (a pilot group of) students for a year.

        After realizing how kludgy it seemed, I decided all students going forward will receive a new, namespace so we don’t need to create on-premise accounts, keep them synchronized during their tenure and then maintain an eternally increasing quantity of them.

        From my rough understand I think I’m going to need to deprecate the use of within Outlook Live before I can complete my federation?

        • Hi Jeremy,

          No that was the type of Legacy I meant.

          IIRC there is a SiteID assigned in Windows Live to each domain. This is used with SSO so if it’s removed SSO won’t work.

          I’ll pop you an email rather than reply in the comments to check some info then see if I can find out for certain what the options are.

          Currently I have a shared namespace (which works well) for my org and use SSO so I’m looking for a more complicated workaround but hopefully there is a more simple option for you.


          • Hello,
            For you to do namespace sharing, you actually want to register “” as the accountname space in federation trust at on-premise. This will free up for you in Outlook Live tto do name space sharing. Once you register, THEN you can add as additional federated domain. As long as isn’t the Account Namepsace, the domain will be available for share namespace. I’ve email to Steve earlier about this solution. thanks.

  28. Pingback: Tweets that mention Set up Federated Free/Busy and Calendar Sharing between Exchange 2010 SP1 and Outlook Live « Steve Goodman's Tech Blog – The weblog of an IT pro specialising in Exchange, Exchange, VMware, Servers and Storage --

Comments are closed.