uCan iCal with Exchange and Outlook


iCal, or internet calendaring, generally isn't heavily used or widely understood. When it is used, it generally creates some confusion since it produces different results based on what server and clients are used. Rather than babble on about all the RFC info, lets use an example to show what this is and how Exchange and Outlook use it.


For this discussion, we assume that sending calendaring items means sending them to a recipient over the internet, or outside the organization. Also, the Outlook client is assumed to be Outlook 2003. Legacy clients/servers will be covered later in the doc.


iCal is a body part in the MIME stream that describes a calendaring event. Usually stored in the stream in a totally readable format... Huh? MIME stream? Body part? Messages on the internet are in MIME format. Have a look, here is a MIME stream with a iCal body part...


-------------------------------------------------------------
Received: by Recipient.AlpineDom.com
 id <01C4920A.480E1A6D@Recipient.MyDom.com>; Fri, 3 Sep 2004 16:03:52 -0700
Content-class: urn:content-classes:calendarmessage
Subject: From MAPI
Date: Sat, 4 Sep 2004 16:03:52 -0700
Message-ID: <E96327EB8B1C144B8438BB7E8C78018F26A4@Recipient.MyDom.com>
X-MS-Has-Attach:
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----_=_NextPart_001_01C4920A.480E1A6D"
X-MS-TNEF-Correlator:
Thread-Topic: From MAPI
Thread-Index: AcSSCoTgSWkIZcpPRcWr/FCLQdCt2g==
From: "Recipient" <Recipient@MyDom.com>
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
To: "Recipient" <Recipient@MyDom.com>


This is a multi-part message in MIME format.


------_=_NextPart_001_01C4920A.480E1A6D
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


When: Saturday, September 04, 2004 10:00 AM-11:00 AM (GMT-08:00) Pacific =
Time (US & Canada); Tijuana.
Where: Here


*~*~*~*~*~*~*~*~*~*


 


Microsoft Outlook Web Access:
http://MyServer/Exchange/Recipient/Inbox/From%20MAPI-2.EML?cmd=3Dopen



------_=_NextPart_001_01C4920A.480E1A6D
Content-Type: text/html;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.xxxx.0">
<TITLE>From MAPI</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->


<P><FONT SIZE=3D2 FACE=3D"Arial">When: Saturday, September 04, 2004 =
10:00 AM-11:00 AM (GMT-08:00) Pacific Time (US &amp; Canada); =
Tijuana.</FONT>


<BR><FONT SIZE=3D2 FACE=3D"Arial">Where: Here</FONT>
</P>


<P><FONT SIZE=3D2 FACE=3D"Arial">*~*~*~*~*~*~*~*~*~*</FONT>
</P>
<BR>
<P>Microsoft Outlook Web Access: <A =
HREF=3D"http://MyServer/Exchange/Recipient/Inbox/From%20MAPI-2.EML?cmd=3D=
open">http://MyServer/Exchange/Recipient/Inbox/From%20MAPI-2.EML?cmd=3D=
open</A></P>
</BODY>
</HTML>
------_=_NextPart_001_01C4920A.480E1A6D
Content-class: urn:content-classes:calendarmessage
Content-Type: text/calendar;
 method=REQUEST;
 name="meeting.ics"
Content-Transfer-Encoding: 8bit


BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(GMT-08.00) Pacific Time (US & Canada)/Tijuana
X-MICROSOFT-CDO-TZID:13
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20040903T230535Z
DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20040904T1000
 00
SUMMARY:From MAPI
UID:040000008200E00074C5B7101A82E0080000000070E87ED8CF91C401000000000000000
 010000000D598A2AF5309D942BD8C93969DEFD500
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="test2i333
 ":MAILTO:Recipient@MyDom.com
ORGANIZER;CN="Recipient":MAILTO:Recipient@MyDom.com
LOCATION:Here
DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20040904T110000
DESCRIPTION:\N
SEQUENCE:0
PRIORITY:5
CLASS:
CREATED:20040903T230353Z
LAST-MODIFIED:20040903T230354Z
STATUS:CONFIRMED
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-OWNERAPPTID:-794585132
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT00H15M00S
END:VALARM
END:VEVENT
END:VCALENDAR


