The story of overbooked conference rooms

This article was first published at pr itk and has been viewed around 10,000 times.

Reading time: 18 minutes

Last update 1 year ago by Patrick Ruppelt

This article basically refers to the constellation in which users access an Exchange Server 2007 (or in some cases other Exchange versions) with their Outlook client (Outlook 2010, Outlook 2007, Outlook 2003).

Exchange offers the option of defining resources. A whole range of resources are already available, as well as room resources, i.e. rooms. It's great if the user simply enters a new appointment in their diary, invites the participants and selects a corresponding room as a resource. If the room is occupied, the user can already see this in the timeline that comes with an up-to-date Office Outlook. Just like the other users are used to.

Now, however, it should actually happen that at the same time two teams stand in front of the same meeting room and both claim that the appointment has been entered and confirmed in their calendars. Is that not possible? One of them is lying? No! It is possible. Exchange can actually give two teams the impression that they have both booked a room and that the room is actually entered as booked in both of their calendars. Exciting, isn't it...?

To get to the bottom of the cause, you have to delve a little deeper into the matter. The whole thing is not quite as trivial as it looks at first. The management of resources - if I may say so as a non-technician - actually follows a fairly stringent logic. On the one hand, it is technical in that the individual parameters are Boolean in nature. On the other hand, the intention that the administrator pursues when parameterising also follows Boolean rules.

My train of thought is a little confused, I'll illustrate this with a few extracts from a - yes, almost pamphlet - by Murat Gunyar. In the Exchange Team blog, he has written a wonderful Article which I find extremely instructive, informative and at times absurdly funny. Although the absurdity stems more from the fact that technology is only as good as it is developed. I quote:

Note: When the Set-MailboxCalendarSettings cmdlet is re-run to modify any settings the original delegate's permissions are removed. The delegate is still displayed when running the 'Get-MailboxCalendarSettings' cmdlet. However, if you look at the permissions on the resource calendar, the delegate's permissions have been removed.

This means the following: You set new parameters in the Powershell, e.g. because you want to change something small. However, this does not work so easily, because Set-MailboxCalendarSetting simply overwrites all previous settings with the new one. So there is no "add" but a "replace". This may be one of the subtleties that every Exchange admin knows. Well, if you're not an admin you don't need to know it, but I still find it interesting for all those who are simply reading this article out of interest or curiosity. Back to the topic. So there will be a "replace". Good. What happens next? The command is executed as it is intended, the old authorisations, for example, no longer exist.

What does this have to do with an overbooked calendar? Well, there is the command Get-MailboxCalendarSettingswhich - wonder why - displays the settings. Unfortunately, this command again shows not shows the changed settings. To see these, you have to look at the authorisations in the resource's calendar. And let's be honest: which admin does that...?

OK, admittedly this doesn't have much to do with overbooked calendars, but we're getting a bit closer. Because we have now reached a fairly central point in the Exchange Server and can start looking for possible causes.

New-Mailbox -database "Storage Group 1Mailbox Database 1" -Name ConfRoom1 -OrganisationalUnit "Conference Rooms" -DisplayName "ConfRoom1" -UserPrincipalName ConfRoom1@contoso.com -Room

This would be a simple example directly from the Microsoft TechNet on the subject of "how do I create a room mailbox". But when do I ever sit with a customer, have the phenomenon of overbooking and can sit down comfortably and simply create the mailboxes myself? I could have done that yesterday at my customer's premises - where exactly this problem occurred - with over 3,000 users and I don't know how many conference rooms. Have fun.

So next attempt - let's check how the rooms are set up. It actually helps to find out which rooms are affected. But the user who reported the error is usually unable to tell you this. They don't know themselves, because they have so many other things to deal with every day, why should they care about IT? Solution: run grep on all resources including all relevant flags, stuff everything into an Excel file and then analyse it. Analyse? How, that is the question.

