MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Kalendersharing und REST

Das Vorzimmer verwaltet den Kalender der Führungskraft, der Empfang verwaltet die Besprechungsräume und immer wieder kommt Outlook mit Exchange zum Einsatz. Wir versuchen einen Blick hinter die Kulissen und was Microsoft in 2026 ändert.

Setup

In den folgenden Beispielen kommen drei Postfächer zum Einsatz und ich orientiere mich an der Bezeichnung, die Microsoft hierzu nutzt.

  • Delegate
    Der "Delegate" ist die Person, die in andere Kalender zugreift oder reinschaut. Klassischerweise also der Mitarbeiter oder die Mitarbeiterin im Vorzimmer, Sekretariat oder Empfang
  • Principal
    Damit meint Microsoft in der Regel die Führungskraft, deren Kalender durch den Delegate eingesehen oder sogar aktiv verwaltet wird. In meinem Beispiel hat der Delegate zumindest "Editor"-Recht auf den Principal.
  • Room
    Um später auf die Unterschiede einzugehen, habe ich noch einen Raum ausgesucht, der zu Meetings gerne eingeladen wird, auf den aber sonst niemand Rechte hat. Es ist eine Empfehlung von Microsoft, dass ein Raum nicht als "Einladender" missbraucht wird, sondern passiv ist

Wenn Sie die Tests nachstellen wollen, dann sollten Sie also zuerst als Principal die Berechtigungen für den Delegate entweder auf das Postfach oder nur den Kalender einrichten. Ich beschränke mich auf den Kalender:

Microsoft versteckt hier in den fünf "Radio-Buttons" genaugenommen zwei Berechtigungen. Die ersten beiden Rechte sind eigentlich für die "Free/Busy"-Funktion gedacht aber erlauben mit keinen weiteren Zugriff auf das Postfach oder den Kalender per MAPI oder REST. Erst die drei weiteren Optionen erlauben dem "Delegate" auch den Zugriff in das Postfach.

Auf meinem Kalender darf die Organisation per "Free/Busy"-API nur sehen, wann ich frei/beschäftigt bin, aber um die Zusammenarbeit zu verbessern, habe ich einer Gruppe die erweiterten Free/Busy-Rechte gegeben, auch den Ort und den Titel anzuzeigen. Nur der Benutzer "FCDEMO1" hat zusätzlich das Recht eines Stellvertreters. Er darf also nicht nur alle Elemente bei mir lesen.

Ich habe die Tests mit Outlook im Cache Mode als auch Outlook ohne OST-Datei ausgeführt und bis auf wenige Sekunden die gleichem Ergebnisse gehab. Allerdings hat Outlook ohne Cached Mode natürlich beim Senden der Termine manchmal schon deutlich länger gebraucht.

Eine Testserie mit Exchange OnPremises steht noch aus

Einbinden und Anzeigen

Die Unterschiede sind recht einfach zu sehen, wenn Sie in Outlook  (Classic, Stand 2026) neben dem eigenen Kalender noch zwei weitere Kalender mit anzeigen lassen. In meinem eigenen Kalender habe ich alle Details und auch im Besprechungsraum, wo ich zumindest "Editor"-Rechte habe, kann ich die Namen der  Organisatoren sehen und mit "Rechter Maustaste" könnte ich dort sogar Termine anlegen. Beim mittleren gelben Termin sehe ich aber nur "Free/Busy" und kann über das Kontextmenü auch keine Termine anlegen.

Was sie aber nicht sehen, ist der Zugriff, der dahinter bislang passiert. Outlook versucht beide Postfächer erst einmal per "Free/Busy"-Abfragen gegen /EWS oder Graph zu ermitteln. Für eine kurze Zeit zeigt Outlook daher für beide zusätzlich geöffneten Kalender auch nur die Frei/Belegt-Zeiten an. Aber Outlook versucht zusätzlich auch noch beide Kalender per MAPI oder REST zu öffnen. Beim Besprechungsraum gelingt das nicht aber beim Principal schon. Daher sehe ich dort dann kurz darauf auch die Details und auch das Menü zum Anlegen von neuen Terminen wird aktiviert. Dass der versuchte direkte Zugriff auf das Postfach des Raums fehlt schlägt, unterdrückt Outlook.

Einladung

Ich lasse die Ansicht der Kalender offen und starte eine Einladung zu einem Termin.

Von : Delegate Frank Carius
To  : Principal  Testmailbox
Raum: Konferenzraum