------_=_NextPart_001_01C4920A.480E1A6D-


-------------------------------------------------------------


Without getting into how MIME streams are built, covered in the various RFC, and what it all means, there are three body parts to this stream we are concerned with.
Content-Type: text/plain;
Content-Type: text/html;
Content-Type: text/calendar;


The last body part, text/calendar, is the iCal blob. As you can see, it's relatively readable. Clients receive this stream have to process it some how. In this case, they are given three options to display the message; these are the three body parts. At least, all clients can display the text/plain since its well, just plain text. If the client knows how to process the text/html body part, it has that option and if it knows how to display a rich meeting request from the text/calendar, it too has that option. Again, it's up to the client to decide what to display.


I'm not going into what each of the lines in the iCal blob means, many of them are self evident, but there are a few lines worth looking at to better understand what is going on


Content-Type: text/calendar;
 method=REQUEST;
 name="meeting.ics"
Content-Transfer-Encoding: 8bit


Outlook Express is not a calendaring client and doesn't know how render the text/calendar into a rich meeting request, so it decided to display the plain text body part. However, in addition it also provides the iCal blob to the user as an attachment, this is what the name="meeting.ics" line above provides. Again, this is all up to the client.



The other interesting line is the encoding; Content-Transfer-Encoding: 8bit. This describes how the particular body part is encoded. It could have been encoded in a way that makes it look like total gibberish leaving it unreadable like Base64. You can see the other body parts have different encoding, but they are all still readable.


The URL to direct the users' to their Exchange mailbox with OWA was added in the message body. Exchange knows this is a calendaring item and has added this to the text/plain and text/html body parts giving the recipient the option to book it in the calendar on the Exchange server with a web browser. This option is on the POP/IMAP virtual server in Exchange System Manager.


 


Finally, a quick note about the Content-Type: multipart/alternative line in the beginning of the stream. This essentially tells the client there are multiple parts to choose from, use the one you (the client) see best fit. Remember this entire stream is handed to the client, and is up to the client to process it.


Ok, so what does this have to do with Exchange? Or Outlook?


- Exchange inside talks MAPI, so MAPI <-> MIME conversions need to take place.
- MIME streams need to be created either by the client or the server.
- Exchange 200x understands iCal but previous version don't.
- Outlook XP doesn't understand multipart/alternative, Outlook 2003 does.


When/where do the iCal MIME streams get created?


Normally Outlook is connected to an Exchange server and talking MAPI. So when Outlook sends a meeting request, it's Exchange that is creating the MIME stream. If Outlook is connecting to a server via POP, it's Outlook that's creating the MIME stream. If connecting with OWA, then of course Exchange is creating the MIME stream.


Isn't it up to the client to decide how to display the iCal item?


It is. Normally Outlook is in MAPI talking to Exchange. When an iCal item arrives, Exchange 200x puts the item in its native form in the store, leaving it there unchanged. When Outlook, in MAPI, requests this item, the store realizes that a MAPI client is asking for a MIME item and then needs to convert it. Exchange 200x is completely iCal aware, understands the multipart/alternative option and selects the text/calendar to convert into a rich MAPI meeting request for Outlook. OWA behaves exactly the same.


Now, Outlook is connecting to the server via POP/IMAP mode, when an iCal item arrives, Exchange 200x does exactly the same thing as before, puts the item in the store in it's native format. Now when Outlook in POP/IMAP mode requests the item, the Exchange 200x store knows the original format arrived as MIME and MIME client is asking for the item, so Exchange just hands Outlook the item unchanged. It's now up to Outlook to process the MIME stream.


If any MIME message arrives in Exchange and any POP/IMAP, or internet client, asks for the message, Exchange simply hands the message over to the client. Outlook Express is not a calendaring client, but still receives the iCal blob just as any other internet client would, and exposes it as an attachment. Other clients may do the same or something different.


How about Outlook XP or older Outlook clients?


