none
Exchange 2013 Allows Room/Resource Double Booking (By Design!)

    General discussion

  • Since upgrading to Exchange 2013 we have noticed a significant increase in users complaining about room double bookings.  After a fair bit of testing we were able to narrow the behaviour down to a reproducible scenario.

    First things first - we have AllowConflicts set to false on all room and resource mailboxes, so that is not the issue.

    The problem manifests if the start date of a recurring meeting series is more than six months in the past.

    This is the scenario which we can reproduce:

    1. Find (or create) a meeting room which is configured to not allow booking conflicts (AllowConflicts:False)
    2. Book one or more meetings in the room (or look for existing meetings)
    3. Create a recurring meeting (or use an existing meeting) with a start date which is more than six months in the past which will conflict with one or more of the bookings created or found in step 2.

    The room will accept all instances of the new recurring meeting, even those which conflict with other bookings.

    A variation of the scenario is to extend an existing recurring meeting series:

    1. Find (or create) a meeting room which is configured to not allow booking conflicts (AllowConflicts:False)
    2. Find (or create) a recurring meeting with a start date which is more than six months in the past and which will end soon.
    3. Book one or more meetings in the room in the same time slot as the recurring meeting for dates past the end of the recurring meeting series.
    4. Extend the recurring meeting from step 2 past the meetings from step 3.

    The room will accept all instances of the extended meeting series, even those which conflict with other bookings.

    This is new behaviour in Exchange 2013 - in Exchange 2010 these scenarios worked and Exchange didn't allow double bookings.

    We opened a case with Microsoft and were eventually told that this new behaviour is 'by design'.  We even appealed to the customer advocacy group and the Exchange product team still refuse to acknowledge this as a bug.  As a workaround  it was suggested that we reduce the booking window horizon to 180 days, but this does not resolve the issue. 

    We are not happy; our users are not happy.

    I'm posting here to share our findings with other Exchange users who may be seeing this issue, and to ask you to please share your experience and, if possible, contact Microsoft so that the product group might reconsider their position on this behaviour.

    Ben Lye


    • Changed type Ben Lye Thursday, January 29, 2015 10:10 AM
    • Edited by Ben Lye Thursday, January 29, 2015 12:22 PM
    Thursday, January 29, 2015 10:10 AM

All replies

  • So it seems like I should have been a little clearer - the scenarios above are for reproduction.  I know that nobody normally creates a recurring meeting with the start date in the past - that step was just to emulate an existing meeting which was created more than six months ago.

    The current explanation from Microsoft is that Exchange 2013 only checks the first six months of a recurring meeting series for conflicts, so another way to encounter (or reproduce) this issue is this:

    1. Find (or create) a meeting room which is configured to not allow booking conflicts (AllowConflicts:False)
    2. Book a new recurring meeting which starts today and has an end date at least six months in the future.
    3. Create a new single meeting instance in the same time slot as the recurring meeting, but after the end of the recurring meeting series.
    4. Extend the meeting series beyond the date of the single meeting instance

    The room will accept the update to the series and the room will be double booked.

    Ben


    • Edited by Ben Lye Thursday, February 12, 2015 10:17 PM
    Thursday, February 12, 2015 3:47 PM
  • In case you might be wondering if you have this problem or not, or you want to know how bad the problem is,

    I've put a script for auditing meeting rooms for double bookings over on my blog.

    Ben Lye
    Friday, February 13, 2015 2:11 PM
  • FWIW, Microsoft has committed to fix this bug in an upcoming CU.  It will not make it into CU8, however.

    Adam

    Monday, March 02, 2015 8:57 PM