I’ve long been aware that Entourage does not know how to properly handle the granularity of control over free/busy information introduced by Exchange 2007, but I’ve now become aware of an even more serious bug on this front in Entourage 2008 Web Services Edition. It seems that anytime that version of Entourage is used to modify Calendar sharing permissions on an Exchange 2007 server (and presumably an Exchange 2010 server), the user or group to whom the permissions are being granted looses the ability to see the free/busy information for that Calendar, regardless of the permissions level granted.

Here are the steps that I have taken to replicate this issue in our environment.  We have Exchange  2007 SP1 Rollup 8. In the testing which I describe below, I am using Outlook 2007 and Entourage 2008 Web Services Edition, Version 13.0.03  (091002). Steps to reproduce the issue are as follows:

• – In Outlook, grant sharing permission to another user on your Calendar. For this example, we’ll grant the user “Free/Busy time, subject, location” permissions. Verify that on the permissions tab, with that user selected, in the Read section, the radio button  for “Free/Busy time, subject, location is checked. After clicking “Apply”, verify that the user can in fact see your free/busy. We have now set a baseline for expected functionality.
• – Now, in Entourage, check the sharing permissions on your Calendar. For the user to whom you have granted permissions, the permissions level will show as “None.”  Now let us use Entourage to modify the sharing permissions. Set it to “Reviewer” for example, and click “OK.”
• – At this point, the user to whom permissions have been granted will be unable to see your free/busy information. (This is true regardless of what permission  level is set in Entourage.)  Looking at the Calendar sharing permissions in Outlook, none of the Read permission items are checked.

This is a serious bug in Entourage, and the only way that I know of to repair the damage is to properly set the permission with an Outlook client.

UPDATE (Sept. 15): We received a note from Cornell indicating that they found that applying Service Pack 3 fixed this issue. Thanks for the heads-up. We are at SP2 RU4, and the problem still manifests at that patch level.