I was asked this by a university in the Midwest with 18 unique Exchange organizations. They wanted to share calendar information amongst the Exchange orgs. (Most diagrams courtesy of Exchange Product team)
What are the benefits of Exchange 2010 Federated Sharing?
- Easy setup of external data sharing
- Broader reach without additional steps to setup
- More secure with controls for admins and users
Exchange Federated Sharing is convenient
- Sharing between two orgs or two people
- No trusts or service accounts
- No end user accounts and credential prompts
Exchange Federated Sharing is secure
- Control which orgs you share with
- Control which users can share and at what level
Exchange Federated Sharing works with online services
What are my choices for calendar federation?
There are two levels of calendar federation available:
- Exchange organization to Exchange organization calendar sharing (diagram below) – administrators can specify what level of default calendar view permissions on a org by org basis (e.g. just free/busy or just limited calendar detail)
- Individual to Individual level of calendar sharing where the user can determine how to share the their calendar across organizations if additional detail needed beyond Free/busy sharing. Note: level of sharing can be controlled by admins via sharing policy (diagram below)
Can I control how my org’s calendar info is shared info per external domain (external org), department or users share calendar information externally?
Yes, by using org level relationship controls or by using a Sharing Policy.
Example of org level relationship sharing controls:
Find information about external org:
Create a new org relationship:
Create what level of calendar sharing allowed with external org:
Optional: set limits as to which department can share information:
More on Org relationships sharing here
Example of a sharing policy:
This is set via GUI or cmdlets. (More here)
How does Federated Sharing work?
It uses a combination of Exchange web services on the CAS server and a federation trust with the Microsoft Federation Gateway.
The nice part is you no longer need to setup directory synchronization like you did with Exchange 2007 nor do you need to setup Active Directory trusts or AD service accounts.
The Microsoft Federation Gateway acts a trust broker to allow for requests over SSL. No need to open RPC ports for AD trusts or share AD service accounts, etc.
What do I need to do to get it work?
Four things needed to get you started:
1) Obtain a X.509 certificate from a Trusted Root CA (GoDaddy, Entrust, etc) for use with Microsoft Federation Gateway (MFG) for signing and encrypting delegation tokens. (more here). Here is a list of Trusted Root CAs that MFG is aware of here.
2) Create a Federation Trust using cmdlet with the MFG (more here):
3) Provide domain ownership by creating a DNS TXT record similar to (more here):
Contoso.com IN TXT AppId = 1C2
4) Add your SMTP domains (other Exchange Orgs) and add Federated domains to trust calendar information with (other org must accept) using cmdlet (more here):
Set-FederatedOrganizationIdentifier – to enable your SMTP domains for federation sharing with the MFG
Add-FederatedDomain – to add other External Orgs to share calendar information with
Can I share my calendar with the Exchange Online and other Microsoft cloud services?
Yes, this is possible with cloud services like Azure today and will be possible with Exchange Online and Live@Edu (Outlook Live) by the end of Summer 2010.
For more specific details on the Federation process visit here.