By Doron Offir - Google Apps Deployment Specialist
On April 2012, Google released a much awaited Calendar Interop tool allowing to share Free/Busy information between Google Apps and Microsoft Exchange 2007-2010 servers.
The tool was released with fairly good documentation which explains how to deploy the Free/Busy sharing between two systems. However, I found the documentation lacking some basic explanation on how the Calendar Interop tool works and I would like to add some info that might help clarifying it a bit.
Google Apps users querying Exchange's Free/Busy information
The Calender Interop using the Exchange Public Folder Schedule+ Free/Busy to query calendar events in Exchange Server and to provide them to Google Apps's users. This process can take some time (1-3 seconds usually) since for each query the service need to contact Exchange's EWS and ask for Free/Busy status.
Exchange Server querying Google Apps's Free/Busy information
Exchange Server uses a public folder to store the Free/Busy information of users in Google Apps and when the request from Exchange user will arise, the answer will be provided instantaneously simply because it's already resides in Exchange's public folder and there is no need to "travel" to Google Apps to bring the data.
The configuration documentation is pretty straight forward, read the below for the "logic" side and follow that document for the deployment.
You need to make sure you have access to the EWS service:
- The EWS service published to the world with a trusted authority certificate, with no warning messages displayed when you accessing it with a browser
- The EWS service is accessible to the world, or at least to the Google's IP range.
- A user that can read/write to the Public Folders, this will be referred as the Google API user
You will need public folders on the Exchange server, however, since the release of Microsoft Exchange 2007 they are not installed by default anymore, therefore create them if you haven't done it before.
Grant the Google API user owner rights on the public folders, as stated in the configuration documentation - Exchange side section 2.
You'll need to explain the Exchange server where to "look" for the Google Apps. Since the users are residing on a different system, we need to make it transparent to the users:
Exchange needs to know that the user isn't in its domain, that is why we should create an alias domain for Google's side (i.e. gapps.mydomain.com) and creating mail contacts pointing to Google Apps's users (email@example.com in Google Apps will be a firstname.lastname@example.org contact in the Exchange Server).
As stated in the configuration documentation - Exchange side section 4, we'll use the Add-AvailabilityAddressSpace to "explain" the Exchange Server where to look for information regarding a specific domain (i.e. gapps.mydomain.com). After executing this step, when I'll check availability of users that their SMTP address ends with gapps.mydomain.com the Exchange Server will know to look it up in the public folders.
At the Google Apps side, we need to "teach" Google Apps how to communicate its users to the Exchange Server. This is done at the last section of the configuration documentation - Google Apps side. Basically what is done by those entry is that we connect the attribute exchangeLegacyDN to the Google's user. By this, the Calendar Interop writes entries to the public folders that are connecting its side email@example.com to the firstname.lastname@example.org contact, which is represented by the exchangeLegacyDN attribute.
Google Apps Calendar Interop tools is a great feature doing large-scale deployments and need a free/busy sharing during rollout. I hope this information was helpful, please if you have any insights, question or even better, something to add, please leave a comment.