Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

I am happy about a solution I just came up with to the problem of not being able to define an arbitrary set of dates as the recurrence pattern for an event in Microsoft Entourage 2008.

I wanted to enter an event that was split across two days, and wouldn’t have obviously fit any type of “every Wednesday” or “every second Thursday” pattern. The ideal way to handle this, I think, was available in the Steltor CorporateTime calendar I used to use: create an event and add arbitrary dates to it, so that each recurrence appeared as part of the series. You can’t do that in Entourage — or I’ve never found any trickery to allow it.

Luckily, however, the event’s start time and duration was the same on each of the two days, so I realized I didn’t need to make two different events for it. And, I only had two recurrences to deal with — if there’d been more, it’s unlikely they would have been evenly spaced.

I used my “Compare dates” AppleScript to determine how many days apart the two instances of this particular event were. I came up with 20. I entered that as the number of days between recurrences. I set the recurrence to end on the date after the last event.

The result? I got two events (and two events only), both on the days I intended, and they were linked as part of a recurrence pattern. Sweet. It’s the little victories, you know?

I have had a problem that has repeated since I first began using Entourage as an Exchange client since at least version 11.0. I’ve never been able to solve it, but let me at least explain it here, because I’ve seen other people encounter it as well. It’s error -18576, and I hate it.

The symptoms are that I have calendar events displayed locally in Entourage that do not appear to synchronize to an Exchange mailbox. The Exchange mailbox, or account, does have some but not all of my calendar events.

There doesn’t seem to be any rhyme or reason to events that are missing. Many of them are recurring entries on my calendar. Beyond that, I’ve had events I put on my calendar myself, events that have been created through invitations from others, events with and without categories assigned, events that were created manually or with AppleScript, events that are flagged private, and so on.

The sequence of events I see in a traffic capture for affected events goes something like this:

1. Entourage tries to LOCK (a WebDAV call?) the event at a URL path ending in /exchange/userid/Calendar/eventname.eml.
2. Exchange returns an “HTTP/1.1 401 Unauthorized, NTLMSSP_CHALLENGE” response.
3. Entourage tries to LOCK the event again, at the same URL path.
4. Exchange returns an “HTTP/1.1 201 Created” response.
5. Entourage attempts an HTTP PUT of the event at the URL.
6. Exchange returns an “HTTP/1.1 200 OK” response.
7. Entourage attempts an HTTP PROPPATCH of the URL.
8. Exchange returns a “HTTP/1.1 207 Multi-Status” response.
9. Entourage attempts to UNLOCK the URL path.
10. Exchange responds with “HTTP/1.1 424 Method Failure.”