Outlook XP in POP/IMAP mode can handle iCal blobs, but doesn't understand multipart/alternative. So if a calendaring item is handed to Outlook XP in POP/IMAP mode with multipart/alternative, which is the default Exchange uses, it will only display the text/plain. The only way Outlook XP will render iCal is if the content type is text/calendar and is the only body type. This means the calendaring item had to enter Exchange in MIME format originally. Older than Outlook XP? Well don't expect any improvements over what Outlook XP does. If Outlook XP is talking MAPI and a meeting request arrives in MIME, Exchange converts it for Outlook into a rich meeting request, just as it would for basically any MAPI client. It's Exchange that's converting the MIME stream into MAPI since MAPI is asking for the item.


The Mac clients...


Outlook Mac doesn't have options for a POP account, it's a pure MAPI client. The latest Microsoft Mac mail client is Entourage which only connects via POP/IMAP/HTTP and is completely iCal aware. This is one client that in addition to Outlook 2003 works very well in iCal environments.


What about Exchange 5.5?


All inbound and outbound MIME mail is handled by the IMC, the IMC converts all MIME to MAPI immediately upon delivery and doesn't understand iCal, or text/calendar, so it can't produce a rich meeting request. This is why the recipient gets a plain text message regardless of what mode Outlook is in. In Exchange 200x all inbound MIME mail is held in its native format in the store until a conversion is necessary, this helps improve performance.


A final word on TNEF. Exchange uses a method to send a MAPI message over the internet in TNEF format, see example header snippet below. Transport Neutral Encoding Format allowed Exchange to wrap all the MAPI properties up and encode them in the MIME stream as a body part. It kind of looks something like Base64 encoding. This was a safe thing to do if you knew your recipient server was an Exchange server and how calendaring items were sent over the internet before iCal. But as the internet grew to what it is today, Exchange needed to be more robust to accommodate this change and added full support for iCal in Exchange 200x.


Content-Type: application/ms-tnef;
 name="winmail.dat"
Content-Transfer-Encoding: binary
X-MS-TNEF-Correlator: <AC5C2D235D49494CBD7F4259E616A0662496@user.MyOffice.com>

- Eric Hartmann

Comments (4)
  1. Corentin says:

    I thought for a moment that you were talking about iCal:

    http://www.apple.com/ical/

    (which offers some Internet Calendaring features) :-

    Corentin

  2. Anonymous says:

    Internet Calenders, it is all that it is cracked up to be? I think it depends on what your needs are for the most part. The first thing to understand is what can be used for this sort of thing….

  3. I’m using Outlook 2003 with Exchange 2003. I’ve got a colleague outside of the organisation who is also using Outlook 2003 but via POP3 with his local ISP.

    If he sends me a meeting request, it works – I get the request, Outlook parses it and I can process it.

    If I send him a meeting request, it doesn’t work. His copy of Outlook just displays the text – there isn’t an ics file nor does Outlook display the meeting buttons.

    Is this expected behaviour or is something misbehaving?

    Are meeting requests treated different from the scenario discussed in this blog?

  4. Eric Hartmann says:

    Philip,

    It works when he sends you a meeting request because his Outlook client is creating the MIME stream, independent of the server, and sending it. Once it has reached your Exchange 2003 server, it is placed in the store in it’s native format until your MAPI client asks for it, then Exchange parses and converts it. Unless it’s converted, scanned and altered along the way to your exchange server, it renders as a rich MR since Exchange can parse a text/calendar body part.

    Now when you send out a MR, the Exchange server has to create the MIME stream and has rules to follow based on what the admins have setup There are several places where admins have control of what leaves the org both at the directory (recipient a contact in the GAL or in your contacts folder in Outlook) and at the SMTP level (Text, HTML, both or TNEF). It’s most likely that the admins have forced plain text messages on outbound messages from your org and is why your recipient is receiving the MR in plain text. Have your recipient pull down the message with Outlook Express and look at the MIME stream (props on the message). Outlook uses the same engine as Outlook Express to receive mail via POP/IMAP client settings, make sure in Outlook Express you tell it to leave a copy of the message on the server so Outlook2003 will then receive the mail as well when you are done.

    It’s also possible, but not likely, the ISP server is scanning the inbound SMTP mail, which they all should do for spam, viruses and such, and removing the body parts it doesn’t have in it’s safe list.

    At last – I’d ask you that if this does not help you resolve the issue, to open up the Support case with our Support Services. This will take some troubleshooting and verification of several config settings…

Comments are closed.

Skip to main content