Thursday, May 13, 2010

Understanding Auto Accept Agent



 
This topic defines what Auto Accept Agent does, and explains how Auto Accept Agent processes meeting requests.
Auto Accept Agent is an asynchronous store event sink that provides automatic server-side processing of meeting requests that are sent to resource mailboxes. Auto Accept Agent raises the OnSave event when an e-mail message is delivered to the Inbox of a registered resource mailbox. Meeting requests, updates, and cancellations are processed in a first-in, first-out order. If the e-mail message is not a calendar item, Auto Accept Agent may delete it, based on the setting for the DeleteNonCalendarItems parameter, to keep the Inbox clear of read e-mail messages. If the request is a cancellation, the meeting is removed from the calendar.

When a meeting request is delivered to an Inbox folder in the Exchange store, an OnSave event occurs. If Auto Accept Agent has been registered for that mailbox, the occurrence of the OnSave event triggers the agent (an ExOLEDB event sink). The following figure shows the basic process flow, starting when an e-mail message is delivered to an Inbox.
Auto Accept Agent process flow
Auto Accept Agent process flow

Scheduling and Updating

When Auto Accept Agent processes meeting requests, it checks the availability of the resource's calendar (not the resource's published free/busy data) and then sends an accept or decline message to the meeting organizer. The agent evaluates only meetings that occur within a specified booking window for conflicts. The agent does not place any meeting instances that occur beyond the booking window in the resource's calendar. After it processes the request, Auto Accept Agent saves a copy of the response to the Sent Items folder and then moves the original request from the Inbox to the Deleted Items folder. The following figure shows the logic that Auto Accept Agent follows when it processes a calendar request.
Calendar request process flow
Calendar request process flow
Auto Accept Agent uses the following scheduling logic for scheduling single and recurring meeting requests.

Single Meeting Requests

Auto Accept Agent accepts or declines new or updated meeting requests for single meetings based on the following criteria:
  • If the entire span of time between the start and end times of the meeting request is marked as free on the resource calendar, the meeting request is accepted.
  • If any part of the span of time between the start and end times on the meeting request is marked as busy or tentative on the resource calendar, the meeting request is declined.
  • If a meeting update is requested that overlaps the time of the original meeting, Auto Accept Agent does not consider the time of the original meeting as busy and allows the update to be processed. For example, if you schedule a meeting from 15:00 to 16:00 on Friday and then send an update to reschedule this meeting from 15:30 to 16:00 on Friday, Auto Accept Agent accepts the update even though the resource appeared as busy.

Recurring Meeting Requests

Auto Accept Agent expands, accepts, and declines recurring meeting requests according to the following parameters:
  • If a recurring meeting request does not contain an end date or contains an end date beyond the specified booking window, by default Auto Accept Agent declines the request. If you set the EnforceRecurringMeetingEndDate parameter to False, Auto Accept Agent expands and schedules meeting instances up to the maximum allowed number of months that are contained in the BookingWindowInMonths parameter. However, because the recurrence will be truncated to the limit set by BookingWindowInMonths, the end date on the organizer's calendar could be different from the end date on the resource mailbox's calendar.
  • The RecurringMeetingConflictPercentageAllowed parameter sets a threshold for the amount of rescheduling required by the organizer when individual instances are declined because of a conflict. It does not enable double-booking.
  • The RecurringMeetingMaximumConflictInstances parameter sets a threshold for the number of conflicts allowed for a recurring meeting before the agent declines the request. This parameter works together with the RecurringMeetingConflictPercentageAllowed parameter, with the lower of the two thresholds determining whether the meeting request is accepted or declined. For example, if you set the RecurringMeetingConflictPercentage parameter to 25 percent and set the RecurringMeetingMaximumConflictInstances parameter to two, and then send a meeting request with four instances of a meeting, a maximum of one instance could conflict for the meeting request to be accepted. In this case, the 25 percent threshold for four instances allows only one conflict, even though you have set the maximum number of conflicts that are allowed to two.
    The default value for both RecurringMeetingConflictPercentageAllowed and RecurringMeetingMaximumConflictInstances is zero. To allow for conflicts, you must change both of these parameters.

No comments:

Post a Comment