Die Geschichte überbuchter Konferenzräume

Dieser Artikel wurde erstmals bei pr itk veröffentlicht und dort rund 10.000 Mal aufgerufen.

Lesedauer: 18 Minuten

Letzte Aktualisierung vor 1 Jahr durch Patrick Ruppelt

Dieser Artikel bezieht sich im Grunde genommen auf die Konstellation, in der User mit Ihrem Outlook Client (Outlook 2010, Outlook 2007, Outlook 2003) auf einen Exchange Server 2007 (oder in Teilen auch auf andere Exchange Versionen) zugreifen.

Exchange bietet die Möglichkeit, Ressourcen zu definieren. Eine ganze Reihe von Resourcen sind schon vorgefertigt vorhanden, so wie auch Raum-Ressourcen, sprich: Räume. Eine super Sache, wenn der Benutzer in seinem Terminkalender einen neuen Termin einfach einträgt, die Teilnehmer einlädt und als Ressource einen entsprechenden Raum auswählt. Ist der Raum belegt, so sieht der Benutzer dies ja bereit in der Timeline, die ein aktuelles Office Outlook mit sich bringt. Genau so, wie man es von den anderen Benutzern auch gewohnt ist.

Nun soll es aber tatsächlich vorkommen, dass zum selben Zeitpunkt zwei Teams vor ein und demselben Besprechungsraum stehen und beide behaupten, bei Ihn sei der Termin aber im Kalender eingetragen und bestätigt. Geht nicht? Einer lügt? Nein! Geht wohl. Exchange kann tatsächlich zwei Teams den Eindruck vermitteln, sie hätten beide einen Raum gebucht und der steht auch wirklich in deren beider Kalender eingetragen als gebucht. Spannend, nicht wahr…?

Um der Ursache auf den Grund zu gehen muss man schon ein wenig tiefer in die Materie einsteigen. Ganz so trivial, wie es am Anfang aussieht, ist die ganze Sache nämlich gar nicht. Die Verwaltung der Ressourcen erfolgt – wenn ich das einmal als Nicht-Techniker so sagen darf – eigentlich einer ziemlich stringenten Logik. Einerseits technischer Natur insofern, dass die einzelnen Parameter boolescher Natur sind. Anderseits insofern, dass auch die Intention, die der Administrator beim Parametrieren verfolgt, booleschen Regeln folgt.

Mein Gedankengang ist etwas wirr, ich veranschauliche das anhand einiger Auszüge aus einem – ja, fast schon Pamphlet – von Murat Gunyar. Er hat im Exchange Team Blog einen wunderbaren Artikel verfasst, der wie ich finde äußerst lehrreich, informativ und stellenweise absurd komisch ist. Wenngleich die Absurdität eher daher rührt, dass Technik nun einmal maximal so gut ist, wie sie entwickelt wurde. Ich zitiere:

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.

Soll soviel heißen wie folgt: Man setze in der Powershell neue Parameter, z. B. weil man eine Kleinigkeit ändern möchte. Das funktioniert aber nicht so einfach, denn Set-MailboxCalendarSetting überschreibt einfach alle vorherigen Einstellungen mit der neuen. Es erfolgt also kein „add“ sondern ein „replace“. Dies mag zu den Finessen gehören, die jeder Exchange Admin kennt. Gut, wenn man kein Admin ist muss man es ja nicht wissen, aber ich finde es dennoch interessant auch für all diejenigen, die diesen Artikel einfach nur aus Interesse oder Neugier lesen. Zurück zum Thema. Es erfolgt also ein „replace“. Gut. Und weiter? Der Befehl wird so wie er gedacht ist ausgeführt, die alten Berechtigungen beispielsweise existieren dann nicht mehr.

