... auf Cross-Tenant Access Policy umstellen.
Ein Projektleiter legt eine Besprechung mit dem Partnerunternehmen an und sieht im Terminplanungs-Assistenten nur noch graue Balken.
Keine Fehlermeldung, kein Eintrag im Nachrichtenfluss, nichts im Admin Center. Die Verfügbarkeitsanzeige über die Tenant-Grenze hinweg läuft bis heute über Exchange Web Services, und ab dem 1. Oktober 2026 schaltet Microsoft EWS in Exchange Online schrittweise ab.
Der Ersatz heißt Microsoft 365 Cross-Tenant Access Policy. Die offizielle Ankündigung steht als MC1446796 im Message Center und wurde am 25. August 2026 mit geänderter Zeitleiste aktualisiert.
Wen die Umstellung betrifft
Organisationsübergreifende Freigaben sind nie ein Standardzustand, sondern immer von einem Administrator eingerichtet worden. Betroffen bist du, wenn dein Tenant Free/Busy, MailTips oder Kalender mit einem anderen Microsoft 365 Tenant teilt, also mit Tochtergesellschaften, Dienstleistern, Lieferanten oder frisch zugekauften Firmen.
Nicht betroffen sind die Freigaben innerhalb deiner eigenen Organisation und die Freigabe zwischen On-Premises und Online in einer Exchange-Hybrid-Bereitstellung. Für Hybrid gilt ein eigener Weg über die dedizierte Hybrid-App. Freigaben mit einer Partnerorganisation, die Exchange lokal betreibt, sind aktuell ebenfalls außen vor, hier hat Microsoft weitere Message-Center-Beiträge angekündigt.
Warum EWS hier überhaupt im Spiel ist
Drei Konfigurationen in Exchange Online steuern die Freigabe nach außen. Organisationsbeziehungen teilen Free/Busy und MailTips mit anderen Tenants. Availability Address Spaces teilen Free/Busy. Freigaberichtlinien steuern, was deine Benutzer selbst an Externe freigeben dürfen, per Einladung oder als veröffentlichte Kalender-URL.
Organisationsbeziehungen und Freigaberichtlinien holen die Daten aus dem Partner-Tenant per EWS ab. Damit hängen sie an einem Protokoll, das Microsoft zusammen mit den High-Privilege-Access-Mustern abräumt. Die Vertrauensbeziehung wandert deshalb nach Entra: Statt Domänennamen und EWS-Endpunkten arbeitest du künftig mit der Tenant-ID des Partners und einer Richtlinie, die den Zugriff eingehend erlaubt.
Ein Detail, das in vielen Zusammenfassungen falsch steht: Availability Address Spaces mit der AccessMethod OrgWideFBToken hängen nicht an EWS und fallen durch die Abschaltung nicht aus. Du darfst sie migrieren, weil die neue Richtlinie feiner steuerbar ist, du musst es aber nicht.
1: Bestandsaufnahme in Exchange Online PowerShell
MC1446796 ging an jeden Tenant, die meisten Empfänger haben nichts zu tun. Verschaffe dir zuerst Klarheit. Du brauchst dafür die Rolle Organization Management.
$FormatEnumerationLimit = -1
Get-OrganizationRelationship | Where-Object { $_.Enabled -eq $True } |
Format-List Name, DomainNames, Enabled, FreeBusyAccessEnabled, FreeBusyAccessLevel,
FreeBusyAccessScope, MailTipsAccessEnabled, MailTipsAccessLevel, MailTipsAccessScope,
TargetSharingEpr, TargetAutodiscoverEpr, TargetApplicationUriBetroffen bist du, wenn Enabled auf True steht, FreeBusyAccessEnabled oder MailTipsAccessEnabled aktiv ist und die Gegenstelle in Microsoft 365 liegt. Letzteres erkennst du an TargetSharingEpr, TargetAutodiscoverEpr oder TargetApplicationUri: Enthalten sie outlook.com, office365.com oder office365.us, ist der Partner ein Cloud-Tenant. Andere Werte deuten auf ein lokales Exchange hin.
Get-SharingPolicy | Format-List Name, Enabled, Domains, Default
Get-EXOMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox,SharedMailbox `
-Properties SharingPolicy | Group-Object SharingPolicy | Select-Object Name, CountBei den Freigaberichtlinien zählt die Zugriffsebene je Domäne. CalendarSharingFreeBusySimple gibt nur Zeiten preis, CalendarSharingFreeBusyDetail zusätzlich Betreff und Ort, CalendarSharingFreeBusyReviewer den vollständigen Kalender. Eine Richtlinie ist nur relevant, wenn sie aktiv ist und mindestens einem Postfach zugewiesen wurde. Regeln, die mit Anonymous: beginnen, sind veröffentlichte Kalender für beliebige Internetempfänger. Auch die zählen.
Get-AvailabilityAddressSpace | Format-List ForestName, AccessMethod, TargetAutodiscoverEpr,
TargetServiceEpr, TargetTenantIdNotiere pro Fund die Zugriffsebene mit, nicht nur die Tatsache, dass Freigabe existiert. Wer beim Neuaufbau versehentlich von Simple auf Detail wechselt, löst keinen Ausfall aus, sondern eine ungewollte Offenlegung von Betreff und Ort. Das ist der teurere Fehler, weil ihn niemand meldet.
2: Vertrauensstellung in Entra herstellen
Die Microsoft 365 Cross-Tenant Access Policy setzt auf der Entra Cross-Tenant Access Policy auf. Vor der ersten Freigabe aktivierst du je Partnerorganisation die Vertrauensebene Microsoft 365 Collaboration. Die Konfiguration läuft derzeit über das Graph PowerShell SDK Beta, dedizierte Cmdlets hat Microsoft angekündigt, aber noch nicht veröffentlicht.
Connect-MgGraph -Scopes "Policy.Read.All,Policy.ReadWrite.CrossTenantAccess,Policy.ReadWrite.CrossTenantCapability" -ContextScope Process
$partnerId = "<partnerTenantId>"
$body = @{
tenantId = $partnerId
m365CollaborationInbound = @{
users = @{
accessType = "allowed"
targets = @( @{ target = "AllUsers"; targetType = "user" } )
}
}
}
New-MgBetaPolicyCrossTenantAccessPolicyPartner -BodyParameter $body
Domänennamen brauchst du nicht mehr. Die Tenant-ID identifiziert den Partner eindeutig, alle zugehörigen Domänen sind automatisch abgedeckt. Betreibt ein Partner mehrere Domänen unter einer Tenant-ID, reicht eine Richtlinie.
3: Capabilities je Partner setzen
Die eigentliche Freigabe steckt in den Capabilities, und die sind eingehend definiert: Jede Organisation entscheidet selbst, was von außen abgerufen werden darf. Für beidseitige Freigabe müssen beide Seiten ihre Richtlinie anlegen. Bei einseitiger Freigabe genügt der Tenant, in dem die Postfächer liegen.
| Alte Konfiguration | Neue Capability |
| FreeBusyAccessLevel AvailabilityOnly | crossTenantCalendarAvailabilityBasic |
| FreeBusyAccessLevel LimitedDetails | crossTenantCalendarAvailabilityLimitedDetails |
| MailTipsAccessLevel Limited | crossTenantMailTipsLimited |
| MailTipsAccessLevel All | crossTenantMailTipsAll |
| CalendarSharingFreeBusySimple | crossTenantCalendarSharingFreeBusySimple |
| CalendarSharingFreeBusyDetail | crossTenantCalendarSharingFreeBusyDetail |
| CalendarSharingFreeBusyReviewer | crossTenantCalendarSharingFreeBusyReviewer |
$partnerId = "<partnerTenantId>"
$capability = "<capabilityName>"
$group = @{ resourceId = "All"; resourceType = "user" }
$body = @{
"@odata.type" = "microsoft.graph.$capability"
inboundAccess = @{
isAllowed = $true
resourceScopes = @{
included = @( $group )
excluded = @( @{ } )
}
}
}
New-MgBetaPolicyCrossTenantAccessPolicyPartnerM365Capability `
-CrossTenantAccessPolicyConfigurationPartnerTenantId $partnerId -BodyParameter $body
Statt All kannst du eine Sicherheitsgruppe hinterlegen und damit begrenzen, von welchen internen Benutzern der Partner Daten abrufen darf. Das ist das Gegenstück zu FreeBusyAccessScope und MailTipsAccessScope. Hattest du bisher mehrere Freigaberichtlinien für unterschiedliche Postfachgruppen, führt an Sicherheitsgruppen kein Weg vorbei, weil sich Postfachzuweisungen in der neuen Welt nicht mehr abbilden lassen.
Zwei Sonderfälle: Wildcard-Richtlinien werden über New-MgBetaPolicyCrossTenantAccessPolicyDefaultM365Capability in der Standardrichtlinie abgebildet. Anonyme Kalenderveröffentlichungen ebenfalls, dafür gibt es die Capabilities AnonymousCalendarFreeBusySimple, AnonymousCalendarSharingFreeBusyDetail und AnonymousCalendarSharingFreeBusyReviewer. Eine anonyme Freigabe je Partner-Tenant ist nicht möglich.
4: Testen, bevor du löschst
Die alten Konfigurationen haben Vorrang vor der neuen Richtlinie. Solange Organisationsbeziehung oder Freigaberichtlinie aktiv sind, läuft der Verkehr weiter über EWS, und dein Test sagt nichts aus. Deaktiviere sie deshalb auf beiden Seiten zum selben Zeitpunkt und stimme das Zeitfenster vorher mit dem Partner ab.
Set-OrganizationRelationship -Identity "<RelationshipName>" -Enabled $False
Set-SharingPolicy -Identity "<PolicyName>" -Enabled $False
Availability Address Spaces lassen sich nicht deaktivieren. Sichere sie vor dem Entfernen, sonst baust du sie im Fehlerfall aus dem Gedächtnis nach.
Der Rückweg läuft über Import-Clixml und Add-AvailabilityAddressSpace mit den gesicherten Werten für ProxyUrl, TargetAutodiscoverEpr, TargetServiceEpr und TargetTenantId. Organisationsbeziehungen und Freigaberichtlinien setzt du mit -Enabled $True zurück.
5: Aufräumen
Erst wenn der Partner bestätigt hat, dass Verfügbarkeit, MailTips und geteilte Kalender in beide Richtungen funktionieren, räumst du auf. Alles andere hinterlässt zwei parallele Pfade, von denen einer im Oktober stirbt.
Remove-OrganizationRelationship -Identity "<RelationshipName>"
Remove-SharingPolicy -Identity "<PolicyName>"
Wenn du den 1. Oktober nicht schaffst
Für Tenants mit vielen Partnerbeziehungen ist das Zeitfenster knapp, und Microsoft räumt das selbst ein. Es gibt ein Sicherheitsventil: Setzt du EWSEnabled auf $True, laufen die bestehenden Freigaben weiter, bis EWS am 1. April 2027 endgültig abgeschaltet wird. AppIDs musst du dafür nicht in die EWS-Positivliste eintragen, weil dieser Pfad ohne OAuth arbeitet.
Ein Haken bleibt: Beide Seiten müssen EWSEnabled setzen. Verlängert nur dein Tenant, sehen deine Benutzer die Daten des Partners nicht mehr, während der Partner deine weiterhin sieht.
Fazit
Die Umstellung ist technisch überschaubar und organisatorisch anstrengend. Der technische Teil sind vier Cmdlets zur Bestandsaufnahme und ein Graph-Aufruf je Partner. Der anstrengende Teil ist die Abstimmung: Jede beidseitige Freigabe braucht einen Administrator auf der Gegenseite, der zur selben Zeit dieselbe Umstellung fährt. Bei fünf Partnern sind das fünf Termine, und jeder davon ist ein Fenster, in dem die Verfügbarkeitsanzeige kurz weg ist.
Plane deshalb nicht nach dem Kalender von Microsoft, sondern nach dem deiner Partner. Die Richtlinie steht dir zur Verfügung, sobald der Rollout deinen Tenant erreicht hat, weltweit war der Abschluss für den 15. September 2026 angesetzt. Bis zum 1. Oktober bleiben danach zwei Wochen, und wer die nicht nutzen kann, zieht EWSEnabled und arbeitet bis spätestens 1. April 2027 sauber ab.
Sicherheitsseitig ist die Migration ein Gewinn, weil ein hochprivilegierter EWS-Pfad verschwindet und die Vertrauensstellung in Entra sichtbar wird. Der Umbau ist außerdem der beste Zeitpunkt, alte Zugriffsebenen zu hinterfragen. Eine Reviewer-Freigabe an einen Dienstleister aus einem Projekt von 2021 überträgt vollständige Kalenderinhalte inklusive Teilnehmer und Ort. Wenn du sie ohnehin neu anlegst, lege sie kleiner an. Dasselbe gilt für anonyme Kalenderveröffentlichungen: Prüfe, ob die veröffentlichte URL noch jemand braucht, bevor du sie in eine neue Capability überführst. Und behalte im Blick, dass die Konfiguration derzeit auf dem Graph SDK Beta beruht. Teste sie in einem Nicht-Produktiv-Tenant, bevor du sie gegen einen wichtigen Partner fährst.
Externe Quellen
| Quelle | Thema | URL |
| Exchange Team Blog | Ankündigung, Rollout-Plan, EWSEnabled als Verlängerung, FAQ | https://techcommunity.microsoft.com/blog/exchange/cross-tenant-freebusy-mailtips-and-calendar-sharing-are-moving-to-cross-tenant-a/4545169 |
| Microsoft Learn | Migrationsleitfaden mit Cmdlets und Capability-Mapping | https://learn.microsoft.com/exchange/sharing/migrate-to-m365-xtap |
| Microsoft Learn | Deprecation von EWS in Exchange Online | https://learn.microsoft.com/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online |
| Message Center | MC1446796, offizielle Ankündigung im Tenant | https://admin.cloud.microsoft/?ref=MessageCenter/:/messages/MC1446796 |
| Microsoft Learn | Übersicht Cross-Tenant Access mit Entra External ID | https://learn.microsoft.com/entra/external-id/cross-tenant-access-overview |
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Kommentar hinterlassen
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.