Ich ziehe mal zwei Themen rund um Exchange Online und Outlook in einem Sammelbeitrag zusammen. Mir sind die Tage zwei Meldungen über Probleme bei Shared Mailboxen untergekommen – dürfte Exchange Online betreffen. Und es ruckelt seit Tagen mit den Microsoft 365-Diensten – komme gar nicht mehr dazu, alle Statusmeldungen hier im Blog einzustellen. Hier ein Überblick, was mir so untergekommen ist.
Leserfrage zu Shared-Mailbox-Problemen
Der erste Fall ist mir am Dienstag, den 29. Oktober 2024, untergekommen, als Blog-Leser Julian B. in einer privaten Nachricht auf Facebook fragte, ob „ich schon was gehört habe, dass Microsoft Probleme mit Shared-Mailboxen hat?“.
Musste ich verneinen, aber ich war ein langes Wochenende unterwegs und habe die Statusmeldungen zu Exchange Online nicht verfolgt. Heute Nacht ergänzte Julian noch, dass ihn „am Dienstag, 29. Oktober 2024, 2 Kunden anrufen, dass ihr Outlook bei allen Nutzern abgestürzt sei und die Shared-Mailboxen nicht mehr abrufbar waren“. Über „OWA“ funktionierte der Zugriff ebenfalls nicht. Nach ca 1-2 Stunden habe es wieder funktioniert.
Diskussion in einer Facebook-Gruppe
Am gestrigen 30. Oktober 2024 bin ich dann in einer geschlossenen Facebook-Grupp auf eine weitere Anfrage gestoßen. Dort hieß es von einem Teilnehmer zum 30. Oktober 2024, dass bei manchen Benutzern die gesendeten E-Mails im Postausgang landen und nicht versendet werden. Das Problem tritt nicht bei allen Benutzern auf. Der Thread-Starter fragte, ob jemand eine Idee habe.
Es gab dann einige Reaktionen, die von Problemen mit Exchange Online-Diensten berichteten. Ein Administrator schrieb „Hatte gestern [war der 29.10.2024] bei einer Shared-Mailbox genau das selbe Problem. SharedMailbox und User-Account mit der Berechtigung einmal entfernt und anschließend wieder eingebunden – hat funktioniert.“
Ein weiteres Gruppenmitglied merkte an, dass er jemand aus der Anwenderschaft habe, der Termine im Auftrag erstellen muss und diese dann nicht unter „gesendete Elemente „auftauchen. Betraf Exchange Online, und es funktionierte weder im Outlook Classic noch in der Webversion. Bei anderen Nutzern funktionierte es aber. Er schrieb von „Exchange-Outlook-Gedöns“.
Exchange Online sortiert Mails als Phishing ein
Gerade hat ein Blog-Leser in diesem Kommentar auf den Artikel Microsoft 365 Alert – Service Degradation – Exchange Online – Users’ legitimate inbound email messages containing specific URLs are being incorrectly marked as phish – NEW verwiesen. Laut Statusmeldung werden seit dem 30. Oktober 2024 eingehende legitime E-Mail-Nachrichten von Benutzern, die bestimmte URLs enthalten, fälschlicherweise als Phishing-Nachrichten markiert.
Microsoft hat festgestellt, dass seine automatisierten Anti-Spam-Verfahren E-Mail-Nachrichten auf der Grundlage bestimmter URLs fälschlicherweise blockieren, was dazu führt, dass eingehende E-Mail-Nachrichten aufgrund einer als bösartig eingestuften Signatur als Phishing markiert und in Quarantäne gestellt werden. Die Logik des maschinellen Lernens, die hinter den Quarantänen steht, wird derzeit weiter überprüft, um die Möglichkeiten zur Abhilfe zu bewerten.
Es rumpelt doch die ganze Woche
Den Kommentaren zum Artikel Exchange Online mit Zugriffsproblemen (21.10.2024) zufolge, rumpelt es aber seit einer Woche kontinuierlich. Am 24. Oktober 2024 hieß es z.B., dass eine Komponente der Mailbox-Datenbankinfrastruktur unter den akzeptablen Leistungsschwellenwerten lag. Soll behoben sein. Zum 29. Oktober 2024 gab es „Service-Degradations“, wie dieser Kommentar belegt. Es konnten teilweise keinen Mails verschickt oder empfangen werden. Noch jemand mit Problemen?
Ergänzung: Ein Leser hat mir noch folgenden Auszug aus Inciden-Berichten gepostet:
Issue ID: EX920584
Affected services: Exchange Online
Status: Service degradation
Issue type: Incident
Start time: Oct 29, 2024, 9:39 AM GMT+1More info
Impacted connection methods include but aren’t limited to:– Representational State Transfer (REST)
– Messaging API (MAPI)Scope of impact
Impact is specific to some users who are served through the affected Germany and North America infrastructure.Root cause
Imbalanced resource utilization on an affected service dependency is causing impact.Current status
Oct 30, 2024, 3:30 PM GMT+1
We’re continuing with our efforts of deploying the aforementioned solution and are monitoring it’s progress.
Next update by:
Wednesday, October 30, 2024 at 9:00 PM GMT+1In dem Fall hat es unser Postfach für den Helpdesk getroffen. Tickets kamen so nicht seit gestern nicht mehr ins System. Seit eben sind die Mails wieder da.
Das konnte ich diese Woche auf jeden Fall auch beobachten. Bis Mittwoch waren schon 14 Incidents, 7-mal angebliches Phishing, 7-mal hat der User einen Release aus der Quarantäne angefragt.
Das ist mehr als in der ganzen letzten Woche zusammen.
Den „hängenden“ Postausgang kann ich hier mit mehreren Fällen bestätigen. Das ist tatsächlich auch noch aktuell ein Problem.
Tja, Cloud halt… ;)
Ich hatte bei ein paar Usern den Fall, dass deren E-Mails unter „Gesendete Elemente“ abgelegt wurden, diese aber im OWA als „Postausgang“ deklariert sind.
Abhilfe hat hier eine Migration auf eine andere Datenbank via EXO-Powershell geschaffen. Könnte dein Problem lösen.
– xSOU1 | Jul
@xSOU1: „Migration auf eine andere Datenbank via EXO-Powershell“:
Kannst Du verraten, mit welchem PoSh-Befehl das in ExchangeOnline funktioniert?
Siehe folgende Notiz:
Powershell-Syntax:
##### EXCHANGE ONLINE MANAGEMENT #####
##### NOTIZ: PowerShell Admin !! #####
### Installiere Exchange Online Verwaltung
Install-Module -Name ExchangeOnlineManagement
### ggf. Ändern von Sicherheitsrichtlinien zum Ausführen
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
### Importiere EXO-Management (wenn bereits installiert)
Import-Module ExchangeOnlineManagement
### Verbinde zu Exchange-Online (mit Admin-Konto)
Connect-ExchangeOnline -UserPrincipalName {username@tenant.onmicrosoft.com}
### Starte Migrationsvorgang
New-MoveRequest {username@domain.com}
### Migrationsstatus abfragen
Get-MoveRequest | Get-MoveRequestStatistics | FT DisplayName,StatusDetail,TargetDatabase,TotalPrimarySize,BytesTransferred
### Nach Abschluss die REST-API sauber beenden und Verbindung zu EXO-MGMT trennen
Disconnect-ExchangeOnline
### Sicherheitsrichtlinien wieder standardisieren
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Viel Erfolg.
– xSOU1 | Jul
@xSOU1: Hochinteressant. Ich wusste gar nicht, dass man in Exchange Online Mailboxen auf andere Server verschieben kann mit dem Seiteneffekt:
„Its use however quickly spread beyond that scenario, as moving the mailbox to a different database has the side effect of restamping some properties and fixing some rather common issues. It also helps in situations when the MRM processing of the mailbox fails, say due to some issue with the underlying hardware, which Microsoft’s monitoring failed to capture in a timely manner.“
Quelle: https://www.michev.info/blog/post/2927/microsoft-to-retire-new-moverequest-for-local-mailbox-moves-in-office-365
Wenn es geklappt hat, schön. Als Admins sollten wir alle an einem Strang ziehen.
War mir auch neu, bis ich auf Reddit Schnippschen an Infos dazu gefunden hab.
Interessanterweise werden die DBs teilweise auf unterschiedlichen Versionen gefahren.
– xSOU1 | Jul
Am 29. war es bei uns am schlimmsten. Mehrere User konnten nicht auf Ihre Postfächer per Outlook zugreifen. Bei anderen hakte es ständig. Zugriff über office.com ging.
Mit Mails in Quarantäne haben wir schon Monate zu kämpfen. Ser viele Mails werden falsch erkannt.
Bei uns gab es keinerlei Probleme > 150 User
Kommt in die Cloud haben sie gesagt… :)
Die Probleme mit einem total langsamen Outlook 365 Classic (nicht Web), sich zwischendurch auch mal total aufhängendem Outlook, mehrfache Zugriffsprobleme auf freigegebene Postfächer, insbesondere seit Anfang dieser Woche (begann allerdings auch schon letzte Woche), kann auch ich absolut bestätigen…
Wir hatten auch keine Probleme, ca. 500 Benutzer.
Hier läuft alles super, keine Probleme:-)
5000 Postfächer auf lokaler Exchange Farm.
Bei Exchange Online Tests hatte ich diese Woche auch Probleme, immer wieder Hänger (Outlook im Online-Mode für Tests).
Wir hatten die gleichen Probleme. 500 migrierte User. Shared Mailboxen oft nicht erreichbar und falsch gefilterte Emails. Damit sind wir bei Office 364 angekommen.
Hallo zusammen, zur Info – das ganze geht munter weiter.
Es kommen täglich neue EX-IDs – heute zB EX925719 – diese werden dann aber meistes innerhalb einer Stunde geschlossen – mit Hinweis auf das IMMER NOCH offene:
EX920584 Startzeit: 29. Okt. 2024, 09:39 MEZ
( Davor gab es auch welche – diese wurden aber immer geschlossen – das Thema besteht schon länger! )
Unter dieser ID wird alles geführt. Wir hatten jetzt auch schon 2 Termine mit MS per Teams – wurde auch bestätigt – allerdings kann man weiterhin nicht sagen, wann MS gedenkt, das abgestellt zu haben. Glück für die, die nicht betroffen sind ;-)
Anbei mal der gesammelte Verlauf:
Some users may be unable to access their Exchange Online mailboxes through most connection methods
Problem-ID: EX920584
Betroffene Dienste: Exchange Online
Status: Dienstbeeinträchtigung
Problemtyp: Vorfall
Startzeit: 29. Okt. 2024, 09:39 MEZ
Benutzerauswirkungen
Users may be unable to access their Exchange Online mailboxes through most connection methods.
More info
Impacted connection methods include:
– Representational State Transfer (REST)
– Messaging API (MAPI)
– Exchange ActiveSync (EAS)
– Outlook on the web
Users who access the service through Internet Message Access Protocol (IMAP) aren’t impacted by this event.
Scope of impact
Impact is specific to some users who are served through the affected infrastructure.
Root cause
Imbalanced resource utilization on an affected service dependency is causing impact.
Aktueller Status
4. Nov. 2024, 21:20 MEZ
We’re preparing to test the efficacy of the fix in a small section of the affected infrastructure and will deploy it to the impacted environment once it’s proven to remediate impact.
Next update by:
Dienstag, 5. November 2024 um 22:00 MEZ
Updateverlauf
4. Nov. 2024, 03:38 MEZ
We’ve identified that a fix has been developed in our internal testing environment and our next steps are to test its efficacy in a small section of the affected infrastructure to ensure that it remediates the impact. If our tests are successful, we’ll expand the deployment to the remaining affected infrastructure.
2. Nov. 2024, 00:39 MEZ
We’re continuing our efforts to develop and validate fixes for the remaining affected connection methods. This is progressing in addition to our infrastructure optimization actions, and while we don’t yet have a timeline for resolution, we’ll provide one as soon as it’s established.
1. Nov. 2024, 19:45 MEZ
While our telemetry indicates that impact to the EAS connection method has subsided following our mitigating actions, we’re continuing to develop and validate fixes for the remaining connection methods. In addition to this, our efforts to increase the impacted infrastructure’s ability to balance resource utilization is ongoing. We’re monitoring service telemetry while these workstreams progress, and we’ll provide a timeline for the remaining fixes once it becomes available.
1. Nov. 2024, 00:43 MEZ
The EAS fix has nearly saturated all of the affected North America and Europe infrastructure and most users will see their access restored. We anticipate this process will be completed by our next scheduled update. Additionally, we’re continuing to implement a suite of performance optimizations within the impacted infrastructure to expedite the remediation process.
1. Nov. 2024, 00:41 MEZ
The EAS fix has nearly saturated all of the affected North America and Europe infrastructure and most users will see their access restored. We anticipate this process will be completed by our next scheduled update. Additionally, we’re continuing to implement a suite of performance optimizations within the impacted infrastructure to expedite the remediation process.
31. Okt. 2024, 19:34 MEZ
The previously mentioned fixes to resolve the infrastructure issues leading to impact are deploying as expected, and we’ll provide a timeline for full deployment as it becomes available. We’re additionally implementing a suite of performance optimizations within the impacted infrastructure to ensure that impact is remediated as quickly as possible.
31. Okt. 2024, 01:03 MEZ
The aforementioned fix is continuing to deploy, and as it saturates the environment, more users within the affected North America and Europe infrastructure who utilize EAS will see their access restored. Additionally, our review of service side logs for Outlook on the web has revealed that the infrastructure responsible for processing requests, is not functioning as expected. We’re in the process of developing a targeted fix for this issue, while continuing the process of allocating additional resources to rebalance the request traffic.
30. Okt. 2024, 22:55 MEZ
The aforementioned fix is continuing to deploy, and as it saturates the environment, more users within the affected North America infrastructure who utilize EAS will see their access restored. In tandem, we’re collecting service side logs for Outlook on the web to isolate the source of the increased resource utilization. To alleviate the impact for the affected Germany infrastructure, we’re working towards allocating additional resources to rebalance the request traffic.
30. Okt. 2024, 20:54 MEZ
The aforementioned fix is designed to revert a previously deployed service change which contained a regression that’s contributing to high resource utilization in the affected portion of infrastructure. This fix has reached a portion of the affected users in the North America infrastructure and some users who utilize EAS will begin to see service restored. We’re continuing to deploy this change to the remaining affected users; however, this change isn’t expected to fully remediate the impact and we’re continuing to review the portions of infrastructure for more opportunities to reduce the resource utilization and rebalance request traffic.
30. Okt. 2024, 15:30 MEZ
We’re continuing with our efforts of deploying the aforementioned solution and are monitoring it’s progress.
30. Okt. 2024, 11:39 MEZ
We’re proceeding with the deployment of our aforementioned solution. Additionally, we’re continuing to assess our available options for expediting the mitigation.
30. Okt. 2024, 06:28 MEZ
The deployment of our aforementioned solution is progressing. In parallel, we’re continuing to assess our available options for expediting the mitigation.
30. Okt. 2024, 04:51 MEZ
We’ve developed a solution to help rebalance request traffic and are currently in the process of deploying it. In addition, we’re assessing our available options for expediting the mitigation.
30. Okt. 2024, 00:56 MEZ
Our operation to redirect incoming traffic to alternate components of infrastructure is complete; however, our service telemetry indicates that impact is ongoing. We’re continuing to evaluate potential methods to rebalancing request traffic to resolve this issue as quickly as possible.
29. Okt. 2024, 23:08 MEZ
We’ve confirmed that the high resource utilization stemmed from necessary adjustments to redistribute mailboxes throughout our service environments and ensure our processes could operate as efficiently as possible. While we continue to consider options to most effectively rebalancing request traffic to relieve the impact, we’ve redirected incoming traffic to alternative portions of infrastructure to mitigate the extent of impact.
29. Okt. 2024, 19:48 MEZ
We’ve determined that there is an increased amount of traffic being directed into the affected portion of infrastructure responsible for facilitating access to Exchange Online mailboxes that’s causing the high resource utilization. We’ve paused recent service changes that may be contributing to the increased traffic and are exploring possible mitigation pathways to rebalance the request traffic.
29. Okt. 2024, 18:02 MEZ
While we continue to review the CPU logs, we’ve identified a change made yesterday designed to reduce high CPU usage and are reviewing the change to determine whether it’s related to the impact.
29. Okt. 2024, 15:34 MEZ
We’re continuing with our review of CPU traces and any recent changes made to the service that may be contributing to impact, in order to isolate the root cause and formulate a mitigation plan.
29. Okt. 2024, 13:35 MEZ
We’ve determined that there is a high resource utilization on the affected service dependency. We’re proceeding with our review of Central Processing Unit (CPU) traces, to isolate the root cause and establish a fix.
29. Okt. 2024, 11:31 MEZ
We’re continuing to review service monitoring telemetry, alongside Central Processing Unit (CPU) traces, to isolate the root cause and formulate a mitigation plan.
29. Okt. 2024, 09:40 MEZ
We’re reviewing service monitoring telemetry to isolate the source of the issue and establish a fix.