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.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.One of the new features available in Exchange 2010 SP1 and higher (including SP2 and SP3) that I’m excited about (and already making use of) is the ability to share calendars from Exchange either in i Calendar or HTML format. Doesn’t Exchange 2010 already have improved Calendar sharing with the new federated sharing features available from RTM? And this new features doesn’t replace federated sharing, however if you want to share calendars 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.It’s enabled by default but should it need re-enabling it’s pretty straightforward using Powershell.
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.
The Calendar Publishing works via a new virtual directory – “calendar”.
This lives the “owa” virtual directory as “/owa/calendar” and has anonymous, http access enabled (watch out ISA/TMG users).
They pop in the i Calendar 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.