Violating the old Never Rewrite From Scratch rule (which, let’s be honest, is sporadically enforced) Microsoft created New Outlook in 2023. So far, it’s been a rocky rollout, with scant rewards for end users and mixed results for MOps.

 

On the bright side, email designers like the new rendering engine. You still need fallbacks for Classic Outlook, but more and more Microsoft shops will see your special effects. On the other side, the death of OFTs is pretty bad, but at least that’s a clean break.

 

More insidious are features ported over from Classic but subtly “fixed” in a non-backward-compatible way. Case in point: Microsoft decided to rewrite their iCalendar (ICS) parser. The new parser hews so tightly to the standard, RFC 5545, that previously supported ICS files now don’t show the Location field:

 

The specific area Microsoft fixed was the order of VEVENT properties and VALARM reminders. The standard is unequivocal here. A valid VEVENT must have its eventprop entries (DTSTAMP, ORGANIZER, SUMMARY, LOCATION, etc.) before any alarmc components (VALARM):

   Format Definition:  A "VEVENT" calendar component is defined by the
      following notation:

       eventc     = "BEGIN" ":" "VEVENT" CRLF
                    eventprop *alarmc
                    "END" ":" "VEVENT" CRLF

 

In other words, this ICS file is invalid since you can see the VALARM is above the LOCATION property:

BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20251016T041331Z
UID:20251016T041331Z-1266201208@ics.agical.io
DTSTART:20251112T190000Z
DTEND:20251112T230000Z
SUMMARY:Logi Work Montréal
DESCRIPTION:Logi Work Montréal
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Alarm: Logi Work Montréal
ACTION:DISPLAY
END:VALARM
LOCATION:Maison Alcan, 2100 Stanley Street
END:VEVENT
END:VCALENDAR

 

The correct order is like so:

BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20251016T041331Z
UID:20251016T041331Z-1266201208@ics.agical.io
DTSTART:20251112T190000Z
DTEND:20251112T230000Z
SUMMARY:Logi Work Montréal
DESCRIPTION:Logi Work Montréal
LOCATION:Maison Alcan, 2100 Stanley Street
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Alarm: Logi Work Montréal
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

 

Nevertheless, Outlook used to be fine with this. In fact, I can’t find a single ICS validator or library as strict as New Outlook!

 

From “reference libraries” like Libical, ical.js and ical4j to apparently homebrewed validators at iCalendar.org and CorrectICS, none care that VALARM is supposed to be after all the properties.[1] They should care, as they would’ve flagged bad files long ago, but since every major calendar app prior to New Outlook was permissive, there was little pressure from their communities.

 

The good news

Marketo’s own Calendar {{my.tokens}} are unaffected — they don’t support reminders at all, so there’s nothing to be out of order. The Agical.io ICS generator has been patched as well. I’ve also checked files generated by Zoom and On24 and they’re fine.

 

Your next step

If you generate ICS files via 3rd-party apps/libraries or internal code, thoroughly test in New Outlook.

 
 
Notes

[1] Google Calendar also doesn’t care about the order when importing. They likely use ical4j under the hood.