Was hat das mit einem überbuchten Kalender zu tun? Nun, es gibt den Befehl Get-MailboxCalendarSettings, der – wonder why – die Einstellungen anzeigt. Nur leider zeigt dieser Befehl wiederum nicht die geänderten Einstellungen an. Um diese zu sehen, muss man sich die Berechtigungen im Kalender der Ressource ansehen. Und nun einmal ganz ehrlich: Welcher Admin tut das schon…?

O. k., zugegeben, das hat auch noch nicht viel mit überbuchten Kalendern zu tun, aber wir kommen der Sache schon ein Stück näher. Denn: jetzt sind wir schon an ziemlich zentraler Stelle im Exchange Server angelangt und können uns auf die Suche nach möglichen Ursachen machen.

New-Mailbox -database „Storage Group 1Mailbox Database 1“ -Name ConfRoom1 -OrganizationalUnit „Conference Rooms“ -DisplayName „ConfRoom1“ -UserPrincipalName ConfRoom1@contoso.com -Room

Das  wäre ein einfaches Beispiel direkt aus dem Microsoft TechNet zum Thema „wie erstelle ich eine Raum-Mailbox“. Aber wann sitze ich schon einmal beim Kunden, habe das Phänomen der Überbuchung und kann mich gemütlich hinsetzen und die Postfächer einfach selber neu anlegen. Hätte ich gestern bei meinem Kunden – wo genau dieses Problem aufgetreten ist – ja einmal mit über 3.000 Benutzern und ich weiß nicht wie vielen Konferenzräumen machen können. Viel Spaß.

Also nächster Versuch – prüfen wir einmal nach, wie die Räume eingerichtet sind. Hier hilft eigentlich schon einmal herauszufinden, welche Räume davon betroffen sind. Aber das kann einem der Benutzer, der den Fehler gemeldet hat, in aller Regel nicht mitteilen. Er weiß es selber nicht, denn er kümmert sich Tag für Tag um soviel anderes, was sorgt ihn die IT? Lösung: grep über alle Ressourcen mitsamt aller relevanter Flags laufen lassen, alles in ein Excel File stopfen und dann auswerten. Auswerten? Wie, das ist die Frage.

Phase 1: Welche Mailboxen sind überhaupt Räume. Nicht immer heißen die Räume auch so. Die Liste sollte zunächst einmal vollständig sein, damit die Recherche überhaupt Sinn ergibt. Alles, was ein -room ist, kann schon einmal nicht sooo verkehrt sein. Es gibt nähmlich viele Wege, die nach Rom führen. Es gibt auch equipment mailboxes – und ein Konfi kann ja im Prinzip auch als solches gesehen werden. Auch kann man Räume über Shared Mailboxen realisieren, oder eigene Benutzer dafür anlegen und diese wiederum als Gruppenpostfach mit Kalender missbrauchen. Das große aber: Meist hat sich der Riese aus Redmond schon etwas dabei gedacht, wenn er Wizards und spezielle Funktionen anbietet, die genau das können was man möchte.

Phase 2: Nun haben wir also Räume. Wie sich diese verhalten, das hängt von den gesetzten Parametern ab. Auch hierzu hat Microsoft eine ziemlich umfangreiche Liste im TechNet bereitgestellt, aber das führt wohl etwas zu weit für einen Blog, der sich social techblog from an economic point of view nennt. Daher an der Stelle meine Zusammenfassung, die grundlegend das Prinzip darstellt, wie und wieso sich Räume selbständig verhalten. Irgendwo hier muss ja wohl der Hunde begraben liegen.

Parameter wichtig Nummer 1: AutomateProcessing

Dieser Paramter regelt, wie

