Information workers frequently need to collaborate with external recipients such as vendors, partners, and customers, and share their availability (free/busy) information, calendar, or contacts. So we speak about
1. Federated free/busy sharing
Access free/busy information of an external user in a partner’s company
2. Federated calendar sharing
Access calendar information of an external user in a partner’s company
3. Federated contact sharing
Access private contacts information of an external user in a partner’s company
In this first part I will give a high level overview about what Microsoft Exchange Server 2010 Federation services provide and what the limitations are.
If you and your partner’s organization uses Exchange 2010, Outlook 2010 or Outlook Web App 2010 you can access free/busy information and calendars as well as contacts of the partner’s organization users. This happens online and in a direct way. No data about the partner’s organization are stored in your Active Directory or on client machines. The User just inserts the mail address of the partner’s user he wants to get information from. If your user is offline or your or your partners company is not connected to the internet by https, it is not possible to get this information. If he does not know the mail address there is no way to get this from Federation.
To secure the access Microsoft provides an own underlying trust infrastructure which acts as trust broker. So every organization which takes part in the sharing has to publish a certificate to this Microsoft Federation Gateway which is placed in the cloud. Data which are sent over the internet are encrypted. Every time a user requests information from the partner’s organization first Exchange asks the Microsoft Federation Gateway to get a token for this session.
The implementation is made by IT-administration. They need to
1. Publish the Exchange web service to the internet (may be using a firewall like Microsoft ISA/TMG/UAG)
2. Publish a certificate to the Microsoft Federation Gateway. The user’s data itself are not send across this gateway.
3. Set up policies which users are allowed to share their information with your partner
There is nothing to do for end-users.
If you use Outlook 2007 your organization still needs the user objects of the partners organization replicated to your Active Directory, because there is no way to access the GAL of the partners organization directly.
If your organization uses Exchange 2007 you have to install at least one Exchange 2010 server to act as a proxy accessing the other organization.
Update: GALsync provides free/busy information to an Exchange 2010 / Outlook 2010 environment. For synchronizing addresses it works fine with Exchange 2003/2007/2010 and works with any client which is able to access the Global Address List.
Exchange 2010 Federation might be a solution to get access to free/busy, calendars and personal contacts of your partners organization if you
1. and your partner migrated fully to Exchange 2010
2. “open” your company to the internet by publishing a web service
3. trust the Microsoft Federation Gateway which holds your certificate and some small information about your company.
4. your users “know” already the mail-address of the people they want to communicate with
5. your users need this feature only if they are online
What the user has to know is the exact mail-address of the people he want to get information from (i.e. he wants to invite for a meeting).
GALsync may be a solution for you
1. if you cannot provide a web service to the internet (i.e. because of restrictions following companies security policies)
2. if you do not want to trust the Microsoft Federation Gateway
3. if you need to provide the partner’s mail-addresses in your own directory so people are able to work offline too or because they use Outlook 2003 or 2007
4. if your or your partners organization uses Exchange 2003 or Exchange 2007
5. if you might not want to have any kind of “trust” between your and your partner’s organization.
1. TechNet Webcast: Calendar Sharing and Federation in Microsoft Exchange Server 2010 (Level 300)
2. Exchange 2010 Federation Part I-III
3. “Microsoft Federation Gateway”