Phase 1: Which mailboxes are actually rooms? The rooms are not always called that. The list should first of all be complete so that the research makes any sense at all. Everything that is a -room can't be all that wrong. After all, there are many roads that lead to Rome. There are also equipment mailboxes - and a confi can in principle also be seen as such. You can also realise rooms via shared mailboxes, or create your own users for them and use them as a group mailbox with a calendar. But the big thing is that the giant from Redmond has usually thought of something when it offers wizards and special functions that can do exactly what you want.

Phase 2: So now we have rooms. How these behave depends on the parameters set. Microsoft also has a fairly extensive list of these in the TechNet but that's probably going a bit too far for a blog that calls itself a social techblog from an economic point of view. So here's my summary, which basically outlines the principle of how and why spaces behave independently. The dog must be buried somewhere here.

Parameter important number 1: AutomateProcessing

This parameter regulates how

• None: Both resource booking and the calendar attendant, which automatically enters new meetings in the calendar, are both deactivated on this resource. In other words, neither of them do anything and all requests remain in the resource mailbox until the day after tomorrow.
• AutoUpdate: The default value accepts all requests with reservations and then waits for the appointment to be confirmed by the delegate. The organiser of the meeting receives the information from the delegate.
• AutoAccept: And this is where it gets really exciting. The resource is booked at room mailbox level. Incoming requests are processed on the basis of stored policies (guidelines). In this mode - and only in this mode - the meeting organiser actually receives the confirmation from the room itself.

So far this sounds plausible and logical, at least once you have thought about how you would best implement something like this yourself. But how should an AutoAccept work so that it actually produces acceptable results in practice? There is also a completely different parameter which, on the flipside, is not entirely innocent of the fact that rooms can be overbooked.

Number 2: Resource booking policies

Here, too, I am only providing a very brief summary, so please do not stone me for perhaps not 100% correct technical details. The policies define an "InPolicy" status, i.e. compliant, and an "OutOfPolicy" status, i.e. not authorised. Permitted or not can be defined by time slots (meetings only within working hours), overbooking (yes/no and yes, oha, you can also define that overbooking is permitted. But that would be really trivial as a reason for overbooking), duration (duration, i.e. how long the meeting is - e.g. all meetings over 2 hours require the authorisation of the line manager) etc..

And to make the story really confusing - no, actually just to make it practicable - a distinction is made again at this point:

• BookInPolicy: This list of users (groups, AD, ...) may enter InPolicy meetings and these are also automatically accepted.
• RequestInPolicy: Similar to BookInPolicy, but an approval by the delegate is required for the booking to be confirmed.
• RequestOutOfPolicy: The scheme looks a little different here, these users are allowed to request any crap and if the delegate approves it, then it's fine. I guess Microsoft introduced this option for works councils, board members and management. Or for workaholics who naturally still sit in the meeting room on Sundays.

Now we have come so far that it makes sense to think again about how overbooking can occur. Murat has drawn a conclusion in his blog post in the form of a table of sensible options. I recommend reading this article there too, because it's really good.

The fact is - what makes sense?

• Automatic Booking: AutoAccept > AllBookIn True > AllRequestIn False. Delegate: none
• Manual Approval: AutoAccept > AllBookIn False > AllRequestIn True. Delegate: should be defined
• Manual Approval: AutoUpdate > AllBookIn True > AllRequestIn False. Delegate: none

It's not so easy to get to the heart of the matter, as the question has often been asked on TechNet. At this point, the technology stops and logic is required!

If you now analyse your hundreds of conference rooms, you will always find some that perhaps do not originate from the current Exchange Server but were taken over from a 2003 server. Here the resources also looked different. Or even from an even older Exchange? Or someone else has created the accounts, or they are simply parameterised differently in some way.

Here is an example to show what happens when you disregard logic - which can ultimately lead to exciting things such as a double booking by a technical system. The interesting thing is that you only have to look at it from this perspective once and consider what is actually "most likely to happen". There are a whole series of constellations that can lead to something going wrong. must.