• None:  Sowohl Ressourcenbuchung als auch der sogenannte Calendar Attendant, der neue Meetings im Kalender automatisch einträgt, sind beide auf dieser Ressource deaktiviert. Soll heißen, beide tun nichts, alle Anfragen bleiben in der Ressourcenmailbox liegen bis zum Sanktnimmerleinstag.
• AutoUpdate: Der default Wert sagt allen Anfragen unter Vorbehalt zu und wartet dann darauf, dass der Termin vom delegate bestätigt wird. Der Organisator des Meetings bekommt die Info vom delegate.
• AutoAccept:  Und hier wird es dann wirklich spannend. Das Buchen der Resource erfolgt auf Raum Mailbox Ebene. Anhand hinterlegter Policies (Richtlinien) werden die eingehenden Anfragen bearbeitet. In diesem Modus – und nur in diesem Modus – erhält der Organisator des Meetings  die Bestätigung tatsächlich vom Raum selber.

Soweit klingt das einleuchtend und logisch, zumindest sobald man sich darüber Gedanken gemacht hat, wie man so etwas selber am besten umsetzen würde. Doch wie soll ein AutoAccept funktionieren, so dass es in der Praxis auch wirklich annehmbare Resultate hervorbringt? Dazu gibt es noch einen ganz anderen Parameter, der auf der Kehrseite nicht ganz unschuldig daran ist, dass man Räume überbuchen kann.

Nummer 2: Ressource booking policies

Auch hier liefere ich nur eine ganz knappe Zusammenfassung, man möge mich bitte nicht für vielleicht nicht 100% korrekte technische Angaben steinigen. Die Policies definieren einen Status „InPolicy“, das heisst konform, sowie einen Status „OutOfPolicy“, also nicht zugelassen. Zugelassen oder nicht kann sich definieren durch Zeitfenster (Meetings nur innerhalb der Arbeitszeiten), Überbuchung (ja/nein und ja, oha, man kann auch durchaus definieren, dass eine Überbuchung zugelassen ist. Aber das wäre als Ursache für Überbuchung nun wirklich trivial), Duration (Dauer, also wie lange das Meeting ist – z. B. bedürfen alle Meetings über 2 Stunden der Erlaubnis des Vorgesetzten) usw..

Und um die Geschichte auch so richtig verwirrend zu machen – nein eigentlich nur, um es praktikabel zu machen, wird an der Stelle noch einmal unterschieden:

• BookInPolicy: Diese Liste von Benutzern (Gruppen, AD, …) dürfen InPolicy Meetings eintragen und diese werden auch automatisch akzeptiert.
• RequestInPolicy: Ähnlich wie BookInPolicy, allerdings ist ein Approval durch den delegate nötig, damit die Buchung bestätigt wird.
• RequestOutOfPolicy: Hier sieht’s dann wieder etwas anders mit dem Schema aus, diese Benutzer dürfen auf gut deutsch jeden Mist anfragen und wenn der delegate diesen genehmigt, dann ist auch gut. Ich schätze, Microsoft hat diese Option für Betriebsräte, Vorstand und Geschäftsführung eingeführt. Oder für Workaholics, die naturgemäß auch Sonntag noch im Besprechungsraum hocken.

Jetzt sind wir so weit vorgedrungen, dass es Sinn macht, sich noch einmal zu überlegen, wie es zu einer Überbuchung kommen kann. Murat hat in seinem Blogeintrag eine Schlussfolgerung in Form einer Tabelle über die sinnvollen Möglichkeiten aufgestellt. Ich empfehle, diesen Artikel dort auch zu lesen, denn er ist wirklich gut.

Fakt ist – was macht Sinn?

• Automatic Booking: AutoAccept > AllBookIn True > AllRequestIn False. Delegate: keine
• Manual Approval:   AutoAccept > AllBookIn False > AllRequestIn True. Delegate: sollte definiert sein
• Manual Approval:   AutoUpdate > AllBookIn True > AllRequestIn False. Delegate: keine

Es ist gar nicht so einfach auf den Punkt zu bringen, denn auch im TechNet wurde die Frage schon häufig gestellt. An diesem Punkt setzt die Technik aus und die Logik ist gefragt!

