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

# Add Exchange 2007. If you'll always run from the Exchange Management Shell, you don't need the next line.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

# Exchange 2007 Commands Go Here - i.e.

Get-MailboxDatabase

# Unload Exchange 2007

Remove-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

# Create Remote Powershell session with Exchange 2010 - edit the server name in ConnetionUri

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exchange.contoso.com/powershell/ -Authentication Kerberos

Import-PSSession $Session

# Exchange 2010 Commands Go Here - i.e.

Get-MailboxDatabase

# Unload Exchange 2010

Remove-PSSession $Session

$LiveCred = New-Object System.Management.Automation.PSCredential "yourliveadmin@contoso.edu", (ConvertTo-SecureString "password" -AsPlainText -Force)

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue

<!-- Set ShowPerformanceConsole to "true" to show ECP's Perf Console: -->

    <add key="ShowPerformanceConsole" value="false" />