Set up Federated Free/Busy and Calendar Sharing between Exchange 2010 SP1 and Outlook Live
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-premise 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-Premise 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) and if there’s any interest I’m also happy to cover using a single autodiscover service as well. But for now, I’m focusing on the user experience with free/busy and calendar sharing.
One of the areas might expect to 
“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 ust gets unfriendly error messages and “permission denied” errors. To get this up and running in Exchange 2010 SP1 is actually now pretty simple. No expensive certificates required from a handful of providers – you can use a self-signed certificate and it’s easy enough to get up and running with in less than an hour. In this article, I’m going to show you how…
Pre-requisites
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-Premise 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-premise and Outlook Live (I’m testing getting shared working – follow up article to come)
-
Exchange 2010 CAS Connectivity to *.outlook.com
-
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.
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-premise 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 Premise: contoso.astonuniversity.net
Outlook Live: live.contoso.astonuniversity.net
Basically we need to create three things on-premise – A Federation Trust to authenticate us against the MS Federation Gateway, then an Organization Relationship to say Outlook Live can see in for Free busy, and 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 Premise Config
Step One – Setup a New Federation Trust using a self – signed certificate
First you need to make a new certificate. Create one using the following command:
Note down the Thumbprint in the output, and then create the Federation Trust using that thumbprint value. Note that we’re manually setting the MetaDataURL. This is why we can’t do it in the Exchange Management Console – SP1 by default works against a new “Business” gateway. Outlook Live currently works against a legacy “Consumer” gateway and the URL below switches us to use that one.
Next, we need to setup a record in DNS that will be used to verify we own the domain and allocate us an ApplicationID for our domain.
Copy “Proof” entry that is output, and get ready to enter it into DNS (BTW the DnsRecord syntax will be wrong, just ignore it)
If you use Windows DNS, it goes a little something like this:
And if it’s Unix:
Once that’s 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:
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 use the Set-FederatedOrganizationIdentifier command:
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.
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.
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:
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 Outlook.com 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 outlook.com 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:
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:
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 “contoso.astonuniversity.net” and Outlook Live “live.contoso.astonuniversity.net”, I’ve created test accounts in each –“onpremise@contoso.astonuniversity.net” and “outlooklive@live.contoso.astonuniversity.net”. 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.
Managing iCal Calendar Sharing with Exchange 2010 SP1 [Updated]
One of the new features available in Exchange 2010 SP1 beta that I’m excited about (and already making use of) is the ability to share calendars from Exchange either in iCalendar or HTML format.
So – why is this useful? Doesn’t Exchange 2010 already have improved Calendar sharing with the new federated sharing features available from RTM? Well, yes it does.. And this new features doesn’t replace federated sharing, however if you want to share calendars now is that the world doesn’t run Exchange 2010. Some organisations will move to it over the next year or two; but lets face facts – some enterprises out there may move to Google Apps, Zimbra or something else, so Federated Sharing isn’t going to be an option. While a workaround might be to create partner mailboxes or use third party software, it would be nice to have a solution that “just works” and enables the business to collaborate with partners easily without worrying too much about what technology each other uses. Only with open standards can this happen and with SP1 that’s now a reality.
The ability to publish calendars with anonymous viewers (and that’s an important point, which I’ll come back to) means that should the admin enable it, the user can now go in via OWA, select the calendar they wish to share and choose to publish it. They then receive a set of URLs that they can share via email. The recipient then can simply refer to the calendar via a web browser, or by using any iCalendar compliant software or web app they can subscribe to the shared Calendar.
Getting back to the anonymous part, there are two options. The end user can publish a calendar with a “public” URL that is searchable. The other option is a “restricted” URL with an obfuscated URL. Additionally, the user can restrict what will be shown for each calendar they choose to publish. On top of this, the admin can restrict via sharing policies the maximum amount of information users can publish, and sharing policies can be tied to a certain set of users. So there is some risk in enabling the facility, but by default no user’s calendars are shared, and there are a number of controls available to user and admin to pull the feature in line with the business and individual user’s requirements.
Now you know a little more about the new feature, let’s take a look at how it comes together from a user perspective, and how it’s configured by the admin.
The User Experience
If a feature is going to work well it has to be easy for a user to find and configure. Exchange 2010 SP1 doesn’t disappoint as the feature is listed in both OWA and Outlook in the same place as other calendar sharing options.
For an OWA user, they select the calendar they want to share, then choose “Share”, and the option is listed as “Publish This Calendar…”
If they’re using Outlook 2010 (beta ), the user right clicks the calendar they want to share, chooses “Share” and again, it’s listed as “Publish This Calendar…”
After clicking “Publish This Calendar…” via OWA or Outlook, the options can be chosen including the detail to show, the date range and the type of access:
After clicking “Start Publishing”, the links are generated:
The user can now either copy the links from this page, or via “Share” choose “Send Links to This Calendar…” which opens a new email with the two URLs attached.
Opening the calendar by the recipient is easy enough. For our first example, let’s have a look at Exchange’s primary competitor, Google Apps. To add the shared calendar to Google Calendar, the end user chooses “Add” then “Add by URL”.
They pop in the iCalendar URL, and it shows up in the recipients Google Calendar. You’ll see below I’m subscribing to two Exchange 2010 SP1 calendars – my personal one and my team’s:
(In my case – this is one aspect I personally like about the feature. Although I don’t use Google Calendar I do use iGoogle and it allows me to see my Exchange calendars on my homepage via the Google Calendar widget.)
Next up it’s Zimba. Add a new Calendar, choose Synchronise appointments from remote calendar, then pop in the Exchange iCalendar URL:
Again, the Calendars show perfectly:
Finally let’s not forget Outlook users; from Outlook 2007 onwards iCalendar subscriptions are supported. I’ve quickly tried this in Outlook 2010 beta – simple right click in the calendar list, choose “Add Calendar” and then select “From Internet…”
As above, after popping the iCalendar URLs in the subscriptions are created in the local Outlook client.
And, finally let’s not forget HTML sharing, which does exactly what you’d expect:
The Admin Experience
Now you’ve seen the user experience let’s take a look at what needs to be done to get it up and running in your SP1 environment. To get it all enabled we need to do the following:
- Set an ExternalURL for your organisation’s Client Access Server
- Enable Calendar Publishing on the OWA Virtual Directory
- Create or modify the sharing policy to allow anonymous sharing
Setup of the ExternalURL is pretty standard stuff so I won’t cover it here. Moving on to the Calendar Publishing OWA virtual directory feature, let’s look at what it’s made up of.
The Calendar Publishing works via a new virtual directory – “calendar”. This lives beneath the “owa” virtual directory as “/owa/calendar” and has anonymous, http access enabled (watch out ISA/TMG users). It’s enabled by default but should it need re-enabling it’s pretty straightforward using Powershell. Here’s a quick example:
Set-OWAVirtualDirectory "owa (Default Web Site)" –CalendarPublishingEnabled:$true
Next up, a sharing policy needs to be configured to allow anonymous access. You can do this via EMS or via the EMC. The EMS example below changes the Default Sharing Policy to only allow anonymous access with maximum access level of Calendar Sharing with Free/Busy plus Subject, Location and Body.
Set-SharingPolicy -Identity "Default Sharing Policy" -Domains "Anonymous:CalendarSharingFreeBusyReviewer"
Via the EMC is also pretty straightforward and particularly suitable when you need to create multiple policies or modify existing ones. Here’s a quick run through of how to create a new policy via EMC that only applies to certain users:
Open EMC and navigate to the Organizational Configuration node, then to Mailbox and select the Sharing Policies tab:
First, examine the sharing policies already present. In the above screenshot, I’ve got a single sharing policy which is disabled. As we’re adding a new policy right-click in the white space or click “New Sharing Policy…” on the actions pane. Give the policy a name and add a new “domain” called “Anonymous” and select an appropriate maximum level of access:
After you’ve added the “domain” anonymous to the policy, make sure it’s enabled, then press Next. On the next page you’ll be presented with the opportunity to add mailboxes now. You can of course add these later either via the EMC or via EMS:
Press Next, then after confirming the details, press New. After completion you’ll see a warning that lets you know calendar publishing is enabled for this policy:
Press Finish and we’re all done. You should now be able to login to the specific mailbox and following the first part of the article share the Calendar.
Conclusion
We’ve had a look at what the new feature brings both from an end-user experience and to an administrator. As we can seen it’s great for sharing calendars in an environment where open standards are important or where partners use different products. I’d like to see full WebDAV compatibility so a Linux user can plug straight in and go, but this is a great start as far as sharing is concerned.
Getting back to new shared calendar features in SP1 - I’m hoping more can be revealed over the next few weeks as there’s still a bit more in store! 
And of course, you’ll be able to get your hands on this yourself early June.
A final thought – bear in mind all the features and steps described here are not necessarily final so don’t be surprised if things change over the next few months.
Steve