Wenn man jetzt sein hunderte Konferenzräume auswertet wird man immer irgend welche finden, die vielleicht nicht vom aktuellen Exchange Server stammen sondern aus einem 2003er übernommen wurden.  Hier sahen die Ressourcen nämlich auch noch anders aus. Oder aus gar aus einem noch älteren Exchange? Oder jemand anders hat die Konten angelegt, oder wie auch immer geartet sind diese einfach anders parametriert.

Ein Beispiel soll hier zeigen, was passiert, wenn man die Logik außer Acht lässt – und damit so am Ende doch wieder spannende Dinge hervorrufen kann wie eine doppelte Buchung durch ein technisches System. Das interessante ist, dass man es eigentlich nur einmal von dieser Seite her betrachten und sich überlegen muss, was denn eigentlich „most likely to happen“ ist. Es gibt eine ganze Reihe von Konstellationen, die ursächlich dazu führen, dass irgend etwas schief gehen muss.

Nehmen wir Fall 1: AutoAccept > AllBookIn True > AllRequestIn False. Delegate: keine

Stellen wir AllBookIn als False an. Was passiert? Jemand möchte einen Termin planen. Unabhängig davon, in welcher  BookIn Liste er steht, es gibt keinen delegate, der irgend etwas genehmigen könnte. Er darf sich auch nicht regulär eintragen, und erst recht nicht als RequestIn. Was passiert in der Praxis: Der beste Fall der Fehlbuchung: eine Fehlermeldung, die besagt, dass die Rechte nicht ausreichen, um diesen Termin zu buchen.

Fall 2: Nehmen wir dagegen mal einen richtig üblen Fall –  Manual Approval:   AutoAccept > AllBookIn False > AllRequestIn True. Delegate: sollte definiert sein, ist es aber nicht

Und jetzt kommt der Fall, der tatsächlich so viele Zufälle miteinander vereint, dass es gleichwohl spannend ist das Resultat zu sehen als auch ungemein schwierig, die Ursache in der Praxis direkt auszumachen. Was passiert ist folgendes:

• Mitarbeiter 1 trägt einen Termin ein. AllBookIn false also bewirkt AutoAccept erst einmal nur eine vorläufige Zusage. Der Organisator bekommt hierzu eine E-Mail in sein Postfach in der steht, dass der Termin vorläufig bestätigt wurde. Der Termin steht im Kalender des Mitarbeiters als gebucht. In den Termindetails sieht man auch seine eigene Zeit sowie die der Teilnehmer als gebucht. In der Zeitleiste sieht man auch den Konferenzraum. Dubiosität: Die Outlook Anzeige an dieser Stelle scheint inkonsistent zu sein, oder es hängt mit den eigenen Anzeigeeinstellungen zusammen. Fakt ist: Dass der Raum selber noch auf „unter Vorbehalt“ steht sieht man als Anwender nicht.
• Mitarbeiter 2 trägt einen Termin ein. Ich könnte jetzt den Text von Mitarbeiter 2 kopieren. Fakt ist auch hier, dass alles perfekt aussieht aber eben nicht ist. Tatsächlich muss ich gestehen mein Titel mag etwas irreführend sein, denn Exchange hat ja gar nicht zwei Termine zeitgleich gebucht. Aber für die Benutzer sieht wirklich alles richtig aus – für beide Teams. Wir haben dies einige Stunden getestet und in allen denkbaren Konstellationen reproduzieren können.

Was passiert jetzt? Denn damit ist der Pfad der Dubiositäten noch lange nicht vorbei. Beide Mitarbeiter kehren an ihre Arbeit zurück und denken sich nichts böses.

Die ganzen zu beiden Terminen eingeladenen Mitarbeiter gehen ohnehin davon aus, dass der Termin schon passen wird, schließlich gibt es ja einen Organisator, der sich darum kümmern wird.