Die Termineinladung wird per versendet und direkt in meinem Kalender eingetragen. Nach wenigen Sekunden landet die Mail beim Principal und beim Raum. Da beide Postfächer einen AutoAcceptAgent haben, passiert am Ziel folgendes:

Postfach  Ergebnis

Principal

Outlook/Exchange sehen die Einladung und addieren sie schon mal "unter Vorbehalt" im Kalender. Eine Rückmeldung kommt aber noch nicht

Raum 

Hier nimmt der AutoAccept-Agent die Einladung an, wenn keine Bedingung (Konflikt, Booking-Beschränkungen o.ä.) dagegen sprechen

Meine Ansicht in Outlook hat sich dann wie folgt verändert:

Zeitpunkt  Bild

Termin angelegt

In meinem Kalender wurde der Termin angelegt. Es ist nicht ersichtlich, dass die Einladungen schon unterwegs sind

  

Reservierung Besprechungsraum

In meinem Fall hat der Besprechungsraum unter Vorbehalt den Termin schon einmal eintragen. Da ich auch Editor-Rechte habe, sehe ich die Details.

Zusage und Update

Mit dem nächsten Update durch Outlook sehen wir nun auch die Reservierung in der Testmailbox und dass der Raum den Termin nun von "Unter Vorbehalt" auf "gebucht" geändert hat

  

Alle Anzeigen wurden in weniger als einer Sekunde aktualisiert. Früher hatte ich immer gedacht, dass Outlook die Zeiten nur alle 15 Minuten aktualisiert und nur Stellvertreter direkt anzeigt. Das scheint aber nicht mehr so zu sein.

Diese Messungen erfolgten noch vor dem 3. Juni und der danach von Exchange Online aktivierten Kalenderreplikation.

Terminupdate

Ich habe den Test noch einmal mit einem Update des Termins wiederholt. Dazu habe ich den Termin in meinem Kalender einfach um eine halbe Stunde verschoben und die Anzeigen der anderen Kalender beobachtet.

Zeitpunkt  Bild

Termin verschoben

In meinem Kalender wurde der Termin sofort an der neuen Zeit angezeigt. Es dauert natürlich etwas, bis die "Updates" per Mail bei den anderen Teilnehmern angekommen sind.

  

Update in der Testmailbox

Diesmal war die Testmailbox schneller. Ob das nun an dem Routing der Update-Mail, der Verarbeitung durch den AutoAccept-Agent oder das Update durch mein Outlook liegt, kann ich nicht sagen

Termine in Sync

Nach weniger als einer Minute danach waren die Termine und auch meine Anzeige überall aktuell.

Absage

Um die Testserie wieder aufzuräumen, habe ich den Termin bei mir gelöscht und die Absagen versendet.

Zeitpunkt  Bild

Termin abgesagt

Die Absage hat bei mir im Kalender den Termin sofort entfernt und auch die Anzeige aktualisiert.

Update des Raums

Diesmal habt der Raum die Absage zuerst als Absage im Kalender gespeichert

Teilnehmer ist frei

Der Teilnehmer hat den Block auch wieder freigegeben, aber anders als beim Raum wird der Termin nicht komplett entfernt. Der Teilnehmer kann also nachvollziehen, dass es hier mal eine Einladung gab, die abgesagt wurde

MAPI Model

Mich hat natürlich etwas interessiert, was da im Hintergrund passiert. Welche Protokolle und welche APIs werden genutzt. Dankenswerterweise hat Microsoft schon 2022 einen Blogspost zu dem Thema geschrieben:

Der klassische Zugriff per MAPI ist schon 20+ Jahre vorhanden und entsprechend in die Jahre gekommen. Damals gab es nur Exchange OnPremises Server und Outlook-Clients mit lokaler Verbindung.


Quelle: https://techcommunity.microsoft.com/blog/outlookglobalcustomerservice/planning-considerations-for-rest-based-aka-new-model-calendar-sharing-in-outlook/3594378

Rechts in Grün ist der "Principal". welcher seinen Kalender frei gibt und in der Mitte ist der Delegate, welcher seinen eigenen Kalender liest aber auch auf den Principal zugreift. Das erfolgt über MAPI und wenn der Delegate möchte, kann er auch den Kalender des Principal über eine eigene MAPI-Verbindung synchronisieren. Der Principal in Grün kann natürlich auch seinen eigenen Kalender synchronisieren. Der Zugriff des Delegate auf z.B. einen Raum, auf dem er keinen Zugriff hat kann er nur per Free/Busy sehen.

