EXO Mailboxserver Insights
Wollten Sie nicht schon immer mal wissen wie Exchange Online seine Postfächer organisiert? Microsoft ist hier ja zurecht sehr verschlossen und gibt vermutlich nur in internen Meetings das ein oder andere Detail preis. Aber auch ohne Zugriff auf interne Quellen können Sie allein über die Exchange Online PowerShell einen ersten Einblick gewinnen. Sie brauchen dazu natürlich zugriff auf einen Microsoft 365 Tenant mit möglichst vielen Postfächern, um gute Daten zu erhalten.
Hinweis:
Am Ende stelle ich ein Skript zur Verfügung, mit dem sie
diese Werte schnell in ihrem Tenant auswerten können.
Überblick
Anhand der auf dieser Seite beschriebenen Schritte und Analysen habe ich folgendes Bild über die Verteilung von Postfächern auf Server, Datenbanken, DAGs und Regionen in Exchange Online gemalt.
All ihre Postfächer sind auf viele unterschiedliche Datenbanken verteilt, die von einer hohen Zahl an Servern gehostet sind, die ihrerseits natürlich in einem Cluster laufen, der auf mehrere Datacenter verteilt ist. All dieses Komponenten sind in einer größeren logischen Einheit, ich nenne sie mal POD, zusammengefasst. Und natürlich gibt es viel mehr Pods.
In den folgenden Abschnitten finden Sie heraus, wie Sie diese Information selbst für ihren Tenant auslesen
Startpunkt Postfach
Zuerst starten wir eine Exchange Online PowerShell, verbinden uns mit dem Tenant und holen eine Liste aller Postfächer. Für eine Analyse von Mailbox-Servern, Datenbanken etc. sind nur wenige Felder interessant.
PS C:>Get-mailbox –resultsize 1| fl servername,database,OrganizationalUnit ServerName : am0pr08mb2945 Database : EURPR08DG170-db093 OrganizationalUnit : eurpr08a002.prod.outlook.com/Microsoft Exchange Hosted Organizations/msxfaqdev.onmicrosoft.com
Microsoft liefert hier wirklich den Servernamen und die Datenbank mit. Mit etwas Phantasie können Sie auch das Namenskonzept erkennen, mit der Microsoft die Datenbanken und Server benennt.
AM0 = Amsterdam Datacenter0 PR08 = Production08 MB2945 = MailboxServer 2945
Auch bei der Datenbank gibt es ein Schema.
Die ersten drei Buchstaben dürften die Region darstellen und die weiteren Buchstaben ebenfalls den Production-Pools
EUR = Europa PR08 = Europäischer Server Production08 DGxxx = Kurzform für DatabaseGroup oder sogar DAG mit laufender Nummer - = Trenner dbxxx = Nummer der Datenbank
Demnach ist mein Beispiel EURPR08DG170-db093 die DAG170 in Europa im Pod PR08.
Postfachliste
Ich kann natürlich nicht per PowerShell nun alle Tenants mit allen Postfächern auslesen. Aber mit diesen Zahlen können wir schon etwas weiter spielen, wobei das natürlich mehr Spaß macht, wenn der Tenant wirklich sehr viele Postfächer hat. Zuerst holen ich mir mal die Liste der Postfächer in eine Variable, damit ich nicht immer wieder die Exchange Online Server abfragen muss. Zudem übernehme ich nur die Namen der Postfachserver und der Datenbanken. Damit entfallen Mailadressen, Benutzername, OUs und andere Daten, die einen Rückschluss auf den Tenant oder individuelle Benutzer erlauben würden.
PS C:>$mblist = get-mailbox –resultsize unlimited | select servername,database PS C:>$mblist.count 34742 PS C:>$mblist.count | export-csv EXOListe.csv
Der Export in eine CSV-Datei ist nicht zwingend erforderlich aber vielleicht stellen Sie mir ja ihre Liste für weitere Analysen bereit. Mit knapp 35.000 Postfächern ist der von mir abgefragte Tenant aber auch schon etwas größer.
Blick auf Datenbank
Zuerst hat mich interessiert, auf vielen Datenbanken insgesamt diese Postfächer verteilt sind. Dazu zähle ich einfach die unterschiedlichen Datenbanknamen, die ich vorher gruppieren lassen.
PS C:>($mblist.database | group -NoElement).count 28205
Das ist aus meiner Sicht eine stattliche Anzahl an unterschiedlichen Datenbanken. Nur wenige Postfächer liegen demnach auf der gleichen Datenbank.
Wenn der Teil "DGxxx" im Namen der Datenbank einen Rückschluss auf die DAG zulässt, dann scheinen diese Benutzer sich auf 473 DAGs verteilt:
PS C:>(($mblist.database).substring(7,5) | group -NoElement).count 473
Lösen Sie sich also von dem Gedanken, dass Microsoft die Postfächer einer Firma auf für die Firma bevorzugte Datenbanken ablegt. Es scheint hier keine Kopplung oder Zuweisung zu geben.
Region und "Pool"
Aus dem Namensschema kann ich aber noch andere Werte über eine Gruppierung auswerten. Aus der Datenbank dürfte sich eine Geo-Region als auch eine Gruppierung von Datenbanken ermitteln lassen. Ich bezeichne das im folgenden als "Pod", denn der Name ist sicher nicht ein "Clustername"
PS C:>($mblist.database).substring(0,7) | group -NoElement Count Name ----- ---- 34742 EURPR08
Anscheinend sind alle Postfächer auf dem gleichen Prod08-Pod. Auf der einen Seite macht dies bezüglich einer Partitionierung Sinn aber bedeutet auch, das ich mit einem Tenant alleine nicht die gesamte Anzahl an Pools ermitteln kann. Ich kann nur vermuten, dass es noch EUROPR07-01 gibt und wie weit nach oben Microsoft schon skaliert hat, kann ich so nicht zuverlässig ermitteln.
EUR PR08 EUR PR01 PR04 DEU P281 NAM PR20 NAM PR16
Die Liste ist sicher nicht vollständig aber zeigt das Prinzip, wie Microsoft die Datenbanken benennt und welche Rückschlüsse Sie ziehen können.
Je mehr CSV-Dateienich von anderen Tenants einsammle, desto genauer werden die Abschätzungen
Servername
Neben dem Datenbanknamen bekomme ich pro Postfach auch einen Servernamen geliefert. Auch über den Servernamen sind interessante Auswertungen möglich. Zuerst wollte ich wissen, auf wie vielen Servern meine Postfächer denn verteilt sind. Das geht wieder einfach über eine Gruppierung:
PS C:>(($mblist.servername) | group -NoElement).count 6982
Fast 7000 Server ist eine stattliche Anzahl aber natürlich weniger als die Anzahl der Datenbanken. Im Schnitt liegen demnach in diesem Tenant ca. fünf bis sechs Benutzer auf dem gleichen aktiven Server. Bei einem Ausfall eines Servers sind kurzfristig nur wenige Benutzer betroffen und dank der DAG sollte die Funktion natürlich schnell wieder auf einem anderen Server verfügbar sein.
Sie können nun sicher ermessen, wie unsinnig die Überwachung von Exchange Online mittels test-Postfächern in der Cloud ist. Sie müssen schon dem Microsoft Status vertrauen, denn jeder Test misst nur einen ganz kleinen Ausschnitt.
Wenn ich die Anzahl der Server durch die DAGs teile, komme ich auf 14,7 Server pro DAG. Bei einem selbst betriebenen Exchange Server wären bis zu 16 Server pro DAG möglich und könnte ein Hinweis auf einen „freien“ Lagged-Server oder Standby Server pro DAG sein. Es dürfte aber unwahrscheinlich sein, dass Microsoft in der Cloud den Exchange Code auf mehr DAG-Mitglieder angepasst hat. Die Werte passen einfach zu gut.
Der Servername erlaubt mir weiterhin einen Rückschluss auf den Pod und hier hatte ich erwartet, dass der PR08 das einzige Ergebnis ist:
PS C:>($mblist.servername).substring(3,6) | group -NoElement Count Name ----- ---- 31408 pr08mb 4 spr01m 1508 pr0802 1817 pr0801 1 spr00m 4 sprmb0
Der überwiegende Teil der Server hat auch tatsächlich ein „pr08mb“ im Namen aber anscheinend gibt es noch einige Postfächer auf anderen Servernamen. Ich wollte natürlich wissen, was da besonders ist und haben mir die fraglichen Postfächer mit folgendem Befehl ausgeben lassen. Vielleicht sind das ja z.B. Teams Room Postfächer oder Group Mailboxen für Teams-Teams?
Hinweis: Diese Auswertung nach Postfächern funktioniert nur, wenn Sie am Anfang beim Export auch den Postfachnamen mit übernommen haben.
PS C:>$mblist | ?{$_.servername.substring(3,6).startswith("spr")}
Ich habe das temporäre in diesem Tenant gemacht aber die Liste der Postfächer enthielt auch ganz reguläre Postfächer und auch der Datenbankname entsprach dem klassischen Schema.
Sie können also nicht davon ausgehen, dass Alle alle Postfächer ihres tenant im gleichen "Pod" liegen. Leider ist nicht über die Pod-Struktur öffentlicht.
Zu diesen Postfächern habe ich mir auch die Servernamen angezeigt und auch hier konnte ich abweichende Namen sehen:
PS C:>ServerName ---------- am0spr01mb0048 am5spr00mb240 as1sprmb0027 as8sprmb0032 db9sprmb0032 du0sprmb0013 pazspr01mb0001 pazspr01mb0001 vi1spr01mb0384
Diese Server passen nun gar nicht zum Namenskonzept der Mehrheit mit einem "PR08MB"-Prefix. Vielleicht führt Microsoft aber auch gerade eine neue Generation an Servern und einem abgewandelten Namenskonzept ein. Da werde ich wohl in einigen Monaten noch mal eine Auswertung starten.
Datacenter-Ansicht
Die ersten drei Stellen der Servernamen scheinen das Datacenter preiszugeben, also den realen Ort auf der Welt. Diese Liste ist erstaunlich lange, weswegen ich sie komplett wiedergebe.
PS C:>($mblist.servername).substring(0,3) | group -NoElement Count Name ----- ---- 1957 am0 525 am4 709 am5 2505 am6 374 am7 636 am8 863 am9 68 as1 245 as2 299 as4 2066 as8 38 db3 93 db4 37 db5 978 db6 1120 db7 1078 db8 853 db9 502 dba 1858 dbb 382 du0 129 du2 307 gv1 280 gv2 69 gvx 1091 he1 741 pa4 131 pav 151 paw 721 pax 2 paz 229 pr2 352 pr3 1165 ve1 3088 vi1
Auf insgesamt 35 verschiedenen Datacenter in 9 verschiedenen Regionen sind die Postfächer verteilt. Ich versuche mal eine Einordnung nach Servernamen der Region:
Amsterdam (Niederlande) ! am0 am4 am5 am6 am7 am8 am9 ??? ! as1 as2 as4 as8 Dublin (Irland) ! db3 db4 db5 db6 db7 db8 db9 dba dbb ??? ! du0 du2 Gävle (Schweden) ! gv1 gv2 gvx Helsinki /Finnland) ! he1 Paris ! pa4 pav paw pax paz ??? ! ve1 Wien ! vi1
Ich vermute mal, dass z.B. "am0"-"am9" alle das gleiche Datacenter in Amsterdam sind aber entweder verschiedenen Bauabschnitt, Brandabschnitte oder in sich eigenständige Einheiten. Bei anderen Tenants habe ich noch andere Server und Regionen gefunden.
Berlin (D) ! be0 be1 ? (US) ! bl0 bl2 bla blu ? (US) ! bn3 bn6 bn8 ? (US) ! by1 by2 by5 bya Frankfurt (D) ! fr0 fr1 fr2 fr3 fry ? (US) ! co1 co2 co6 Chicago? (US) ! mw2 mw3 mwh ? (US) ! mn2 Philadelphia (US) ! ph0 San Jose ? (US) ! sj0 ? (US) ! sn1 sn6 ? (US) ! sa0 ? (US) ! dm3 dm5 dm6 ? (US) ! cy1 cy4
Die Zuordnung eines 2-stelligen Buchstabencodes zu einem Land ist nicht einfach.
- Ihre Microsoft 365-Daten werden in Microsoft-Rechenzentren in Deutschland
gehostet.
https://www.microsoft.com/de-de/microsoft-365/microsoft-365-local-datacenter -
Hollands Kroon, Nederland
https://local.microsoft.com/de/communities/emea/north-holland/ -
Sverige: Gävle, Sandviken och Staffanstorp
https://local.microsoft.com/sv/communities/emea/sweden/
Skript
Ich habe auf dieser Seite jede Menge Einzeiler in PowerShell dokumentiert, mit denen Sie ihren Tenant auswerten können. Hier gibt es das ganz aber auch noch mal als Skript. Es gibt zwei Betriebsarten:
- Exchange PowerShell
Wenn Sie das Skript einfach so starten, versucht es mit einem "Get-Mailbox" alle Postfächer zu lesen und die relevanten Daten zu extrahieren. Sie müssen dazu natürlich entweder On-Premises die Exchange Powershell gestartet haben oder in Exchange Online mit "Connect-ExchangeOnline" sich verbunden haben. - Input aus CSV-Datei
Sie exportieren die Daten mit folgendem Befehl aus einem Tenant in eine CSV-Datei. Das kann auch ein Kunde sein, der ihnen diese Datei dann zusendet. Das Skript kann über den Parameter "-filename" den Dateinamen erhalten und diese einlesen.
get-mailbox -resultsize unlimited | select ServerName,Database | export-csv mbliste.csv
Die Ausgabe ist ein PSObject mit den Werte. Die Ausgabe kann von ihnen natürlich weiter verarbeitet werden:
# parse-exombx.ps1 # # Script to analyse a get-mailbox | select ServerName,Database | export-csv filename # [cmdletbinding()] param ( $filename = "" ) Write-Host "Parse-exmombx: Start" if ($filename -eq "") { Write-Verbose "No Filename given. Try Exchange PowerShell" try { $mblist = Get-Mailbox -resultsize unlimited | Select-Object ServerName,Database } catch { Write-error "Unable to get Mailbox from Exchange -please run in exchange powershell" } } try { Write-Verbose "try importing CSV" $mblist = import-csv $filename | Select-Object ServerName,Database if ($mblist.count -eq 0) { write-Error "Missing property ServerName" -ErrorAction Stop } else { Write-verbose "Total Lines $($mblist.count)" } if (!$mblist[0].database) { write-Error "Missing property Database" -ErrorAction Stop } if (!$mblist[0].ServerName) { write-Error "Missing property ServerName" -ErrorAction Stop } } catch { Write-Error "Unable to import File $($filename) Error:$($_)" exit } Write-Host "Parse-exmombx: Start Analysis" $result = [pscustomobject][ordered] @{ databasecount = (($mblist.database | Group-Object -NoElement).count) DAGCount = (($mblist.database).substring(7,5) | Group-Object -NoElement).count PODCountDB = (($mblist.database).substring(0,7) | Group-Object -NoElement).count PODName = (($mblist.database).substring(0,7) | Group-Object -NoElement).name Servercount = (($mblist.servername) | Group-Object -NoElement).count PODCountServer = (($mblist.servername).substring(3,6) | Group-Object -NoElement).count DatacenterCount = (($mblist.servername).substring(0,3) | Group-Object -NoElement).count DatacenterList = (($mblist.servername).substring(0,3) | Group-Object -NoElement).name PODlistServer = (($mblist.servername).substring(3,6) | Group-Object -NoElement).name } $result Write-Host "Parse-exmombx: End"
Kopieren Sie die Zeilen einfach über die Zwischenablage in Notepad und speichern Sie als Textdatei mit der Endung PS1 ab.
Zwischenstand
Wenn ich die Werte so zusammennehme, dann haben liegt dieser Tenant in EUR und dem PR08-Bereich, in dem es sehr viele DAGs mit noch mehr Datenbanken auf Servern in ganz Europa gibt. Allerdings ist eine Datenbank natürlich immer nur auf einem Server aktiv, so dass ich nicht ermitteln kann, wie auf wie viele Server und welche Regionen eine Datenbank repliziert wird. Dazu müsste ich vielleicht diese Auswertung immer wieder machen und drauf hoffen, dass Microsoft im Hintergrund eine Datenbank auf verschiedenen Servern aktiviert. Mit noch mehr Daten könnte das Bild dann immer klarer werden.
Wenn Daten vieler Tenants vorliegen, könnte man die Anzahl der Pods, ihrer Verteilung über Datacenter und anhand der Nummern die Anzahl der Server pro Pod und Datenbanken pro Pod und DAG abschätzen.
Auf der anderen Seite muss ich mir natürlich die Frage stellen, welchen zusätzlichen Wert solche eine erweiterte Analyse bringen würde. Sie wäre sowieso nur auf der Postfächer des einen Tenants ausgerichtet und nur die wenigen Datenbanken und Server eines Teilbereichs sehen.
Wenn Sie mögen, können Sie mir gerne ihre Liste "EXOListe.csv" per Mail zusenden. Interessant fände ich noch größere Tenants und insbesondere "MultiGeo"-Tenants. Bislang waren alle Tenants immer nur in genau einem Pod.
Aber anhand der Daten sollten wir alle verstehen, dass Microsoft sehr viele Exchange Server betreibt und die Benutzer eines Tenants über viele Server und Datenbanken verteilt sind. Eine eigene Überwachung von "Exchange Online" über aktive Tests ist damit eigentlich wertlos. Es reicht aus, die Latenzzeit zu https://outlook.office.com und die Zwischenstationen zu überwachen und ansonsten den Dienststatus per Graph (siehe Office 365 Status) abrufen oder sich über das Microsoft 365 Message Center benachrichtigen zu lassen.
Weitere Links
- Data Residency
- Office 365 Region
- Office 365 Status
-
Hollands Kroon, Nederland
https://local.microsoft.com/de/communities/emea/north-holland/ -
Sverige: Gävle, Sandviken och Staffanstorp
https://local.microsoft.com/sv/communities/emea/sweden/ - Ihre Microsoft 365-Daten werden in Microsoft-Rechenzentren in Deutschland
gehostet.
https://www.microsoft.com/de-de/microsoft-365/microsoft-365-local-datacenter - Beschreibung des Exchange Online-Dienstes
https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description