In allen Kalendern steht der Termin fest gebucht. Um überhaupt – wenn man explizit danach forschen würde – zu sehen, dass etwas nicht passt, müsste man schon als Organisator auf die Termindetails schauen und dort die Zeitleiste soweit auf einem mindestens 22″ Monitor in die Breite ziehen, damit man dort ganz klein schraffiert am Raum sehen würde, dass der noch gar nicht zugesagt hat. Die Mitarbeiter sehen nämlich – Dubiosität Nummer X – den Raum als gebucht. Und zwar als fest gebucht. Ich nehme an, dass die Teilnehmer diesen Status deshalb so sehen (und damit erst recht davon ausgehen, dass alles einwandfrei passt), weil sie gar nicht ihren eigenen Raumstatus sehen sondern nur, dass der Raum prinzipiell gebucht wurde. Aber eben von dem Team, das zuerst da war. Sprich: Die eingeladenen Teilnehmer von Meeting 2 haben defintiv keine Absage bekommen, sehen Termin, Teilnehmer und Raum in all ihren Kalendern. Die eingeladenen Teilnehmer von Meeting 1 sehen genau das gleiche, nur vermutlich sehen die tatsächlich den gebucht-Status des Raumes von sich selbst.

Soweit so gut. Das ist zwar alles etwas eigenartig, aber bei korrekt hinterlegten Parametern wäre dieser Zustand nicht von allzu langer dauer. Denn eigentlich kommt an der Stelle ein delegate in’s Spiel. Der bekommt den Konflikt in seine Mailbox, denn er arbeitet als delegate ja als Stellvertreter des Raums, und muss eine Entscheidung treffen.

Ach ja – interessanter Einschub: selbst wenn das der Fall ist und er eine Absage sendet, muss der Organisator des Termins dennoch handeln. An den Kalendereinträgen aller Beteiligten ändert das nämlich rein gar nichts! Sprich: Schon wieder eine vermeintliche Doppelbuchung. Dubios.

Zurück zum eigentlichen Thema. Der delegate ist nicht eingetragen, die Mail zur Entscheidung hängt in der Queue des Raumes fest und eine Eskalation ist nicht vorgesehen. Es passiert also nichts.

Was ist vorgesehen in einem solchen Fall? Nichts. Denn es handelt sich um eine Fehlkonzeption des durch den Admistrator umgesetzten Regelwerkes aus logischer Sicht. Ein solcher Prozessverlauf sollte nie eintreten. Und das heisst im Klartext: beide Organisatoren haben eine vorläufige Zusage erhalten. Eine Absage kam nie. Und in allen Kalendern sieht alles korrekt aus. Ergo: Es werden beide Teams zur selben Zeit am selben Ort stehen und beide haben gleichermaßen Recht. Dubios.

Und noch immer sind wir nicht am Ende – eine Kuriosität habe ich noch auf Lager. Die meisten Kunden setzen Exchange nicht erst seit gestern ein sondern haben auch schon Vorgängerversionen betrieben. Hierbei war es an der Tagesordnung, dass es in den Abteilungen jeweils einen oder mehrere Mitarbeiter gab, die sich um die Kalender der Konferenzräume gekümmert haben. Diese wurden zumeist einfach als zusätzliches Postfach geöffnet, und auch dann würde es nicht mehr zu dieser Überbuchung kommen. Nur ist das nicht so vorgesehen. Freilich, es funktioniert, aber eben nur solange, wie der Kalender irgendwo – quasi als „Owner“ – geöffnet ist. Verlässt der Mitarbeiter das Haus war es das dann. Dokumentiert wird so ein Fall eigentlich nie, jedenfalls wäre mir das in 15 Jahren nicht vorgekommen… Und dann? Dann hat man einen verwaisten Konferenzraum, der augenscheinlich jahrelang funktioniert hat (obwohl falsch konfiguriert) und dann „plötzlich“ nicht mehr seinen Dienst tut und Überbuchungen zulässt.

Nicht dubios: Der Fehler liegt wie immer beim Menschen.