Damit der Delegate weiß, dass er das Postfach oder den Kalender des Principals öffnen kann, wird im Postfach des Delegate nach  der Einrichtung ein Eintrag, vergleichbar zu einem Link, gespeichert aber keine Termine.

Heute gibt es sehr viele Clients und selbst Smartphones und Raumsysteme nutzen Kalender, aber haben MAPI nie gelernt. Entsprechend gibt es die ein oder anderen Unstimmigkeiten.

Wer keinen Zugriff auf einen Kalender hat, kann nur Free/Busy per EWS mit den bekannten Verzögerungen nutzen.

Wechsel zu REST

Microsoft wird schon gemerkt haben, dass der Zugriff auf Kalender eines Principals nicht so optimal ablaufen. Sie sind normalerweise nicht im Cache (OST-Datei) und braucht viele TCP-Verbindungen. Ohne Berechtigungen muss der Status und die Kalenderansicht über EWS vom Exchange Server ermittelt werden. Nun wissen wir alle, dass Microsoft in EWS-Funktion in Exchange Online zum Oktober 2026 abschaltet und einzelnen Apps maximal bis April 2027 eine Verlängerung bekommen können.

Neuere Versionen von Outlook wechseln daher zumindest mit Exchange Online Postfächer auf eine moderner REST-Schnittstelle. Das New Outlook/Win kann sogar gar kein MAPI mehr und Mobilegeräte etc. sind ebenfalls raus.


Quelle: https://support.microsoft.com/en-us/office/calendar-sharing-in-microsoft-365-b576ecc3-0945-4d75-85f1-5efafb8a37b4

Das bedeutet aber auch, dass Outlook 2019/2024 und andere klassisch lizenzierte Outlook-Versionen nicht in den Genuss der neuen Zugriffswege kommen.

Wenn Outlook 2024 aber kein REST macht und Exchange Online kein EWS mehr anbietet, dann dürfte hier die Free/Busy-Funktion wegfallen. Wer Exchange Online nutzt, sollte daher besser auch die Microsoft 365 Apps-Version von Outlook nutzen.

Mittlerweile sollte der Zugriff per REST der neue Default sein. Sie können dies aber in ihrem MAPI-Profil kontrollieren. Diese Checkbox aktiviert REST. Die zweite Einstellung sind die Details beim jeweiligen Kalender selbst. Auch hier ist MAPI oder REST zu lesen.

 

Die Details sehen Sie nur, wenn Sie mindestens Reader oder Stellvertreter-Rechte haben.

Die Einstellungen können auch per Gruppenrichtlinien verwaltet werden.

Analyse mit Fiddler

Ich habe mein Classic Outlook (Stand Jun 2026) ohne OST-Datei mit meinem Exchange Online Postfach und den oben bei den Tests genutzten Besprechungsraum und Test-Postfach neu geöffnet und dann vom Posteingang zur Kalenderansicht mit allen drei Kalendern gewechselt. Ich sehe überwiegend MAPI/HTTP-Zugriffe auf drei verschiedene PostfachIDs

Dazwischen ist aber ein Aufruf auf "CalendarService-API", mit folgendem Request (Gekürzt)

POST https://outlook.office.com/CalendarService/api/v1.0/users('PUID:100xxxxF32@<tenantGUID')/Calendar/getSchedule HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: application/json;IEEE754Compatible=true;charset=utf-8
Accept-Charset: utf-8
Accept-Encoding: gzip
Authorization: Bearer eyJ0exxxxxxxx
User-Agent: Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.19929; Pro)
X-User-Identity: Frank.Carius@Netatwork.de
X-MS-Account-Type: Organization
X-Accept: application/json
X-AnchorMailbox: PUID:100xxxxF32@<tenantGUID
ScenarioTag: RMP_OutlookDesktop_Other
Content-Length: 227
Host: outlook.office.com

Die Authentifizierung ist das Bearer-Token des aktuell angemeldeten Benutzers, welcher auch die X-AnchorMailbox ist aber auf das Testpostfach zugreift. Die Antwort ist eine klassische Free/Busy-Antwort mit einer langen Folgen von 0000000 für leere Zeiten und scheinbar drei Terminen.

Dann habe ich Outlook einfach mal auf der Kalenderansicht "stehen" lassen und mit Fiddler den Verkehr während "Ruhe" betrachtet.

