Lamest...Bug...Ever....

Entourage has a bug.

I know, that isn't exactly earth-shattering news. Entourage has had many bugs over the years, and still does (not the least of which is the fact that Entourage will sometimes decide, for no apparent reason, to eat mailbox data, as evidenced by many mailbox restores which I've had to perform thanks to that steaming pile of excrement - grrrr). But this one I find especially annoying, not to mention idiotic. Fortunately, it only impacts a small subset of our users, but still....  

We opened a support call with Microsoft PSS about this issue in January of 2007.  After many months (with no progress being made on the case whatsoever), Microsoft unceremoniously closed the case. With our update to Exchange 2007 and the release of Entourage 2008 earlier this year, I had hoped that the problem would go away, but my hopes were unfounded.  A few months ago, we opened a new case on this issue when yet another user complained about the problem, but still there is no resolution.

So what exactly is this dastardly bug which vexes me so? We have a small group of users (I previously knew of 2, and learned of a third the day before yesterday) whose accounts cannot be added to mailbox object or Public Folder DACLs via Entourage.  They can be added to folder sharing permissions just fine via Outlook, but attempts to do so via Entourage fail (regardless of who is attempting to do this) with the following error:

Entourage cannot modify permissions on the Exchange server.

There was an error while attempting to modify permissions on the server.

On the mailbox server, the following enigmatic error appears in the Application Event Log:

Event Type: Warning

Event Source: MSExchangeIS

Event Category: General 

Event ID: 1233

Date: 9/10/2008

Time: 4:28:06 PM

User: N/A

Computer: EXB06

Description:

An error occurred.

 Function name or description of problem: XNTSD::HrCreateSd()/XACL::HrCreateAcl()

Error: 0x80070057 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Helpful, isn't it?

But wait, it gets better.  When a third account with this issue came to light a few days ago, I noticed a pattern. All three accounts that exhibit this behavior have middle initial of "I". All of our display names are in the format "lastname, firstname initial" (with no period after the middle initial created by the account feed which populates our AD), so the display names of the effected accounts all end with " I".  On top of everything else, the middle initial for effected accounts does not appear in the search results for the "Select User" dialog box in Entourage.

Wondering if this pattern of non-functionality might be universal to all display names ending with " I", I employed a bit of EMS magic to dump a list of all mailboxes with display names fitting this pattern:

get-mailbox -resultsize unlimited | where {$_.DisplayName -like '* I' }

Sure enough, every name from this list produces the same error when attempts are made to use Entourage to add them to a sharing permission. Furthermore, I began tinkering with a test account.  Changing its display name from "User, Joe" to "User, Joe I" confirmed the issue.  The error surfaced.  Furthermore, the error was not fixed by adding a period.

One of my co-workers suggested that Entourage might be misinterpreting the letter "I" as a generational suffix.  Sure enough "II", "III", and "IV" all produce errors (with or without trailing periods), although "V" (and apparently all other letter combinations) works fine.

So, Entourage seems to have a strong dislike for multi generational naming schemes, at least through the first four generations.

Sigh....

UPDATE (Oct. 21): It gets better. This bug also manifests if the Display Name ends with 'Jr' or 'Sr' (with or without trailing period).  The Microsoft Premier Support folks have finally managed to replicate the issue, but they want us to fill out a Business Impact Statement to give to the Entourage dev team to use in evaluating whether or not to issue a fix.  I suppose it isn't sufficient that this is a BUG!