That’s it, that’s the extent of the HTTP/WebDAV exchange between Entourage and the Exchange server. The Entourage Error Log shows an -18576 error, but as of Entourage 2008, has no further description. Entourage’s Exchange-related errors are numbered in the -18000s and are typically based on HTTP (see the Entourage Error Page; use the equation 19000 + error number to determine its HTTP equivalent.

In my case, this is an HTTP 424 error, or a “Failed Dependency.” According to RFC 4918 on WebDAV, this means “The property change could not be made because of another property change that failed.”

The end result in Entourage is an event that does not appear in the Exchange calendar, but does appear locally — and there’s that entry in the Entourage Error Log, of course. There’s one such for each attempt to sync an affected event, so they build up over time — but some events do synchronize. It’s more aggravating that I’m left with a feeling of being in limbo, not knowing whether any calendar I’m looking at is correct or not. (Is there a sniglet for that? Update: I hereby propose “calendremma.”)

It doesn’t seem to matter whether Entourage is connecting to a front end or back end Exchange server (at least through Exchange 2003). Rebuilding the Entourage database doesn’t clear up the problem, although seems to occasionally have offered some temporary respite. However, the events that didn’t sync before still don’t sync.

The events which don’t synchronize fail to appear via Exchange ActiveSync on my iPod touch, and aren’t visible in either Outlook Web Access or Outlook for Windows.

Microsoft released Service Pack 1 to update Office 2008 for Macintosh on Tuesday, May 13. The update makes a significant number of changes — spread across Entourage, Word, Excel, and PowerPoint — so if you are a system administrator, I would recommend examining the full description of Office 2008 for Mac Service Pack 1 (12.1.0) in its release notes.

The update is downloadable via Microsoft AutoUpdate (invoke that helper program with Help > Check for Updates in any of the Office applications, or look inside /Library/Application Support/Microsoft in the file system) as well as the Microsoft Office for Mac Web site.

I had a good example today of how mismatched UIDs between Exchange meeting updates and existing events can affect Microsoft Entourage’s processing of those incoming updates.

I used the same drag-and-drop-to-export methodology as in my previous article. The iCalendar .ics file for the existing event that I dropped out of my Entourage calendar contained these unique identifiers:

UID:CD0000008B9511D182D800C04FB1625D717DE62091129A469FCB6E9EDDBF2075
X-ENTOURAGE_UUID:D26822E7-E4B7-49BB-9284-B18A2D42B77F

The e-mail cancellation from the meeting organizer, when dropped into the Finder as a .eml file, had the following unique identifiers:

UID:A449CD26-8099-11DC-8144-000393C78A56
X-ENTOURAGE_UUID:A449CD26-0991-DC81-4000-93C78A560000

As we can see, even though these were supposedly for the same event, neither the UID nor the X-ENTOURAGE_UUID properties matched. I emphasize the UID property because, as per my post on matching UIDs between Exchange meeting updates and existing events in Microsoft Entourage, I believe it to be the most important.

Both I and the meeting organizer are Entourage users in this case. That may be why both the event and the cancellation had X-ENTOURAGE_UUID properties at all. The UID property has appeared consistently for me in both events and their updates, no matter what their source.

Because of the discrepancy between unique identifiers, Entourage apparently couldn’t determine whether the cancellation was for the event that existed in my calendar. When Entourage “processed” the cancellation, it removed nothing from my calendar.

This seems entirely reasonable, although I would personally like Entourage to do deeper matching if it could: how about “is there an existing event by the same organizer and/or with the same name at the time of the update or cancellation?” Matching UIDs has got to be simpler.

How does this happen? Well, for me, it could have happened any number of ways: There could have been a past error when:

• Entourage was trying to synchronize to my Exchange account
• my Entourage calendar was synchronizing with Sync Services on Tiger or Leopard
• Missing Sync for Palm OS, which I use with my Palm Treo 650, was performing its synchronization with Sync Services on Tiger or Leopard
• I was using Microsoft Outlook in cached mode with my Exchange account
• I used Duplicate Killer for Outlook from 4Team to remove massive numbers of duplicate calendar entries from my Outlook/Exchange calendar (which could have resulted in the loss of events with their original UIDs).

As far as I can determine, when you have data synchronization problems, you’re going to have one of the following outcomes:

• data is added
• data is deleted
• data is modified
• nothing happens.

Not all of these are pleasant, mind you — and that can depend on the circumstances involved. Deleting data is perfectly acceptable in some scenarios where it needed to be removed, but not others where it means it has just been lost. Adding data is great, unless it results in unwanted duplicates.

Anyway, I hope this helps you understand how Microsoft Entourage works a bit better.

When Microsoft Entourage is handling meeting updates or cancellations between Exchange users, it’s critically important that it can match up the change to an event with the correct event in a calendar. It does so by comparing unique identifiers between the update/cancellation message and existing calendar events. As nearly as I can tell, this depends on having the right UID, which makes sense.

How can you see the UID for events? Drag the event from an Entourage calendar to a Finder window, where it will become an vCalendar/iCalendar-formatted file with a .ics extension. You can open the resulting file in a text editor. Here’s a sample from a repeating event in an Entourage calendar, with the UID highlighted:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Microsoft Corporation//Entourage Mac 11.0 MIMEDIR//EN
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:GMT -0500 (Standard) / GMT -0400 (Daylight)
X-ENTOURAGE-CFTIMEZONE:
BEGIN:STANDARD
TZNAME:Standard Time
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:16010101T020000
END:STANDARD
BEGIN:DAYLIGHT
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:16010101T020000
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:040000008200E00074C5B7101A82E00800000000D0172C9CE47DC801000000000000000010000000C131C7E01B61184999585795596672E0
X-ENTOURAGE_UUID:37656211-A6ED-4E37-99D2-BAD25704AF63
DTSTAMP:20080304T160415Z
DTSTART;TZID="GMT -0500 (Standard) / GMT -0400 (Daylight)":20080305T100000
DTEND;TZID="GMT -0500 (Standard) / GMT -0400 (Daylight)":20080305T113000
LAST-MODIFIED:20080304T160433Z
… [snip]

Similarly, you can drag and drop a proposed change to an event, which is received by e-mail (because Exchange is largely an e-mail based — rather than a network-based — calendar system), to the Finder. This will save the message as the text source of the e-mail, with a .eml extension. That file can also be opened in a text editor, where you can see that it contains a siginficant amount of vCalendar/iCalendar data. Here’s a sample cancellation notice that removes one instance of the recurring event from Entourage — for reference, not the instance shown above, but another one from the same sequence:

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT -0500 (Standard) / GMT -0400 (Daylight)
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
X-MICROSOFT-CDO-MODPROPS;X-MODPARAM=1:attendee,BEGIN,class,created,description,dtend,dtstamp,dtstart,duration,END,last-modified,location,organizer,priority,recurrence-id,sequence,status,summary,transp,uid,x-microsoft-cdo-alldayevent,x-microsoft-cdo-apptsequence,x-microsoft-cdo-attendee-critical-change,x-microsoft-cdo-busystatus,x-microsoft-cdo-importance,x-microsoft-cdo-insttype,x-microsoft-cdo-intendedstatus,x-microsoft-cdo-owner-critical-change,x-microsoft-cdo-ownerapptid
DTSTAMP:20080422T194244Z
DTSTART;TZID="GMT -0500 (Standard) / GMT -0400 (Daylight)":20080423T100000
UID:040000008200E00074C5B7101A82E00800000000D0172C9CE47DC801000000000000000010000000C131C7E01B61184999585795596672E0
… [snip]

Note that the UID properties match.

If you are troubleshooting a problem where an update/cancellation does not modify an existing event as you expected, and the UIDs of each do not match, that’s probably the source of your problem. Of course, you still have to figure out why the UIDs don’t match. In that case, I’d personally start by looking at what other synchronization software (besides Entourage’s own Exchange sync) and devices are involved.

Amir’s post about how How Does Entourage Work? is certainly welcome. It outlines, service by service, how Entourage communicates with an Exchange server. It documents the basic traffic, ports used and protocol security.

This sort of thing really should have been part of the documentation for Microsoft Entourage 2004 — at least SP2 in September 2005 — but no matter the timing, it’s extremely useful information now. It explains to both tech support staff and Exchange administrators how Entourage conducts Exchange transactions. It also clears up misconceptions that I’ve come across on the Web, in forums, and in person.

It struck me today that when running Entourage, I have two script menus. One is specific to Entourage, the other is for the optional — but handy — system-wide Script menu. Yet both have the same icon — the stylized black and white paper-rolled-into-an-S icon — in my menu bar.

The app-specific script menu was probably more common in classic Mac OS days than it is under Mac OS X. (But yet, as I type this, I noticed that MarsEdit has its own script menu, too. I think that just shows how wired into classic’s scripting Brent Simmons was — I mean, he worked on UserLand Frontier, the original scripting environment for the Mac.)

Ah, I just wish the two menus could be one and the same. If Entourage (or any other application) detected that you had the system’s Script menu enabled, it ought to just turn its own off in favor of the system menu. Or maybe the system-wide menu could show the app-specific scripts first, so that they are always in a known location (top of list, right side of menu bar), and take over the function of the application’s scripting menu. Or, they could just have two different icons, or one could be an icon while the other was text, or whatever.

In reviewing Jesper's list of requirements for The Email Client That Doesn't Suck, I was somewhat surprised how many of his points are already handled by Microsoft Entourage 2004.

I’d give it 19 out of 26 points. There are some places where I’m being charitable towards Entourage, partly because it can support the requirement with a little work (which does not always mean scripting — and it should be noted that Entourage is very scriptable) or I didn’t understand what Jesper meant by the requirement.

Many Mac users discount Entourage. There are a couple of reasons that may be cited:

• Microsoft bundles it with Office 2004, so you have to buy it along with a lot of other software in order to get it. That costs more than a standalone client, even if you’re eligible for the $149 Student and Teacher Edition (which is often discounted even more).
• It’s not Universal yet, so it works natively only on PowerPC Macs. It requires Rosetta on Intel Macs today. (But Microsoft has announced that the next version of Office will be Universal.)
• It comes from Microsoft, so it must be evil somehow.
• It has a custom monolithic database for its backend. This predates any of Apple’s Core Data-type development. It can be a completely valid issue for some — such as those with network or portable home directories, or those performing regular client backups.
• It doesn’t look like a Mac OS X application. Rather, you might say it looks more like an application from classic Mac OS … and I’d agree, but there are some quick things you can do to spruce things up. (I had some on my old blog, but I still haven’t ported the old content over. Suffice it to say that changing a lot of the font choices to “Lucida Grande” in the preferences makes a big difference.)

That said, there are many valid concerns about Entourage. I voice many through the Microsoft feedback channels available to me.

However, I think there is a huge impediment to creating a new e-mail client today, simply because of how connected this kind of product is to your whole computing experience. Any developer should take that into consideration, and realize that it’s probably an unending effort.

If you don’t get enough Microsoft Entourage information from the usual sources, I count that as a personal failing on my part. Just kidding. But still … you’ll probably want to check out Amir's Exchange Clients Blog. There, Amir “is focussed [sic] on Entourage only in the role of being a client to Exchange Server and Outlook Anywhere (RPC over HTTP) Feature.”

[Via Richard.]

I was amused the other day when I thought I saw Avril Lavigne on the soundtrack to “Erage” at the top of the charts in the iTunes Store. So, of course, I needed to blog about it with a misleading headline and a screenshot.

“Erage” is, of course, handy shorthand for Microsoft Entourage. (In fact, it’s so embedded in my thinking that it’s the shorthand substitution I use for “Entourage” in Spell Catcher X and what I type to launch the application from LaunchBar.) I swear I remember seeing members of the Entourage team wearing jackets bearing the “Erage” name, too. Edit: It is not, however, related to the television show Entourage. Which is where I’m betting a lot of my hits on this page come from.

Anyway, it turns out that it was a song on the soundtrack to “Eragon”—an actual movie with a soundtrack, of course—but it still amused me to take a screenshot. (When you have screencapture + Python + Core Image, why not take frivolous screenshots?)

Update: After several months and several attempts that each seemed to work in their own way, I finally got the inline image to appear. I’m not exactly a fan of Drupal’s image handling at this point — coming from my Manila background — but perhaps I have sorted it out.