Sie sehen gut, dass Outlook hier vier "ausstehende" HTTP-Connections hat, die zwar gesendet aber vom Server noch nicht beantwortet wurden. Zudem sehen wir an den Zeiten, dass die Requests nach ca. 1 Minute immer wieder erneuert werden. Ds kann ich auch in den Details eines Requests und der Übersicht gut sehen:

 

Die Pakete sind auch alle ca. 166-180 Bytes groß und man kann in der "RAW"-Ansicht die MAPI-Kommunikation zumindest vermuten.

Das sieht so aus, als wenn der Client eine "gibt es eine Update"-Anfrage stellt und der Server als Streaming dann erst ein "PROCESSING" und dann regelmäßig ein "PENDING" sendet, ehe dann die Verbindung mit einem "DONE", gefolgt von dem Zeitstempel und der Gesamtzeit, hier vermutlich 65406ms, liefert.

Ich habe in der Zeit, als ich diese Messungen gemacht habe, aber noch keine REST-Aufrufe gesehen.

Das ist aber auch erklärbar, weil ich die Mitschnitte ohne OST-Datei, d.h. ohne Cache Mode gemacht habe und hierbei anscheinend die Aktivierung von REST im Profil gar nicht möglich ist.

Sobald ich den Cache-Mode aktiviere, ist die Checkbox auswählbar.

Wechsel zu REST mit Synchronisation

Auch die neue Zugriffsmethode per REST löst aber nicht alle Probleme, die Outlook noch mit "Delegates" hat. Vor allem der Zugriff auf andere Postfächer ist nicht immer optimal und hier ändert Microsoft im Juni/Juli 2026 die Betriebsart:

Die Termine der des letzten Jahres und in der Zukunft aus dem Kalender eines Stellvertretenden/Principal werden in einen Ordner des Stellvertreters durch den Exchange Online Server im Hintergrund "neartime" synchronisiert, wenn es nicht mehr als 6 Stellvertreter sind. Das Outlook des Stellvertreters repliziert dann die Termin in seine OST-Datei und muss nicht mehr in die anderen Kalender zugreifen. Das Rollout ist vom 3. 6 bis 31.7 geplant


 Quelle: https://admin.cloud.microsoft/?#/MessageCenter/:/messages/MC1287370

Exchange Online wird serverseitig den Kalender von Principals als weiteren Ordner in den Kalender des Delegate synchronisieren.

“A new calendar folder will be created in a hidden state and will only become visible to the user once the full sync is successfully completed and validated, ensuring a seamless rollover to the new model.” This doesn’t mean that Exchange Online will create a new version of the user’s own Calendar folder. Instead, it refers to the copies of shared calendars created in delegate mailboxes
 Quelle: MC1287370)  Shared calendars in Microsoft 365 are being automatically upgraded to the improved sharing platform starting late May 2026. No admin action is required.  
https://admin.cloud.microsoft/?#/MessageCenter/:/messages/MC1287370

Damit kommt hier nun die Funktion die 2022 schon angekündigt wurde. Voraussetzung ist natürlich Exchange Online. OnPremises wird es das nicht geben.

Der Community-Artikel von damals hat schon beschrieben, wie es nun kommen soll.


Quelle: https://techcommunity.microsoft.com/blog/outlookglobalcustomerservice/planning-considerations-for-rest-based-aka-new-model-calendar-sharing-in-outlook/3594378

Die Termine im Kalender des rechten Postfach des Principals werden serverseitig in einen Unterordner des Delegate repliziert. Für das Classic Outlook des Delegate ist es einfach ein weiterer Kalender im Postfach, welcher er Offline synchronisieren, mitnehmen und anzeigen kann. Änderungen im Kalender des Principals wird der Delegate erst im lokalen Cache machen aber dann direkt ein den Kalender im Postfach des Principal zurückschreiben. Die Änderung im Principal-Kalender wir dann vom Exchange Server wieder zum Ordner im Postfach des Delegate repliziert und dann letztlich wieder zum lokalen Client. Die Latenzzeit der Replikation soll dabei weniger als 1 Minute sein.

Wenn ein Principal einen neuen Delegate einrichtet, startet der Exchange im Hintergrund die Replikation in drei Schritten.

  1. Hat der Principal <= 6 Delegates und hat der Delegate <= 6 Principals?
    Wenn die Werte überschritten sind, wird die Replikation nicht gestartet. Hintergrund dürfte die Sorge vor zu vielen Sync-Partnerschaften und Throttling auf der REST-API sein.
  2. Anlegen eines versteckten Ordners beim Delegate
    Der wird dann zum Replikationsziel für den Kalender und der "FullSync" aller Termine der letzten 365 Tage und in der Zukunft startet.
  3. Visible
    Sobald der Ordner "inSync" ist, wird er für den Anwender sichtbar geschaltet. Outlook braucht keinen Neustart o.ä.

