MapiExceptionMdbOffline, Queues wachsen, DAG Kopien replizieren nicht mehr. Ein Neustart hilft, aber nur bis zum nächsten Mal.
Es ist die letzte Bastion der Basic Authentication in Exchange Online. Für IMAP, POP, EWS und MAPI hat Microsoft die Passwort-Anmeldung bereits im Oktober 2022 abgeschaltet, nur bei SMTP AUTH durfte sie bisher bleiben. Damit ist bald Schluss: Ende Dezember 2026 deaktiviert Microsoft Basic Auth für SMTP AUTH in bestehenden Tenants standardmässig. Neue Tenants ab Januar 2027 bekommen sie gar nicht mehr, und im zweiten Halbjahr 2027 folgt das endgültige, unwiderrufliche Enddatum. Wer Geräte oder Skripte betreibt, die sich mit Benutzername und Passwort per SMTP an Exchange Online anmelden, sollte jetzt handeln, auch wenn sich die Frist reaktivieren lässt.
Ein öffentliches Zertifikat gehört auf jeden Exchange-Server, der von aussen erreichbar ist. Der lästige Teil ist die Erneuerung: Let's-Encrypt-Zertifikate laufen nach 90 Tagen ab, und niemand will das alle drei Monate von Hand machen. Mit win-acme lässt sich das komplett automatisieren, inklusive Zuweisung an die Exchange-Dienste und geplanter Erneuerung. In diesem Beitrag zeige ich den kompletten Weg, und ich gehe auf einen kleinen Stolperstein im mitgelieferten Exchange-Skript ein, der mich kurz aufgehalten hat.
Wer Exchange Hybrid betreibt und alle Postfächer längst in Exchange Online hat, kennt das Dilemma: Für die Verwaltung der Exchange-Attribute von synchronisierten Benutzern braucht es weiterhin einen lokalen Exchange Server – den berüchtigten Last Exchange Server (LES). Attribute wie E-Mail-Adressen oder CustomAttributes werden on-prem gepflegt und per Entra Connect in die Cloud synchronisiert. Microsoft bietet nun einen Ausweg: Mit dem Source of Authority (SOA) Transfer wandert die Verwaltungshoheit für Exchange-Attribute in die Cloud – pro Postfach oder gleich für den ganzen Tenant. Schauen wir genauer hin.
Der SOA-Transfer trennt die Zuständigkeiten sauber auf: Die Identitätsattribute (Name, UPN, Abteilung, Telefonnummern usw.) bleiben im lokalen Active Directory und werden weiterhin synchronisiert. Die Exchange-Attribute (E-Mail-Adressen, CustomAttributes, HiddenFromAddressListsEnabled, Weiterleitungen usw.) hingegen werden nach dem Transfer direkt in Exchange Online verwaltet – per EXO PowerShell, Exchange Admin Center oder Microsoft 365 Admin Center.
Gesteuert wird das über eine neue Postfach-Eigenschaft: IsExchangeCloudManaged. Steht sie auf true, ignoriert Exchange Online die Exchange-Attribute aus der on-prem-Synchronisation und erlaubt die direkte Bearbeitung in der Cloud.
Update vom 9. Oktober 2026: Microsoft hat den Zeitplan präzisiert (MC1485116). Der harte Stichtag ist der 10. Oktober 2026: Ab dann blockiert Exchange Online bei EwsEnabled = True jede Anwendung, die nicht in EwsAllowedAppIDs steht. Eine leere Liste bedeutet «alles blockiert». Microsoft hat die Liste am 8. und 9. Oktober für Tenants automatisch befüllt, die am 2. Oktober bereits EwsEnabled = True hatten, auf Basis der EWS-Nutzung der letzten 60 Tage. Wer erst später auf True stellt, erhält keine Liste und muss sie selbst pflegen. Tenants mit EwsEnabled = Null werden stufenweise deaktiviert, jeweils mit einer Warnung im Message Center sieben Tage vorher. Die unten erwähnte Frist Ende August ist damit überholt, der Rest des Beitrags gilt unverändert. Der Set-Befehl funktioniert inzwischen in allen Tenants. Prüfen, was Microsoft eingetragen hat:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled,EwsAllowedAppIDs
Update vom 23. Oktober 2026: Übergangslösung bis April 2027
Microsoft hat EWS in vielen Tenants bereits abgeschaltet. Bis April 2027 lässt es sich noch einmal einschalten. Das ist eine Übergangslösung, kein Dauerzustand. Danach geht es nicht mehr, auch nicht mit Admin-Rechten.
Ob es deinen Tenant getroffen hat, zeigt das Message Center: Suche nach «EWS has been disabled in your tenant». Typische Symptome sind ständige Passwortabfragen in Apple Mail oder Classic Outlook auf macOS, ausgefallene Outlook-Add-ins oder ein Backup, das nicht mehr läuft.
Wie du EWS wieder einschaltest, beschreibt Microsoft Schritt für Schritt, im Admin Center und per PowerShell: Exchange Online EWS application stopped working? Do this. Das kann nur ein Tenant-Admin, der Microsoft Support nicht.
Die Wirkung kommt meist innert einer Stunde, in seltenen Fällen nach bis zu 4 Stunden. Die Allow-List mit den Apps der letzten 60 Tage ist schon befüllt, Änderungen daran brauchen 24 Stunden.
Die Zeit bis April 2027 solltest du nutzen: Bei jeder Anwendung, die EWS braucht, beim Hersteller nach einer Version ohne EWS fragen. Eigener Code muss auf Microsoft Graph umgestellt werden.
Exchange Web Services (EWS) begleitet uns seit Exchange 2007. Unzählige Backup-Lösungen, Migrationstools, Archivierungssysteme und selbst geschriebene Skripte nutzen die Schnittstelle bis heute. Damit ist bald Schluss: Ab dem 1. Oktober 2026 beginnt Microsoft, EWS in Exchange Online schrittweise zu deaktivieren. Am 1. April 2027 wird die Schnittstelle endgültig und unwiderruflich abgeschaltet. Wer jetzt nicht handelt, riskiert ab Oktober einen Betriebsunterbruch. Die wichtigste Deadline liegt dabei nicht im Oktober, sondern bereits Ende August 2026.
Eine Phishing-Mail passiert morgens um 8 Uhr den Filter, weil der Link dahinter noch harmlos ist. Um 11 Uhr schalten die Angreifer die Zielseite scharf, und die Mail liegt längst im Postfach. Genau für dieses Szenario gibt es in Exchange Online eine Funktion, die kaum jemand auf dem Radar hat: Zero-Hour Auto Purge (ZAP). Sie räumt bereits zugestellte Nachrichten nachträglich weg, ist in jeder Cloud-Mailbox enthalten und braucht keine Zusatzlizenz. Trotzdem wird sie oft unabsichtlich ausgehebelt. Schauen wir genauer hin.
Microsoft hat bisher nur die USD-Listenpreise offiziell publiziert (pro Benutzer und Monat, Annual Commitment). Bestandskunden bleiben bis zu ihrer nächsten Verlängerung auf den bisherigen Preisen.
| Plan | Alt | Neu | Änderung |
| Microsoft 365 Business Basic | $6.00 | $7.00 | +16% |
| Microsoft 365 Business Standard | $12.50 | $14.00 | +12% |
| Microsoft 365 Business Premium | $22.00 | $22.00 | unverändert |
| Office 365 E3 | $23.00 | $26.00 | +13% |
| Office 365 E5 | $38.00 | $41.00 | +8% |
| Microsoft 365 E3 | $36.00 | $39.00 | +8% |
| Microsoft 365 E5 | $57.00 | $60.00 | +5% |
| Microsoft 365 F1 / F3 | $2.25 / $8.00 | $3.00 / $10.00 | +33% / +25% |
Bemerkenswert: Die «ohne Teams»-Varianten steigen prozentual stärker (Microsoft 365 E3 ohne Teams +11%, E5 ohne Teams +6%). Das betrifft auch Schweizer Kunden, da Microsoft die Teams-Entbündelung hier ebenfalls anbietet; auf microsoft.com heissen diese Pläne «EWR (ohne Teams)».
Microsoft begründet die Erhöhung mit einer Wertsteigerung der Suiten. Der Rollout der neuen Funktionen läuft seit Juni 2026 und soll bis am 1. August 2026 abgeschlossen sein; Tenants erhalten 30 Tage vorher eine Ankündigung im Message Center. Für E-Mail-Administratoren relevant:
Ein Benutzer verlässt die Firma – und plötzlich gehört ihm noch eine wichtige wiederkehrende Teams-Besprechung. Für Admins bedeutet das bis heute: unsaubere Workarounds oder kompletter Neuaufbau der Serie.
Microsoft hat nun ein neues PowerShell Cmdlet für Exchange Online angekündigt, das genau dieses Problem adressieren soll. In diesem Beitrag: was bereits bekannt ist, was noch fehlt und wie ihr prüft, ob das Feature in eurem Tenant verfügbar ist.
Für verwaiste Meeting-Serien gab es bisher nur drei Optionen:
Keine dieser Varianten ist in produktiven Umgebungen wirklich zufriedenstellend.
Das neue Exchange Online Cmdlet soll es ermöglichen, den Organisator eines Meetings oder einer gesamten Serie zu ändern – ohne Neuaufbau und ohne Verlust der Historie.
Der neue Organisator soll dabei vollständig übernehmen:
Phishing-Angriffe setzen oft nicht auf gefälschte Domains oder komplexe Technik – sie missbrauchen einfach den Anzeigenamen im Absenderfeld einer E-Mail. Das nennt sich Display Name Spoofing, und es ist erschreckend einfach umzusetzen.
Der Anzeigename im Absenderfeld («From») ist frei wählbar – z. B. Hans Muster, CEO. Die eigentliche Absenderadresse (z. B. hans.muster.ceo@betrug-mail.com) stimmt dabei nicht mit der Identität überein. Viele Mailprogramme zeigen standardmässig nur den Anzeigenamen an, die vollständige Adresse bleibt verborgen.
Typische Merkmale:
Bei reinem Display-Name-Spoofing schlägt SPF/DKIM/DMARC nicht fehl – die Absenderdomain (z. B. @gmail.com) ist technisch legitim authentifiziert. Microsoft Defender for Office 365 setzt deshalb auf eine Kombination aus modernen Erkennungsmethoden:
E-Mail ist nach wie vor das wichtigste Kommunikationsmittel im Geschäftsalltag – und gleichzeitig eines der beliebtesten Angriffsziele. Phishing, Spam und Domain-Spoofing nehmen zu. Mit SPF, DKIM und DMARC stehen drei bewährte Mechanismen zur Verfügung, die zusammen einen wirksamen Schutz bilden. In diesem Beitrag erkläre ich, wie die drei Protokolle funktionieren, was Alignment bedeutet und welchen konkreten Nutzen die Auswertung von DMARC-Reports bringt.
SPF (Sender Policy Framework) legt fest, welche Mailserver berechtigt sind, E-Mails im Namen einer Domain zu versenden. Der Eintrag wird als TXT-Record im DNS veröffentlicht. Exchange Online-Kunden verwenden typischerweise:
v=spf1 include:spf.protection.outlook.com -allDKIM (DomainKeys Identified Mail) versieht ausgehende E-Mails mit einer digitalen Signatur. Der empfangende Mailserver kann anhand eines öffentlichen Schlüssels im DNS prüfen, ob die Nachricht unverändert ist und wirklich von der angegebenen Domain stammt.
DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf. Es legt fest, wie ein empfangender Mailserver mit Nachrichten umgehen soll, die die Prüfungen nicht bestehen – und liefert Reports darüber, was im Namen der eigenen Domain versendet wird.