(Or "Why You May Want to Patch Your Exchange Server")

Before SP2, Entourage would allow you to perform an action within a folder, calendar, or address book and, at a later time, the app would attempt to sync your change to the server. If the sync failed due to permission errors, the offending item would be either moved to your drafts without notice or, in some instances, completely lost--unquestionably a bad experience for anyone.

As we added a fair amount of features in SP2 to enable team collaboration (e.g. sharing calendars, opening shared folders, improved delegation, much improved public folder support), solving permission confusion became a much more critical issue. No one wants to spend 30 minutes crafting a post to a public folder only to have it disappear because they had read-only permissions on the folder and Entourage never let them know.

How Does Entourage Enforce Permissions?
Let’s start with a simple example of a common permission setting: a user with the ability to delete items they created in a folder but without the ability to delete items others created in the folder. In this case, the folder level permissions are Delete Own while each item’s deletion permission varies based on ownership.

Each folder and item on the server has a corresponding PR_ACCESS value that is calculated by the Exchange server. When certain folders and items are synchronized with Entourage, the application retrieves a corresponding PR_ACCESS along with all the other information about the folder, message, contact, or event. Entourage makes no attempt to calculate the user’s permission level from within the client; the server informs us of permissions and we listen. In the Delete Own example, the folder’s PR_ACCESS property has a value representing this level of rights while each item in the folder has different PR_ACCESS property values depending on if a user may or may not delete the particular item.

Permissions Sync Optimizations
The Delete Own example provides a particular challenge to synchronizing permissions with Entourage. If the folder’s Owner changes permissions on the folder such that an Entourage user now has Delete All rights, Entourage must resynchronize the PR_ACCESS value for each and every item within the folder. The Exchange server notifies Entourage that a permission change occurred and the only way for the application to know the full extent of the change is to verify the permissions for all affected items.

While this sounds like a fair amount of overhead for synchronizing permissions, there are three factors working to minimize the resources needed: PR_ACCESS is a small (two bytes) value, a permission change affecting a user is typically are a one-time or rare event, and Entourage optimizes by always assuming Owner level rights (and thus not synching permissions) for a user’s mailbox folders.

So Why Do I Need to Patch My Exchange Server?
The user mailbox optimization is critical to understanding why your organization may want to patch the Exchange servers. The inverse of the optimization is that permission values are synchronized for all folders outside a user’s mailbox (e.g. public folders, a folder/address book/calendar shared with another user, and any delegated folder or mailbox).

Without patching your Exchange server, all folders outside a user's mailbox synchronized by Entourage 2004 SP2 will be read-only. The PR_ACCESS value retrieved by Entourage via WebDAV is returned incorrectly when connected to a non-patched Exchange servers. The property is always returned as read-only, even if the user has a higher level of privileges. Without the patch, Entourage will use these read-only values to lock the user out of performing actions they may actually have permission to perform.  With the patch, the correct value is returned to Entoruage and permissions are accurately reflected within the user interface.

If you are applying the patches, you should consider applying the patch on all servers within your organization (frontend, backend, public folder, etc.). The Entourage team worked side-by-side with the Exchange team on the fix, though the fix will correct permissions for all DAV clients.  To read more about and download the patches, refer to the following KB articles:

The Exchange 2003 fix will be included in the upcoming Exchange 2003 SP2 release.

Possible Oddities in Synchronizing Permissions
Keeping permissions in sync with an offline client is difficult and there instances where the cached client permissions may differ from the servers:

Downgraded permissions - Entourage’s local cache has Read-Only permissions for a folder while the user actually has a higher level of permissions. The next time the folder synchronizes with the Exchange server, Entourage will update the permissions within the local cache. There’s no risk of losing data, as Entourage will be overzealous in restricting actions until the next sync.

Faux-Escalated permissions - Entourage’s local cache includes a higher level of permissions than those on an Exchange server. For example, an Entourage user has Read-Write privileges on a public folder, goes offline to board an airplane, and, while jetting, posts several new items to the public folder (write activity). During the flight, an administrator removes the write-level permissions for the user on the public folder.

At this point, the offline cache’s permission level is now out of sync with the Exchange server. When the user reconnects, Entourage may or may not update the local permissions before attempting to sync the newly created posts (it’s a timing issue optimized for the most common scenarios). However, the permissions on the Exchange server always trump the permissions cached within Entourage. When Entourage attempts to sync and fails, the newly created items will be moved to the user’s Drafts folder and permission denied errors logged in the Entourage Error Log--the same behavior of Entourage 2004 prior to SP2.