Wenn Sie Fehler haben, dann sollten Sie laut Microsoft nicht den Ordner beim Delegate löschen und neu anlegen, sondern ein Support Ticket öffnen. Ich vermute, dass Microsoft damit auch die Anfangsfehler finden, verstehen und korrigiere möchte.

Die neue Funktion durch eine Replikation ist nur verfügbar, wenn Principal und Delegate in Exchange Online gehostet sind. OnPremises-Server oder Hybrid-Szenario sind nicht abgedeckt. 

Steuerung, Status, Logging

Die einzige Funktion, die ich gesehen habe, ist ein Zugriff auf den Kalenderordner beim Delegate über PowerShell oder Microsoft Graph. Was aber der "Replikationsjob" bei Microsoft im Backend durchläuft, ob es Fehler beim Lesen in der Quell und der Anlage/Update/Löschung im Ziel gibt, konnte ich noch nicht einsehen. Ein Migrations-Job hinterlegt ein Migration-Protokoll in der Mailbox.. Vielleicht hat Microsoft ja vor, dass auch der Kalender-Sync-Job seine Tätigkeit als versteckte Nachricht im Postfach der Quelle oder Ziel hinterlegt.

Wenn jemand hier etwas in Erfahrung bringt, freue ich mich über einen Hinweis.

Bis dahin kann man wohl per PowerShell oder Graph einfach nach einem entsprechenden Kalender im eigenen Postfach schauen.

Connect-ExchangeOnline

Get-MailboxFolder `
   -Identity user1@msxfaq.net:\Kalender `
   -Recurse 



Get-MailboxCalendarFolder `
   -Identity <user2>:\Calendar\<name of shared calendar> 

Interessant ist in dem Zuge auch das Feld "ExtendedFolderFlags", welches mehr Details zu dem Kalenderordner liefert.

Kalendetype  ExtendedFolderFlags

Primärer Kalender des Postfachs in Exchange Online

SharedOut, SharedViaExchange, SharedExchangeEver, SharedExchangeWriteEver, SharedExchangeValid, ExchangeShareFolder, ExchangePublishedCalendar  

Per ICS synchronisierter Kalender eines Microsoft Events

ReadOnly, WebCalFolder, SharedIn, PersonalShare, SharedExchangeValid, ExclusivelyBound

Geburtstage 

ReadOnly, SharedExchangeValid 

per ICS importierter Kalender 

ICalFolder, SharedIn, SharedExchangeValid, ExclusivelyBound

Es gibt sicher noch weitere Flags und ich bin gespannt,  

Einschätzung

Es hat fast vier Jahre gedauert, bis eine von Microsoft im August 2022 auf https://techcommunity.microsoft.com/blog/outlookglobalcustomerservice/planning-considerations-for-rest-based-aka-new-model-calendar-sharing-in-outlook/3594378 veröffentlichte Änderung nun zumindest in Exchange Online tatsächlich ankommt. Wobei ich mir immer noch nicht sicher bin, ob dies nun der große Vorteil ist und war Microsoft damit entlasten will. Sicher musst mein Outlook sich zu allen Postfächer per MAPI und später per REST verbinden, von denen ich die Termine sehen wollte. Zukünftig bekommt Outlook die Daten als Kopie über das eigene Postfach repliziert. Das ist nur dann schneller und aktueller, wenn der Synchronisationsprozess im Backend zeitnah und fehlerfrei arbeitet. Vermutlich nutzt Microsoft im Backend dazu die Graph-Schnittstelle mit einer Push-Notiification, sobald der primäre Anwender im Kalender etwas ändert.

Allerdings ist das eine reine Exchange Online Funktion und hilft uns weder bei einem Hybrid-Betrieb mit lokalen Postfächern und auch eine Synchronisation über mehrere Tenants ist aktuell nicht vorgesehen. Vielleicht kommt so etwas zu einem späteren Zeitpunkt. Insbesondere bei einem "Multi-Tenant-Betrieb" wäre so ein KalenderSync durchaus interessant, auch wenn er nur unidirektional erfolgen würde. Das bleibt dann bis auf weiteres wieder die Aufgabe von 3rd Party Tools

Weitere Links