Take case 1: AutoAccept > AllBookIn True > AllRequestIn False. Delegate: none

Let's set AllBookIn as False. What happens? Someone wants to schedule an appointment. Regardless of which BookIn list they are in, there is no delegate who could approve anything. They are also not allowed to register regularly, and certainly not as a RequestIn. What happens in practice: The best case of incorrect booking: an error message stating that the rights are not sufficient to book this appointment.

Case 2: Let's take a really bad case - Manual Approval: AutoAccept > AllBookIn False > AllRequestIn True. Delegate: should be defined, but is not

And now comes the case that actually combines so many coincidences that it is both exciting to see the result and extremely difficult to directly identify the cause in practice. What happens is this:

• Employee 1 enters an appointment. AllBookIn false therefore causes AutoAccept to only provisionally confirm the appointment. The organiser receives an email in their mailbox stating that the appointment has been provisionally confirmed. The appointment is shown as booked in the employee's calendar. In the appointment details, you can also see your own time and that of the participants as booked. You can also see the conference room in the timeline. Dubiousness: The Outlook display at this point seems to be inconsistent, or it has to do with your own display settings. The fact is: As a user, you cannot see that the room itself is still set to "under reservation".
• Employee 2 enters an appointment. I could now copy the text from employee 2. The fact is that everything looks perfect but isn't. In fact, I have to admit that my title may be a little misleading, because Exchange has not booked two appointments at the same time. But for the users, everything really does look right - for both teams. We tested this for a few hours and were able to reproduce it in all conceivable constellations.

What happens now? Because the trail of dubiousness is far from over. Both employees return to work and think nothing of it.

All the employees invited to both dates assume that the date will fit anyway, after all there are an organiserwho will take care of it.

The date is firmly booked in all calendars. In order to even see - if you were to explicitly search for it - that something doesn't fit, you would have to as organiser look at the appointment details and drag the timeline on a monitor at least 22″ wide so that you can see the small hatching on the room that it has not yet been confirmed. The employees see - Dubiousness number X - the room as booked. And as firmly booked. I assume that the participants see this status in this way (and therefore assume that everything fits perfectly) because they do not see their own room status at all, but only that the room has been booked in principle. But by the team that was there first. In other words: The invited participants of Meeting 2 have definitely not received a cancellation and can see the date, participants and room in all their calendars. The invited participants of Meeting 1 see exactly the same thing, but presumably they actually see the booked status of the room themselves.

So far so good. It's all a bit strange, but if the parameters were stored correctly, this state would not last too long. This is actually where a delegate comes into play. It receives the conflict in its mailbox, because as a delegate it works as a representative of the room and has to make a decision.

By the way - an interesting aside: even if this is the case and he sends a cancellation, the organiser of the appointment still has to act. This does not change anything in the calendar entries of all those involved! In other words: yet another supposed double booking. Dubious.

Back to the actual topic. The delegate is not entered, the mail for the decision is stuck in the room's queue and no escalation is planned. So nothing happens.

What is envisaged in such a case? Nothing. This is because the set of rules implemented by the administrator is logically misconceived. Such a process should never occur. And that means in plain language: both organisers have received a provisional commitment. There was never a cancellation. And everything looks correct in all the calendars. Ergo: Both teams will be in the same place at the same time and both are equally right. Dubious.

And we are still not at the end - I still have one curiosity in store. Most customers have not just been using Exchange since yesterday, but have also been using previous versions. It was the order of the day that there was one or more employees in each department who took care of the calendars in the conference rooms. These were usually simply opened as an additional mailbox, and even then this overbooking would no longer occur. But that's not how it's supposed to work. Of course, it works, but only as long as the calendar is open somewhere - as the "owner", so to speak. If the employee leaves the company, that's it. Such a case is never actually documented, at least not in 15 years... And then? Then you have an orphaned conference room that has apparently worked for years (although incorrectly configured) and then "suddenly" no longer does its job and allows overbooking.

Not dubious: As always, the fault lies with people.