Recurring Meeting Requests with Conflicting Instances 2: The Power of Delegates
Published Jan 23 2012 11:06 AM 85.2K Views

The key takeaway from my last post on this topic was that the Resource Booking Assistant never allows double booking of a resource room calendar as a result of a recurring meeting request (please see Automatic Processing of Recurring Meeting Requests with Conflicting Instances).

Since there are times that an administrator may want to allow double-booking, we offered two workarounds that I’d like to address in a bit more depth. I'd also like to offer a third one that wasn’t mentioned before:

1) Send Follow-Up Nonrecurring Meeting Requests to Double Book

Recall that if a recurring meeting series is accepted individual conflict notifications will be emailed to the organizer in addition to the acceptance email for the series. The organizer can use those declined-instance emails as a reference for following the first of our workarounds, which would be to send additional non-recurring meeting requests to double-book the intended resource room for each declined instance.

This method, though laborious, allows fine control over when a resource is double booked and when not.

Suppose on the other hand an administrator follows the second workaround, and hands control to a trusted delegate instead of the Resource Booking Assistant? A delegate has the human discretion to allow all recurring meeting conflicts to double book by accepting an entire recurring meeting series. It also turns out a delegate can selectively decline any number of conflicting instances while accepting the series, something the assistant cannot. The question came up about how exactly they can do this, so let’s take a look:

2) Allow a Delegate to Double Book Resources

The request policy on a resource mailbox can be configured to require delegate control over resolving recurring meeting request instance conflicts. But how exactly do they use that power? What might the process look like, and what tools can they use carry it out? The best functionality for this is in Outlook 2010.

Let’s go to an example. Say we have a resource room, called Green Room, which is managed by a delegate named Howard. As meeting requests for the Green Room come in Howard accepts them for the room calendar. Presently there’s a meeting scheduled for 2PM on Wednesday, and another for 3PM on the following Thursday.

Now a new recurring meeting request with the Green Room as the room resource goes out to several recipients. The room’s request policy requires Howard to approve all meeting requests, so this new one gets forwarded to him. We see that the recurring meeting request is for four instances, Tuesday through Thursday, from 2:30PM - 3:30PM each day. Outlook helpfully points out (highlighted in yellow and also below the Calendar Preview) that two of the four instances conflict with the existing appointments:


If Howard wishes to accept the entire series, and allow double booking he can just accept the whole thing. But what if he wants to decline one conflict, but allow the other? Howard can click on the arrow next to “Conflicts: 2” and get a preview of each area of the calendar where conflicts overlap with an existing appointment.

He does so, and sees the first conflict is with the Wednesday, 2PM Catalog Review meeting:


The second is with the Sales Presentation meeting on Thursday:


Suppose Howard wishes to decline the double booking on Thursday, but let the Wednesday conflict get booked? To decline the Thursday instance he can simply double-click on the item in the Calendar Preview section of the forwarded meeting request.

That action will open up a view for that time from the Green Room’s calendar. Howard can then right click on the instance that he wishes to decline, go to the Decline menu item, then select an option to decline just this occurrence:


Now that Howard has determined which instance to decline and which to allow he can simply go back to the original forwarded meeting request, and accept the series. This will accept all the remaining instances while preserving the manually declined instances:


So to summarize a delegate's power in this area, they can use the conflict notifications provided in Outlook 2010 to quickly decline (or accept) individual occurrences of a recurring meeting request.

3) Send a Series Update Without Changing Details

There is a third known way of working around the Resource Booking Assistant’s refusal to double book a room due to a recurring meeting request. Thanks to feedback from a customer relayed to me by my colleague Patriciu Seliceanu, we now know that a meeting organizer can simply send an update for a recurring meeting but without changing any details. The amazing result is that conflict instances declined before are then accepted. This workaround of course requires that conflicts be allowed for single-instance meeting requests, which by default is enabled in virtue of the AllowConflicts attribute set to "True" for calendar processing settings.

The update to the recurring meeting works because each recipient receives not another recurring meeting request, but an update meeting request (with no actual changes) for each individual instance. Since Exchange sees much the same as the single-instance meeting requests from workaround method 1 above it allows double-booking for each updated instance. This may save a bit of labor over the steps required in item 1 of this list, such as when the number of conflicts is high, and assuming every conflict should be double booked.

In conclusion, there are a number of ways to work around the safety mechanism inherent in the Resource Booking Assistant which prevents recurring meeting request from double-booking a resource mailbox. The most robust and powerful of these is the intrepid delegate with Outlook 2010 at their fingertips and Exchange 2010 at the ready. Please note though that for the majority of cases, you should not even have to worry about doing this, as in most cases, the default behavior is the correct one.

Thanks to Tom Kern for his help and counsel, and to Patriciu Seliceanu for method 3.

Jesse Tedoff

Version history
Last update:
‎Jan 23 2012 11:06 AM
Updated by: