Rating: 5.0/5. (15 Stimmen) Details
Bitte warten...

Die Problembehandlung von Terminserien und Raumbuchungen, kann einem Exchange Administrator schon einige Zeit beschäftigen. Die Problemstellung ist oftmals gleich: Anwender erstellen in Outlook einen wiederkehrenden Termin und buchen zusätzlich zu den Teilnehmern einen Konferenzraum hinzu. Doch was passiert, wenn der Raum zeitweise durch einen anderen Termin belegt ist? Es kommt zum Konflikt und das Ressourcenpostfach lehnt die Terminserie ab. Ein weiteres Problem ist die Überbuchung von Räumen. Das ist noch ärgerlicher, denn dann geht wertvolle (Meeting) Zeit mit der Suche nach einem freien Raum verloren. Mit einer durchdachten Konfiguration lassen sich solche Konflikte vermeiden. Was zu beachten ist, wie die Kalenderautomatik funktioniert und welche Stellschrauben zu drehen sind, wird im folgenden näher behandelt.

CalMeetingEigentlich ist es ganz einfach. Über Outlooks Planungsansicht können verfügbare Konferenzräume angezeigt und in Termine eingeladen werden. Das funktioniert aber nur mit einzelnen Terminen gut, bei Serienterminen werden sich Überschneidungen kaum vermeiden lassen. In ungünstigen Fällen, nämlich wenn die Konfiguration der Ressourcen nicht auf die Anforderungen abgestimmt ist, kann auch schon bei vereinzelten Terminkonflikten die gesamte Terminserie abgelehnt werden. Genervte Anwender und langwierige Ursachenforschung sind die Folge. Dabei hat Microsoft mit Exchange Server 2007 den Ressourcenbuchungsassistent (Resource Booking Assistant, RBA) eingeführt, der genau an dieser Problematik ansetzt.

Resource Booking Assistant mit Vergangenheit

Wenn man es ganz genau nimmt, gab es den RBA schon vor Exchange 2007, hieß damals Auto Accept Agent und war in Exchange 2003 SP1 verbaut. Der Agent war ein serverseitiger Store Event Sink (Ereigniskonsument und COBRA-Komponente) und bot erstmals eine automatische, serverseitige Verarbeitung von Besprechungsanfragen, die an Ressourcenpostfächer gesendet wurden. Der Agent übernahm die anfängliche Planung, Stornierungen, Aktualisierungen und sendete Antworten an den Organisator. Der Agent hatte ein paar “kleinere” Einschränkungen. So war es nicht möglich und nicht empfohlen, Räume über 6 Monate im Voraus zu buchen. Auch musste man Ressourcenpostfächer im Auge behalten und auf ungewöhnliche Elemente im Postfach achten, um Störungen früh zu erkennen. War früher wirklich alles besser? 😉

Das Verhalten des RBA lässt sich in Exchange 2007 mittels Set-MailboxCalendarSettings anpassen, mit Exchange Server 2010 und den nachfolgenden Versionen wird die Konfiguration mithilfe Set-CalendarProcessing vorgenommen. Folgende Parameter sind entscheidend:

AutomateProcessing

Hiermit wird die automatisierte Kalenderverarbeitung aktiviert. Mögliche Werte sind None, AutoUpdate und AutoAccept. AutoUpdate aktiviert die Kalenderaufsicht (Calendar Attendant) und ist bei Benutzerpostfächer standardmäßig aktiv. Nur der Calendar Attendant verarbeitet Besprechungsanfragen und -antworten. Der Wert AutoAccept aktiviert zusätzlich zum Calendar Attendant den Resource Booking Assistant. Während der RBA Meeting Requests basierend auf den Richtlinien verarbeitet, sorgt die Kalenderaufsicht im Postfach für Ordnung, löscht bearbeitete Anfragen und aktualisiert den Kalender. Ressourcenpostfächer werden per default mit aktiviertem RBA bereitgestellt. Für dieses Szenario brauchen wir also den Parameter auf AutoAccept.

AllowRecurringMeetings

Hierüber wird festgelegt, ob Terminserien erlaubt sind (True) oder nicht (False).

AllowConflicts

Diese Einstellung sorgt für die meiste Verwirrung. Der Wert kann True oder False sein. Manche Administratoren sind mitunter geneigt diesen Wert auf True zu setzen, weil man ja Serienkonflikte behandeln möchte. Doch genau das ist falsch. Dieser Parameter gibt an, ob jeder Terminkonflikt akzeptiert werden soll. Das betrifft neben Terminserien auch einzelne Termine. Die weiter unten aufgeführten Parameter würden durch die Aktivierung dieser Konfiguration AllowConflicts $true obsolet, da Konflikte erlaubt wären.

ConflictPercentageAllowed

Wie viele Termine der Serie in Konflikt geraten dürfen, wird bei diesem Parameter in Prozent angegeben. Der Wert liegt zwischen 0 und 100. Dabei rechnet Exchange die Anzahl der Konflikte auf die Anzahl der Termine in Prozent um. Wird der angegebene Wert überschritten, lehnt der RBA die gesamte Serie ab. Andernfalls prüft er den zweiten Parameter MaximumConflictInstances.

MaximumConflictInstances

Wird die Anzahl von kollidierender Terminen diesen Wert überschreiten. lehnt der RBA eine komplette Serie ab. Die Werte MaximumConflictInstances und ConflictPercentageAllowed dürfen nicht überschritten werden.

Okay, soweit die Theorie. Doch am besten erklären wir das an einem Musterfall. Angenommen wir haben einem Ressourcenpostfach folgende Werte hinterlegt.

AutomateProcessing        : AutoAccept
AllowRecurringMeetings    : True
AllowConflicts            : False
ConflictPercentageAllowed : 50
MaximumConflictInstances  : 5

 

Sendet ein Anwender nun eine Serie an das Postfach, prüft der RBA ob:

  • weniger oder gleich 50% der Termine sich überschneiden.
  • weniger oder gleich 5 Termine sich überschneiden.

 

Schauen wir uns das an einigen Beispielen an:

Bsp. 1: Eine Serie mit 10 Terminen kollidiert mit 4 anderen Reservierungen. Dann sind weniger als 50% – nämlich nur 40% – und weniger als 5 Termine davon betroffen. Beide Bedingungen sind erfüllt.

Doch was passiert nun? Man erhält zwei E-Mails vom RBA. Den Terminen der Serie ohne Überschneidungen wird zugesagt. Termine mit Konflikten zu bereits bestehenden Buchungen werden parallel dazu abgelehnt. In der entsprechenden Mail befinden sich dann Informationen, um welche Termine es sich handelt und wer der Organisator der anderen Termine ist, siehe Abbildung weiter unten. So besteht die Möglichkeit, mit dem Organisator der bereits erfolgreich gebuchten Meetings die Raumbelegung zu ändern oder einen anderen Raum für die einzelnen Termine zu buchen.

Bsp. 2: Eine Serie mit 20 Terminen steht in Konflikt mit 6 bestehenden Buchungen. 6 von 20 sind rund 33%, die angegebenen 50% sind nicht erreicht.  Die Bedingung ConflictPercentageAllowed ist damit erfüllt, nicht aber die Bedingung MaximumConflictInstances von maximal 5 kollidierender Termine. Die gesamte Serie wird abgelehnt.

Bsp. 3: Eine Serie mit 5 Terminen kollidiert mit 4 anderen Buchungen. Zwar ist die maximale Anzahl an Konflikten nicht erreicht, jedoch überschreitet man die angegebenen 50% mit dem Resultat, dass die gesamte Serie abgelehnt wird.

 

Exchange RBA appointment accepted

Mail eines angenommenen Termins

Exchange RBA appointment declined

Mail eines ablehnten Termins

 

Voraussetzung für diesen Ablauf ist, dass der Parameter AutomateProcessing auf AutoAccept steht, allgemeines Überbuchen mittels AllowConflicts über False verhindert wird und Terminserien durch AllowRecurringMeetings gleich True erlaubt sind. Mit fein abgestimmten Werten sollten die wenigstens Serien abgelehnt werden. Welche Konfiguration man letztlich wählt, ist der jeweiligen Arbeitsumgebung geschuldet. Doch am Ende zählt nur der zufriedene Anwender. Und man kann sich selbst mit anderen Themen beschäftigen.

➡ Um  die Werte aller Ressourcenpostfächer zu prüfen, ist die Exchange Powershell das optimale Werkzeug. Zeile 1 zeigt die Kommandos in einer bekannten Schreibweise. Zeile 2 zeigt eine verkürzte Form des Befehls, was am Ende aber das gleiche Ergebnis liefert.

PS C:\> Get-Mailbox -ResultSize Unlimited | Where-Object {$_.ResourceType -eq "Room" -or $_.ResourceType -eq "Equipment"} | Get-CalendarProcessing | Format-Table Identity, AutomateProcessing, AllowRecurringMeetings, *Conflict* -AutoSize

PS C:\> Get-Mailbox | ? ResourceType -in "Room", "Equipment" | Get-CalendarProcessing | ft Id*, Auto*, Allow*, *Conflict* -auto

 

Die Abfrage lässt sich noch optimieren, indem man die Postfächer bereits im ersten Cmdlet nach RecipientTypeDetails filtert. Es wird allerdings ein eindeutiger Objekttyp erwartet, so sind die Ressourcenpostfächer in zwei Runden zu konfigurieren. Vorsicht beim Anwenden! Idealerweise simuliert man vorab mit dem WhatIf-Schalter die geplanten Änderungen.

PS C:\> Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowRecurringMeetings $True -AllowConflicts $False -ConflictPercentageAllowed 50 -MaximumConflictInstances 5

PS C:\> Get-Mailbox -RecipientTypeDetails EquipmentMailbox -ResultSize Unlimited | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowRecurringMeetings $True -AllowConflicts $False -ConflictPercentageAllowed 50 -MaximumConflictInstances 5

 

Bringt die Optimierung der Abfrage durch frühzeitiges Filtern wirklich etwas? Nun, das lässt sich einfach nachprüfen. Wir messen die Ausführung beider Varianten. Und tatsächlich sprechen die Zahlen für sich. Überträgt man diesen Test von einer kleinen Test- in eine größere Produktionsumgebung, ist der Vorteil klar auszumachen.

PS C:\> Measure-Command -Expression {Get-Mailbox | ? ResourceType -in Room | Get-CalendarProcessing | ft Id*, Auto*, Allow*, *Conflict* -AutoSize}

Seconds           : 0
Milliseconds      : 338
Ticks             : 3388262
TotalDays         : 3,92159953703704E-06
TotalHours        : 9,41183888888889E-05
TotalMinutes      : 0,00564710333333333
TotalSeconds      : 0,3388262
TotalMilliseconds : 338,8262

PS C:\> Measure-Command -Expression {Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited | Get-CalendarProcessing | ft Id*, Auto*, Allow*, *Conflict* -AutoSize}

Seconds           : 0
Milliseconds      : 133
Ticks             : 1332805
TotalDays         : 1,54259837962963E-06
TotalHours        : 3,70223611111111E-05
TotalMinutes      : 0,00222134166666667
TotalSeconds      : 0,1332805
TotalMilliseconds : 133,2805

 

Zurück zur Konfiguration. Wo es Regeln gibt, sind Ausnahmen nicht weit. Eine Anforderung kann sein, dass ein kleiner, erhabener Anwenderkreis von den Richtlinien ausgenommen werden soll. Mit dem Parameter RequestOutOfPolicy kann ausgewählten Benutzern die Möglichkeit eingeräumt werden, die konfigurierte Policy zu übergehen. Das sollte nach Möglichkeit nur sparsam eingesetzt werden. Das Ziel ist ja, Doppelbuchungen und anderen Unannehmlichkeiten, was letztlich wieder bei einem selbst in Form von zusätzlicher Arbeit landet, entgegenzuwirken.

PS C:\> Set-CalendarProcessing -Id "Meeting Room Frankfurt" -RequestOutOfPolicy "bob@contoso.com", "alice@contoso.com"

 

Ressourcen lassen sich auch moderieren, so dass bspw. die Konferenzräume der Geschäftsführung durch das Sekretariat explizit freigegeben werden müssen. Der Parameter AllRequestInPolicy steuert, ob Anwender Besprechungsanfragen senden dürfen, sofern nicht gegen konfigurierte Richtlinien verstoßen wird. AllBookInPolicy gibt an, ob automatisch gebucht werden darf. In Kombination mit ResourceDelegates wird die Moderation aktiviert. Das lässt sich natürlich noch weiter ausbauen und die E-Mail-Bestätigung mit einer individuellen Nachricht versehen. Soviel Zeit muss sein.

PS C:\> Set-CalendarProcessing -Id "Board Management Conference Room" -AllRequestInPolicy $true -AllBookInPolicy $false -ResourceDelegates "assistenz@contoso.com", "secretary@contoso.com" -AddAdditionalResponse $true -AdditionalResponse "Bitte halten Sie den Raum sauber und schalten beim verlassen alle Geräte aus."

Sind die idealen Werte gefunden, wird sich bald keiner mehr an die nervigen Probleme erinnern können. Damit wären wir am Ziel und in diesem Beitrag am Ende angelangt.

 


Mac

Mac

Seit über 20 Jahren beschäftige ich mich mit Themen aus dem Bereich IT. Mein Schwerpunkt liegt dabei auf Produkte aus dem Hause Microsoft. Dazu gehören neben Active Directory und Windows Server insbesondere Netzwerkdienste wie DNS, DFS und DHCP. Zudem bin ich ein großer Verfechter des Internet Information Service, also dem Windows Webserver. Berührungspunkte im Bereich Citrix XenApp sowie XenDesktop, als auch VMware runden meinen Erfahrungsschatz ab.

3 Kommentare

Joachim · 7. Dezember 2022 um 16:04

Sobald ein Raum explizit durch eine Person freigegeben werden muss, wird die gesamte Serie erlaubt, auch wenn ein Termin bereits besetzt ist (ConflictPercentageAllowed : 50 & MaximumConflictInstances : 5)
Termine kommen so also in einen Konflikt, habe das gerade mit Exchange 2019 getestet.

Kann das noch jemand nachvollziehen?

Eric Cloninger · 1. Juni 2016 um 20:50

Awesome!  Thanks for posting this.  I was unable to find an accurate explanation anywhere else on the (English) internet.  Greatly appreciate your explanation and examples for this.  And for my English-speaking friends, YES you can have a recurring appointment declined only on the conflicting appointments!  The design decision to have percentage/max-number options grey-out based on true/false condition of “allow conflict” is very misleading.  “Allow conflicts” is not “allow/disallow a recurring appointment based on whether there are conflicts (and if so how many or what percentage)”.  It is “Allow/disallow recurring appointments to double-book.”  The percentage/max-number of conflicts is entirely separate from “allow conflicts”.

Note that the original flow chart incorrectly states that the “allow conflicts-> True” path leads to “instances with conflicts declined”… and the referenced article goes on to say that RBA will *never* double-book.  That was Exchange 2010, and is no longer, if ever was, the case.

    Mac

    Mac · 15. Juni 2016 um 18:02

    Hi Eric!

    Glad to hear the post was helpful to you. 👍
    I didn’t notice that the flow chart from the vendor had errors. Thanks for the hint. The wrong chart has been removed. 🧹

    Kind regards,
    Mac

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.