Ich mache meinen Job im Support lange genug, dass ich sagen kann: Es wurde ja auch Zeit. Es gibt nun die Exchange Online Mailflow Alert Policies bei Office 365. Ihr glaubt ja gar nicht, wie viele Support-Anfragen immer wieder eintrudeln, in denen es genau darum geht, dass irgendwas mit dem Nachrichtenfluss nicht stimmt. Es wäre doch wirklich wünschenswert, wenn ausgewählte Leute darüber in Kenntnis gesetzt werden würden. Und genau das passiert nun. Also: Es ist davon auszugehen. Schauen wir mal.
Exchange Online Mailflow Alert Policies – Ein langer Begriff
Ich lache ja gerade, steht doch im „deutschsprachigen“ Hilfeartikel von Microsoft zu den Exchange Online Mailflow Policies der Begriff „Warnungsrichtlinie“. Was soll das sein? Nein, das lassen wir mal schön bleiben. Jedenfalls kann ich im Exchange Admin Center die Ereignisse nachvollziehen, die im Zusammenhang mit dem Mailflow auftreten können. Ereignisse gibt es viele. Wenn ich die notwendigen Berechtigungen habe, kann ich das nun mit verfolgen.
Ich muss zur Gruppe „Security Administrator“ hinzugefügt worden sein. Dann kann ich solche Richtlinien erzeugen, verwalten und natürlich lesen. Wenn nur das Lesen erforderlich ist, reicht der „Security Reader“ aus. Das sind RBAC-Rollen, die vor dem Einsatz der Exchange Online Mailflow Alert Policies eingerichtet sein müssen. Ach ja, und die Organisation muss entsprechend lizenziert sein, sonst geht es nicht. Mit diesen Lizenzierungen geht es wohl:
- Microsoft 365 Enterprise subscription
- Office 365 Enterprisesubscription
- Office 365 US Government E1/F1/G1 subscription
- E3/F3/G3 subscription
- E5/G5 subscription
- Office 365 GCC environment
- GCC High environment
- DoD US government environment
Als Beispiel: Wenn die Organisation über eine E3 Subscription und Defender verfügt, dann kann ich die Alerts verwenden. Oder ich verfüge über E5, dann klappt es auch. Microsoft macht da wieder viel rum. Aber es ist nun einmal eine Dienstleistung, und die kostet nun einmal Geld. Oder anders gesagt, nur wenn ich über eine entsprechend ausreichende Lizenz verfüge, kann ich die Exchange Online Mailflow Alert Policies einsetzen.
Was mache ich denn nun damit? – Oder: Raider heißt jetzt Twix!
Purview? Was ist dann denn jetzt wieder? Purview ist das Compliance Center. Ja, Raider heißt jetzt Twix, sonst ändert sich nix. Jedenfalls kann ich dort die Exchange Online Mailflow Alert Policies definieren und verwalten. Und zwar unter Policies -> Alert Policies. Und ich kann die Alerts sehen. Unter Alerts. Aber dort grinst mich die Meldung an, dass ich ins Exchange Admin Center wechseln soll. Also machen wir das. Dort stehen dann die letzten Alerts. Aber kann ich dort neue anlegen? Irgendwie nicht.
Daran merkt man aber, dass hier wirklich das RBAC-Modell zieht. Wenn ich nicht die Berechtigungen habe, kann ich mich auf den Kopf stellen, ich werde dort nichts machen können:
Mit entsprechenden Berechtigungen angemeldet, sehe ich die Alerts und die Policies. Ich kann zum Beispiel sehr genau erkennen, ob es eine Richtlinie gibt, die irgendwen darüber informiert, wenn Emails verzögert versendet werden. Die ist vorhanden, sie ist eine Standard-Richtlinie. Aber da ist dann schon das grundsätzliche Prinzip solcher Richtlinien erkennbar. Ich sehe, wie eine Richtlinie heißt, wonach sie sucht und wen sie informiert.
Bei der Standard-Richtlinie „Messages have been delayed“ warnt Office 365, wenn der On-Premises Partner der Hybrid-Umgebung keine Emails von dem Cloud-Teil eurer Hybrid-Umgebung empfangen kann. Die Warnung wird an die Tenant Admins geschickt, wenn der Schwellenwert von 2000 Emails überschritten wird.
Und was mache ich mit einer neuen Policy?
Natürlich ist das Ganze jetzt einfach nur Spielerei. Mir geht es auch darum, dass ich zeige, was mit Exchange Online Mailflow Alert Policies so möglich ist. Die Richtlinie im Screenshot informiert mich, wenn der Testuser eine Inbox-Regel definiert, die Emails weiterleitet oder umleitet. Manchmal ist das sinnvoll, wenn nämlich ein Postfach sensible Daten erhält. Die sollten dann nicht unbedingt wahllos weitergeleitet werden.
| Filter | Activity.UserId -eq ‚Test.User@XXXX.com‘ |
| Operation | MailRedirect |
| NotificationEnabled | True |
| NotifyUser | henning.uhle@XXXX.com |
| Severity | Low |
Mit solchen Exchange Online Mailflow Alert Policies könnt ihr feststellen, was eure User so in der Cloud treiben. Denn eines ist mal sicher: Microsoft 365 funktioniert am besten, wenn es so genutzt wird, wie es vorgesehen ist. Natürlich kann ich riesige Verteiler definieren und meine Riesen-Emails (Mail Bomb) durch die Gegend jagen. Die Frage ist halt, ob ich damit nicht gleich den ganzen Tenant negativ beeinflusse. Sinnvoller ist allerdings, im Fehlerfall informiert zu werden.
Policies ausmisten
Es ist ja das Eine, die Exchange Online Mailflow Alert Policies anzulegen und damit im Zweifelsfall mit Emails bombardiert zu werden. Denn es ist nun mal so, dass „laut Murphy“ immer aller Eventualitäten auf einmal auftreten. Das Andere ist, dass man von Zeit zu Zeit schaut, ob man die eine oder andere Policy noch braucht. Wer weiß, vielleicht wollt ihr euch das per PowerShell aufrufen, dann wäre das dieser Befehl zum Beispiel:
Get-ProtectionAlert | fl name,createdby,whencreated,filter
Und dann könnt ihr die Policies, die ihr nicht mehr braucht, auch problemlos wieder löschen. Entweder markiert ihr die jeweilige Policy im Admin Center, sodass das Einstellungsfenster dazu geöffnet wird. Dort könnt ihr dann auf „Delete Policy“ klicken. Oder ihr nutzt „Remove-ProtectionAlert“, wenn ihr ohnehin in der PowerShell unterwegs seid. Bei unserer Test-Policy ist das dann also:
Remove-ProtectionAlert -Identity "Test"
Und was ist mit den Filtern? Mit denen kann man genüsslich herumspielen. Wir können uns für alles mögliche Exchange Online Mailflow Alert Policies anlegen. Was wir dabei an Alarmen festlegen, steht dann hier:
Get-ProtectionAlert | where {$_.Category -eq "MailFlow"} | Sort-Object "Severity" | ft name,severity,notifyuser,filter,thresholdUnd ihr werdet lachen: Obwohl wir unsere Policy eben gelöscht haben, wird sie hier weiter aufgeführt. Das ist aber der Alert. Den muss ich gesondert löschen. Und da es sich um einen Mailflow Alert handelt, muss ich den im Exchange Admin Center löschen:
Ihr müsst eure Policy aber erst deaktivieren, dann kann sie gelöscht werden. Ich nehme an, dass irgendwann Support-Anfragen eintreffen werden, in denen es genau darum geht, wie man einmal erstellte Policies wieder loswird. Sonst finde ich das ganze Thema ja ziemlich gut. Ich habe über den Andres Bohren davon erfahren. Aber man denkt sich halt, dass „Delete“ eben auch „Löschen“ bedeutet. Mir scheint aber, dass das nicht grundsätzlich zutrifft.
Habt ihr schon Erfahrungen mit den Exchange Online Mailflow Alert Policies gemacht? Wenn ja, welche Erkenntnisse habt ihr gesammelt? Würdet ihr euch selbst Policies definieren? Was haltet ihr im Allgemeinen davon? Das würde mich alles mal interessieren.