Working with meeting responses in Exchange ActiveSync
Last modified: August 22, 2011
By Katarzyna Puchala
Summary: This article explains how Microsoft Exchange ActiveSync clients can respond to meeting requests and interpret meeting responses by using Exchange ActiveSync protocol version 14.1. Where applicable, differences between product versions are noted.
Applies to: Exchange Server
In this article
Scenario 1: Invitee uses an Exchange ActiveSync client to respond to a meeting request
Scenario 2: Organizer uses an Exchange ActiveSync client to verify the meeting response status
The ability to respond to meeting requests is an important aspect of collaboration and communication for Microsoft Exchange users. Responses to meeting requests inform meeting organizers of invitees' attendance status and automatically book the time on attendees' Calendars. In Working with meeting requests in Exchange ActiveSync, we explored how Exchange ActiveSync clients can create, send, receive, and interpret meeting requests. In this article, I describe the following aspects of working with meeting responses from the perspective of an Exchange ActiveSync developer:
How the Exchange ActiveSync client responds to meeting requests
How the Exchange ActiveSync client should interpret responses to meetings organized by the client user
Other topics related to calendaring with Exchange ActiveSync (such as recurring meetings, delegation, meeting updates, and meeting cancellations), will be covered in future articles.
The following figure shows an overview of the meeting response process and the two key scenarios involved. In this example, Exchange ActiveSync user Bob has received a meeting invitation from the organizer, Alice, on his Exchange ActiveSync client. Bob responds to the meeting request using his Exchange ActiveSync device, and Alice can verify his response status using her device.
In our example, an invitee, Bob, finds a meeting request from Alice waiting in his Inbox, and a placeholder Calendar item tentatively marking the time of the meeting on his Calendar. Bob can choose to accept, tentatively accept, or decline the meeting and send his response to the organizer from either the meeting invitation in his Inbox or the Calendar placeholder item. Bob accepts the meeting request by using the options provided by the meeting request email displayed on his Exchange ActiveSync client. The Exchange server then deletes the meeting request from his Inbox and changes the status of the placeholder Calendar item from Tentative to Busy. In addition, the Exchange ActiveSync client sends a meeting acceptance notification to the organizer. A copy of this message appears in Bob's Sent Items folder.
The following figure shows the Exchange ActiveSync client meeting response process.
Responding to meeting requests involves the following steps:
The user, in this case Bob, accepts the meeting from his Exchange ActiveSync client by using the options exposed in the meeting request. Upon doing so, the following events occur:
The server deletes the meeting request email message from his Inbox.
The server deletes the tentative meeting from his Calendar and adds an accepted meeting in its place.
If Bob's Exchange server is not configured to process incoming meeting requests automatically, a tentative meeting placeholder item does not appear on his Calendar. In this case, the server does not delete any Calendar item, and the MeetingResponse command cannot be sent from the Calendar folder; it can be used on the meeting request in the Inbox only.
When Bob issues a Sync command on the Calendar folder, the tentative meeting is deleted from the Calendar by the Exchange server, and a new accepted meeting is added.
If Bob synchronizes his Deleted Items folder, a copy of the original meeting item is added to that folder. (This step is not shown in Figure 2 and is not described in this article.)
Bob's client sends an email message to the organizer that indicates his acceptance.
The server adds a copy of the meeting acceptance email message in Bob's Sent Items folder. If Bob synchronizes his Sent Items folder, a copy of the notification will appear there.
When the ResponseRequested element is set to 1, the Exchange ActiveSync client allows the user to act on the meeting request from both the Inbox and the Calendar item.
Responding to meeting requests from the Inbox
When the client displays a meeting request message in a user's Inbox, the user has the option to accept, tentatively accept, or decline the meeting invitation. After the user selects a response, the client sends a MeetingResponse command to the server.
MeetingResponse command request
The following example shows a MeetingResponse command request.
<?xml version="1.0" encoding="utf-8"?> <MeetingResponse xmlns="MeetingResponse:"> <Request> <UserResponse>1</UserResponse> <CollectionId>6</CollectionId> <RequestId>6:17</RequestId> </Request> </MeetingResponse>
The RequestId element specifies the server ID of the meeting request in the Inbox collection. The UserResponse element can contain one of the values listed in the following table.
UserResponse element value
The server deletes the corresponding Calendar entry and creates a new Calendar entry with the "Accepted" status.
The server deletes the corresponding Calendar entry and creates a new Calendar entry with the "TentativelyAccepted" status.
The server deletes the corresponding Calendar entry.
Server response to the MeetingResponse command request
After the MeetingResponse command has finished, the server automatically deletes the meeting request item from the Inbox. The following example shows the server response.
<?xml version="1.0" encoding="utf-8" ?> <MeetingResponse xmlns="MeetingResponse:"> <Result> <RequestId>6:17</RequestId> <Status>1</Status> <CalendarId>2:25</CalendarId> </Result> </MeetingResponse>
The RequestId element specifies the meeting request that the client is responding to. If the meeting invitation is accepted or tentatively accepted, the server adds or updates the corresponding Calendar item and returns the item's server ID in the CalendarId element of the response.
The following table lists the possible values for the Status element.
Status element value
The request succeeded.
This response indicates that the request is invalid. The client should not retry the request, as it is unlikely to succeed. The server sends this response if the item sent to the server is not a valid meeting.
This error is returned when the client sync state is missing or corrupted on the server. The client can retry once, right away, but should retry slowly after that, about once an hour. If the request still fails after an extended period, the client should stop retrying.
This error indicates that the meeting request can't be processed. The meeting request may be missing, the meeting may have been canceled, or this may be a delegate meeting to which the user can't respond. If the client retries the request, it is unlikely to succeed.
The Exchange ActiveSync client should handle the response to the MeetingResponse command in the same way that it handles the status responses to email commands.
When an invitee responds from the Inbox item, the Exchange server deletes the meeting invitation from the Inbox. The invitee can, however, change their response to the meeting request from the Calendar item with new MeetingResponse command. If the user declines the meeting, the server deletes the Calendar item, and it can no longer be used to respond to the meeting request.
The Exchange server automatically deletes the email invitation from the Inbox after the user has responded to the request. When the Exchange ActiveSync client synchronizes the Deleted Items folder, the deleted item is automatically added to the Deleted Items folder on the client.
Responding to meeting requests from the Calendar folder
Users respond to a meeting request from the Calendar folder in the same way that they respond to the request from the Inbox. The client uses the MeetingResponse command, but in this case, the RequestId element value indicates the Calendar item. This option is only available in Exchange ActiveSync version 14.0 and later versions. When the user responds to a meeting request from the Calendar folder, the corresponding meeting request item in the Inbox is automatically deleted by the server.
Replacing the placeholder Calendar item with a new item
When the user responds to the meeting request, the original tentative Calendar item is deleted. If the user declines the meeting request, the server does not add a new item to the Calendar. If the user accepts or tentatively accepts the meeting request, the server creates a new Calendar item with the status as indicated by the user. The following example shows the Sync command response for the Calendar collection, after the user has accepted the meeting request. The original meeting item is deleted, and the new item with a status of "Accepted" is added in its place. The UID element value of the new accepted item is identical to the value of the tentative placeholder item.
<?xml version="1.0" encoding="utf-8"?> <Sync> <Collections> <Collection> <SyncKey>1598194209</SyncKey> <CollectionId>2</CollectionId> <Status>1</Status> <Commands> <Add> <ServerId>2:25</ServerId> <ApplicationData> <calendar:TimeZone>4AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAABAA IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAACAAIAAA AAAAAAxP///w==</calendar:TimeZone> <calendar:DtStamp>20110510T185139Z</calendar:DtStamp> <calendar:StartTime>20110510T170000Z</calendar:StartTime> <calendar:Subject>Quarterly Planning</calendar:Subject> <calendar:UID>A3561BDAAE8E4B30AC255FD3F31A3AD7000000000000000000000 00000000000</calendar:UID> <calendar:OrganizerName>Alice </calendar:OrganizerName> <calendar:OrganizerEmail>firstname.lastname@example.org</calendar:OrganizerEmail> <calendar:Attendees> <calendar:Attendee> <calendar:Email>email@example.com</calendar:Email> <calendar:Name>Bob </calendar:Name> <calendar:AttendeeType>1</calendar:AttendeeType> </calendar:Attendee> </calendar:Attendees> <calendar:Location>Office</calendar:Location> <calendar:EndTime>20110510T180000Z</calendar:EndTime> <airsyncbase:Body> <airsyncbase:Type>1</airsyncbase:Type> <airsyncbase:EstimatedDataSize>127</airsyncbase:EstimatedDataSize> <airsyncbase:Truncated>1</airsyncbase:Truncated> </airsyncbase:Body> <calendar:Sensitivity>0</calendar:Sensitivity> <calendar:BusyStatus>2</calendar:BusyStatus> <calendar:AllDayEvent>0</calendar:AllDayEvent> <calendar:Reminder>15</calendar:Reminder> <calendar:MeetingStatus>3</calendar:MeetingStatus> <airsyncbase:NativeBodyType>3</airsyncbase:NativeBodyType> <calendar:ResponseRequested>1</calendar:ResponseRequested> <calendar:AppointmentReplyTime>20110506T165252Z</AppointmentReplyTime> <calendar:ResponseType>3</calendar:ResponseType> </ApplicationData> </Add> <Delete> <ServerId>2:24</ServerId> </Delete> </Commands> </Collection> </Collections> </Sync>
The client must synchronize the Calendar folder after the user accepts or tentatively accepts a meeting request in order for the new Calendar item to appear on the user's Calendar.
Deleting the Calendar item when the meeting is declined
If the user declines the meeting, the Exchange server automatically deletes the corresponding Calendar item. The client must not delete the Calendar item on behalf of the user.
When a user declines a meeting request, the response does not contain a meetingresponse:CalendarId element because the server deletes the corresponding Calendar item.
Sending response notifications
The client sends a notification to the meeting organizer if the user chooses to send a response. The client uses the SendMail command to send the notification. The client should send the email notification only after the MeetingResponse command finishes successfully; otherwise, the invitee's Calendar and the status information that the invitee reports to the organizer will be in conflict. If the ResponseRequested element is set to 0 (zero, meaning false) on the meeting request, the client does not expose an option to the user to send a response notification to the organizer.
The client indicates its response in the subject of the email message, and by using an iCalendar reply command, as shown in the following example.
<?xml version="1.0" encoding="utf-8" ?> <SendMail xmlns="ComposeMail:"> <ClientId>13554</ClientId> <SaveInSentItems/> <Mime> Subject: Accepted: Quarterly Planning From: Bob@contoso.com Content-Type: multipart/alternative; boundary=NextPart To: Alice <Alice@contoso.com> --NextPart Content-Type: text/plain; charset=us-ascii Sure, I will be there! --NextPart Content-Type: text/calendar; charset=utf-8; name=meeting.ics; method=REPLY Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR…<more iCalendar content follows> </Mime> </SendMail>
The following table lists the possible response types.
iCalendar reply method
Accepted: <meeting request subject>
Tenative: <meeting request subject>
Declined: <meeting request subject>
If the organizer makes updates to the meeting, the Exchange ActiveSync client might receive multiple meeting notification email messages. All mail items that are related to the same meeting have the same GlobalObjId element value (for the email notification) and the same UID element value (for the Calendar item). If the Exchange ActiveSync client receives multiple updates that share the same ID, it is important for the client to enable the user to respond to the most recent item only based on the DtStamp element value.
After the invitees have responded to the meeting request, the organizer might want to determine the status of the responses. The organizer can view the responses in the Inbox as they arrive from individual invitees. In addition, the Exchange server automatically parses the invitee responses and updates the Calendar item accordingly. The organizer can view the response status on the Calendar item based on updates from the server to the Exchange ActiveSync client.
Synchronizing meeting responses in the organizer's Inbox
As invitees respond to the meeting request, the organizer's Exchange ActiveSync client runs a Sync command on the Inbox folder to discover the responses, as shown in the following example.
<?xml version="1.0" encoding="utf-8"?> <Sync> <Collections> <Collection> <SyncKey>378940377</SyncKey> <CollectionId>6</CollectionId> <Status>1</Status> <Commands> <Add> <ServerId>6:22</ServerId> <ApplicationData> <email:To>"Alice" <firstname.lastname@example.org></email:To> <email:From>"Bob" <email@example.com></email:From> <email:Subject>Accepted: Quarterly Planning</email:Subject> <email:DateReceived>20110506T165454Z</email:DateReceived> <email:DisplayTo>Alice </email:DisplayTo> <email:ThreadTopic>Quarterly Planning</email:ThreadTopic> <email:Importance>1</email:Importance> <email:Read>0</email:Read> <airsyncbase:Body> <airsyncbase:Type>1</airsyncbase:Type> <airsyncbase:EstimatedDataSize>0</airsyncbase:EstimatedDataSize> <airsyncbase:Truncated>1</airsyncbase:Truncated> </airsyncbase:Body> <email:MessageClass>IPM.Schedule.Meeting.Resp.Pos</email:MessageClass> <email:MeetingRequest> <email:AllDayEvent>0</email:AllDayEvent> <email:StartTime>20110510T17000000Z</email:StartTime> <email:DtStamp>20110506T165252Z </email:DtStamp> <email:EndTime>20110510T180000Z</email:EndTime> <email:InstanceType>0</email:InstanceType> <email:Location>Office</email:Location> <email:Organizer>"Bob " <firstname.lastname@example.org></email:Organizer> <email:Sensitivity>0</email:Sensitivity> <email:TimeZone>4AEAACgAVQBUAEMALQAwADgAOgAwADAAKQAgAFAAYQBjAGkAZgBpAGM AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQwAAAAsAAAABAAIAAAAAAAAAAAAAACgAV QBUAEMALQAwADgAOgAwADAAKQAgAFAAYQBjAGkAZgBpAGMAIABUAGkAbQBlACAAKABVAF MAIAAmACAAQwAAAAMAAAACAAIAAAAAAAAAxP///w==</email:TimeZone> <email:GlobalObjId> BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAATQAAAHZD YWwtVWlkAQAAAEEzNTYxQkRBQUU4RTRCMzBBQzI1NUZEM0YzMUEzQUQ3MDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAA</email:GlobalObjId> </email:MeetingRequest> <email:InternetCPID>20127</email:InternetCPID> <email:Flag /> <email:ContentClass>urn:content-classes:calendarmessage</email:ContentClass> <airsyncbase:NativeBodyType>1</airsyncbase:NativeBodyType> <email2:ConversationId>(Uí©E¯*O»FnÔ</email2:ConversationId> <email2:ConversationIndex>Ì1ë¯��4E</email2:ConversationIndex> <email:Categories /> </ApplicationData> </Add> </Commands> </Collection> </Collections> </Sync>
Note that the ApplicationData container element in the response that is synchronized to the organizer's Inbox contains To and From elements, however, the values of these elements are different than the values in the original meeting request. In the response message, the To element indicates the organizer, because the organizer is the recipient of the response, while the From element indicates the invitee.
The MessageClass and Subject elements indicate the invitee's response to the request, as set by the client. The following table lists the possible values for the MessageClass element.
MessageClass element value
The organizer's Exchange ActiveSync client must synchronize the Calendar folder in order to receive the meeting responses from meeting invitees. The organizer's mailbox uses the Calendar item to reconcile responses to a meeting request with the Calendar event.
Updating the organizer's Calendar item to reflect invitee responses
When the Exchange ActiveSync client synchronizes the organizer's Calendar folder, the original meeting item is updated to reflect any new or updated invitee responses. The client can then display the invitee status to the organizer. The following example shows a change in an attendee, (Bob's), status after he accepts the meeting invitation. Note that the Calendar item shows a value of 3 for the AttendeeStatus element, rather than 0 (zero), which was the value when the request was created and before a response was received.
<?xml version="1.0" encoding="utf-8"?> <Sync> <Collections> <Collection> <SyncKey>124536913</SyncKey> <CollectionId>2</CollectionId> <Status>1</Status> <Commands> <Change> <ServerId>2:9</ServerId> <ApplicationData> <calendar:Attendees> <calendar:Attendee> <calendar:Email>email@example.com</calendar:Email> <calendar:Name>Bob </calendar:Name> <calendar:AttendeeStatus>3</calendar:AttendeeStatus> <calendar:AttendeeType>1</calendar:AttendeeType> </calendar:Attendee> </calendar:Attendees> </ApplicationData> </Change> </Commands> </Collection> </Collections> </Sync>
The following table lists the possible values for the AttendeeStatus element.
AttendeeStatus element value
When the organizer creates the meeting request, the AttendeeStatus element is set to 0 (zero) because invitees have not yet responded. As the response notifications arrive, the organizer’s Exchange server interprets the iCalendar content in the response messages and updates the AttendeeStatus value for each attendee accordingly. An AttendeeStatus value of 5 indicates a problem with interpreting the invitee response.
Exchange ActiveSync does not handle responses involving new time proposals. New time proposals appear as tentative or decline responses to the Exchange ActiveSync client. The new time proposal may be indicated in the subject line or the body of the message, depending on the client that the invitee uses to send the proposal.
After an invitee responds to a request, the Exchange server deletes the meeting request from the invitee's mailbox. This helps to ensure that the invitee does not send multiple responses to the same meeting request that might conflict with one another. If the invitee does send multiple responses to the meeting request (for example, by responding from the Calendar item rather than the meeting invitation), the Exchange server automatically updates the organizer's Calendar item to reflect the most recent meeting response status.
The ability to respond to meeting requests is a critical element of a successful calendaring experience for Exchange ActiveSync client users. When you develop Exchange ActiveSync client applications, make sure that you handle iCalendar meeting responses correctly. Keep in mind that your applications should not process incoming iCalendar meeting requests on the client; meeting requests should be processed by the Exchange server.