Multi Geo Tenant

Firmen mit eigenen Servern müssen meist Kompromisse zwischen Anzahl der Server, der Standorte und den Arbeitsplätzen der Mitarbeiter finden. Office 365 hat weltweit verteilte Datacenter. Da könnte man doch z.B. das Postfach des Anwender in die "Nähe" zum Anwender bringen. Diese Seite beschreibt die Wege und Methoden.

Note that Office 365 Multi-Geo is not primarily designed for performance optimization, it is designed to meet data residency requirements.
Quelle. https://docs.microsoft.com/en-us/Office365/Enterprise/office-365-multi-geo.

MultiGeo ist aktuell nur für Kunden mit einem "Enterprise Agreement" (EA) verfügbar und müssen mindestens 250 Benutzer haben und mindestens 5% davon als "Multi Geo" lizenzieren. MultiGeo ist nicht für CSP-Kunden verfügbar.

Das Feld "PreferredDataLocation ist nicht mit dem Feld UsageLocation zu verwechseln.

Warum?

Ehe Sie über MultiGeo nachdenken, sollten Sie ein paar Aspekte vorab prüfen, ob sie überhaupt daran interessiert sind:

  • Komplexität
    Die allermeisten Firmen werden auch zukünftig mit einem Tenant in genau einer Region arbeiten. Die Vorteile einer Datenablage in verschiedenen Regionen wird mit einer höheren Komplexität erkauft, z.B. gibt es dann mehrere DNS-Namen für z.B. Sharepoint/OneDrive. Statt msxfaq.sharepoint.com bekommen Sie es dann z.B. mit msxfaq-emea.sharepoint.com, msxfaq.nam.sharepoint.com, msxfaq-apac.sharepoint.com etc. zu tun.
  • Mindestbenutzer
    Die Konfiguration unterscheidet sich auch im Backend und daher sind MultiGeo-Firmen etwas "anders". Microsoft aktiviert MultiGeo erst ab einer bestimmten Benutzeranzahl. Die Untergrenze ist mittlerweile aber auf 250 lizenzierte Benutzer gefallen und daher die kleinste Hürde.
    Quelle https://techcommunity.microsoft.com/t5/office-365-blog/multi-geo-reduced-seat-minimum-and-expanded-geo-coverage/ba-p/1310777
  • Lizenzbedarf = Kosten
    MultiGeo ist eine AddOn-Lizenz (ca. 2 US$/User/Monat) für Office365/Microsoft 365 F1/F3/E1/E3/E5-Pläne. Es gibt noch weitere Besonderheiten bei Ressource-Postfächern etc.
  • Eignung der Software
    Dann sollten Sie prüfen, ob die verwendete Cloud-Komponente auch MultiGeo kann. Exchange Postfächer "in der Nähe" des Benutzers erscheinen sinnvoll aber dank Cache-Mode ist der Nutzen zu hinterfragen. Teams Audio/Video nutzt auch ohne MultiGeo die naheliegende MCU des ersten Teilnehmers und OneDrive synchronisiert auch so ihre Daten. Ein Online-Zugriff auf SharePoint klingt interessant, wenn die Anwender auch überwiegend regional arbeiten. Azure VMs und Services können schon seit je her auf Standorte festgelegt werden.

Mit diesen Hintergrundinformationen bleiben nur zwei Aspekte übrig:

  • Latenzzeit
    Sie haben tatsächlich Applikationen, für die eine "kurze Verbindung" essentiell ist, d.h. 20-80ms sind nun mal besser als 120-200ms in die nächste Region.
  • Juristische/Compliance-Vorgaben, DSGVO u.a.
    Das ist aus meiner Sicht das primäre Argument für MultiGeo. Wenn die Staaten und ihre Rechtsabteilung aufgrund der Gesetze und Vorschriften einen MultiGeo-Betrieb als einzige und zwingende Lösung vorsieht, dann sind die Zusatzkosten durch Lizenzen, Migration, Komplexität nicht weiter relevant.

Nach meinem Wissen ist MultiGeo eine Einbahnstraße, d.h. ein Zurück ist aktuell nicht vorgesehen.

Datenschutz und Regularien

Microsoft hat lange Jahre immer gesagt, dass es "Regionen" in Office 365 gibt. Es gibt also gar kein weltweit großes Office 365 (Azure) Active Directory, sondern eher mehrere Forests in verschiedenen Regionen. Das wurde auch mit der Lokalität der Daten begründet, damit eine Firma in Deutschland sicher sein konnte, dass ihre Postfächer, SharePoint-Daten aber auch Active Directory Informationen im europäischen Datenraum liegen. Dazu passen dann auch die verschiedenen Gerichtsverfahren, bei denen z.B. US-Ermittler von Microsoft verlangt haben, Daten eines Postfach aus Europa in den USA bereit zu stellen.

Für die, die sogar die Ablage innerhalb der deutschen Grenzen erfordern, gibt es mit der DE Cloud - die deutsche Microsoft Cloud eine Lösung, die laut Aussage von Microsoft und dem Datentreuhänder (Telekom) auf jeden Fall "in Deutschland" bleibt. Allerdings betrifft dies erst mal nur den Datenbestand, nicht den Zugriff auf die Daten aus anderen Ländern. Es gibt keinen "DE-Cloud-Zugang" in anderen Ländern oder Kontinenten. Reisende oder ausländische Niederlassungen laufen natürlich immer ein Stück über das Internet.

Es gibt aber natürlich auch technische Aspekte, warum ein Client und Service möglichst nahe beieinander stehen sollen. Ich mache das gleich an zwei Beispielen deutlich. Geografisch verteilte Daten stellen natürlich erweiterte Anforderungen an Microsoft bezüglich der Konfiguration und Verwaltung. Aber auch Sie als Kunden sollten das Thema nicht unterschätzen, da es zum einen ihr Konzept der Verbindung zu Office 365  (Stichwort "dezentrale Breakouts") beeinflusst und natürlich das gesamte Thema Datenschutz (Safe Harbor, EU-US Privacy Shield, GDPdU, GDPR, BDSG). Auf diese rechtlichen Aspekte kann ich hier nicht eingehen. Dafür gibt es in ihrem Unternehmen die entsprechenden Organe wie Datenschutzbeauftragter, Juristen, Betriebsräte etc.

Die Frage des "Datenstandorts" dürfen Sie aber nicht nur aus der rein deutschen Brille sehen. Es gibt durchaus Länder, die auch per Gesetz die geografisch "lokale" Ablage von Daten erfordern. Sie können als deutsche Firma zwar ihren Tenant in Europa betreiben aber wenn ihre US-Niederlassung z.B. im Rahmen einer amerikanischen Steuerüberprüfung Daten bereitstellen muss, dann werden Sie vermutlich schwer dagegen wehren können nur weil die Daten in Europa liegen. Es könnte sogar soweit kommen, dass Sie die Postfächer der Mitarbeiter im jeweiligen Land vorhalten müssen. Auch das könnte ein Grund für eine verteilte Datenablage sein.

Multi-Geo ist eine "data-at-rest only solution", d.h. sie können bestimmen, wo die Daten liegen aber nicht, wo sie übertragen werden. Bei Exchange bedeutet dies, daß, z.B. per SMTP übertragene Mails nicht nur in der jeweiligen Region ankommen und versende werden. Auch der Zugriff auf das Postfach aus einer anderen Region bedeutet, dass die Übertragung und damit Einträge in Logfiles in anderen Regionen anfallen.

Introducing Multi-Geo capabilities in Office 365 and how to configure them
https://www.youtube.com/watch?v=3d9-Vt2fArk

Beispiel: Exchange Datenspeicher und Zugriff

Am Beispiel von Exchange und Outlook ist die Funktionsweise von Office 365 sehr einfach zu  beschreiben. Ihr Postfach liegt natürlich nicht "verteilt" auf vielen Servern sondern auf einem Server. Aus Verfügbarkeitsgründen repliziert Microsoft das Postfach natürlich noch auf andere Server in der gleichen Region. Für Firmen in Deutschland ist das dann meistens Irland und Niederlande (Amsterdam). Das Postfach ist aber immer "in Europe" und diese Einstellung war lange Zeit für den Tenant vorgegeben, d.h. alle Postfächer einer Firma waren immer in diesen beiden Tenants.

Nun greifen viele Mitarbeiter aber nicht nur aus Deutschland auf ihre Postfächer zu. Niederlassungen in allen Kontinenten oder auch einfach nur ein paar Handlungsreisenden arbeiten auch außerhalb von Europa. Microsoft hat diese Anforderung so gelöst, das der Namen "outlook.office365.com", mit dem sich alle Outlooks verbinden, abhängig vom Standort zu einem naheliegenden Übergang ins Microsoft Global Network geleitet werden. Der Client nutzt also nur einen kurze Weg über das Internet um dann möglichst schnell über die eigenen QoS-gesicherten Leitungen von Microsoft zum Postfach zu gelangen.

Trotz dieser optimierten Strategie gibt es natürlich zwei Aspekte:

  • Latenzzeit (speziell OWA)
    Wenn Sie an der Copacabana ihren Caipirinha schürfen und nebenbei per Browser ihre Mails lesen, dann sind 200-500ms Laufzeit schon nervig bei der Bedienung von Outlook per Browser. Das gibt natürlich genauso für jeden Mitarbeiter, der im klimatisieren oder stickigem Büro irgendwo auf der Welt arbeitet.
  • Datenvolumen (Migration und Betrieb)
    Aber auch Microsoft hat natürlich ein Interesse daran, dass Daten möglichst "nahe" beim Anwender sind und lange Übertragungen vermieden werden. Insbesondere bei großen Datenmengen, wie diese bei Migrationen oder z.B. Neuaufbau einer OST-Datei anfallen

Insofern ist es schon für beide Seiten, Kunde und Microsoft, interessant, die Daten von geografisch verteilten Firmen nicht nur in einer Region zu speichern.

Microsoft sieht aber speziell bei Exchange die Latenzzeit nicht als ausschlaggebend an. Ob sie nun Outlook über 50 oder 200ms Latenzzeit betreiben, fällt im Cached-Mode mit einer OST-Datei eh nicht auf und auch bei OWA sind noch viele andere Faktoren relevant. Es ist also primär die Speicherung des Ortes

Beispiel: Skype for Business/ Microsoft Teams

Noch spürbarer ist "Entfernung" bei Konferenzdiensten, wie diese von Skype for Business oder Microsoft Teams bereit gestellt werden. Bei Video und insbesondere bei Audio ist Entfernung und damit auch die Laufzeit ein Schlüsselfaktor bei der Qualität. Sobald eine Konferenz aus drei oder mehr Personen gestartet wird, wird eine "MCU" (MultiCastUnit) benötigt, zu der alle Clients ihre Töne und Bilder senden und die dann die Daten entsprechend mischt und wieder verteilt. Eine Konferenz ist also keine "n:m"-Verbindung aller Teilnehmer sondern viele 1:1 Verbindungen. Der Services wird normalerweise immer von dem Standort bereit gestellt, in dem der Konferenzleiter ist. Ungünstig ist es daher für die Anwender aber auch für Microsoft, wenn alle Mitarbeiter z.B. in Europa "gehostet" sind aber physikalisch z.B. in Asien sitzen. Selbst eine rein asiatische Konferenz geht dann immer über Europa.

Microsoft hat daher auch hier natürlich ein Interesse daran dass die Konferenzen möglichst dort abgehalten werden, wo die Anwender "in der Nähe" sind. Aktuell gibt es noch eine statische Zuordnung von "HomeServer" des Anwenders in einer Region zur Konferenz-MCU. Vielleicht ist es irgendwann ja möglich die MCU abhängig von den Standorten der Anwender flexible zu optimieren oder zu verketten, damit die WAN-Leitungen entspannt werden. Denkbar wäre auch eine Verschlüsselung mit einem Key pro Konferenz statt individueller SRTP-Schlüssel pro Verbindung. Dann könnten ebenfalls wiederholte Übertragungen wegoptimiert werden.

Beispiel: OneDrive/SharePoint

Auch dieser Datentops kann pro Benutzer und Site Collection in einer der Regionen verteilt werden. Anders als bei Exchange ändert sich dabei aber auch die URL, unter der diese Daten dann erreichbar sind. Der Anwender kann also sehr schnell sehen, dass die Daten in einer anderen Region liegen.

Die Daten des Benutzers kann der Administrator mit "Start-SPOUserAndContentMove" verschieben.

Multi-Geo Capabilities in OneDrive and SharePoint Online | BRK3236
https://www.youtube.com/watch?v=_l68KIEzzAg

Multi National Tenant einrichten

Sie sehen schon an den beiden Beispielen, dass es durchaus im Interesse von ihnen als Kunden aber auch von Microsoft sein kann, wenn nicht alle Postfächer aller Mitarbeiter in einer Region liegen. Aus dem Grund gibt es den "Multi Regional Tenant", bei dem ihre Tenant zwar in einer Region verortet ist aber die Daten durchaus geografisch günstiger für den Zugriff durch die Anwender bereitgestellt werden oder aufgrund legislativer Vorschriften regional abgelegt werden. Die Funktion wird nach und nach bei Tenants und je Produkt eingeführt.

Zuerst müssen Sie eine passende Lizenz kaufen und diese muss im Tenant erscheinen und dann kann es viele Tage dauern, bis Sie dann auch loslegen können:

Before you can start using Microsoft 365 Multi-Geo, Microsoft needs to configure your Tenant for Multi-Geo support. This one-time automatic configuration process is triggered after you order the Multi-Geo Capabilities in Microsoft 365 and the licenses show up in your Tenant. You'll receive workload-specific notifications in the Microsoft 365 message center once the Tenant has completed the configuration process for each workload, and then you may begin configuring and using your Microsoft 365 Multi-Geo capabilities. The time required to configure a Tenant for Multi-Geo support varies from Tenant to Tenant, but most Tenants finish within a month after receipt of the feature licenses. Larger or more complex Tenants may require more time to complete the configuration process.
Quelle: https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-multi-geo?view=o365-worldwide#getting-started

Sie müssen als Administrator pro Benutzer dann konfigurieren, in welcher Region die Daten dieses Benutzers liegen sollen. Die interessante Frage dabei ist ja immer noch, ob und wie Microsoft die Daten bei einem Umzug des Anwenders auch verlagert.

Die Einstellung für "Multi-National" ist pro Tenant durchzuführen. Technisch müssen Sie ihren Tenant über eine Azure-AD Powershell auf die Nutzung vorbereiten, die "erlaubten " Regionen angeben und dann pro Benutzer die "PreferredDataLocation" hinterlegen. Sie starten also eine Azure PowerShell und setzen den Tenant erst einmal auf MsolCompanyMultiNationalEnabled. Diese Einstellung ist "Pro Service" durchzuführen und ist nicht wieder umkehrbar.

Für Skype for Business würde dies dann wie folgt aussehen:

# Aktivierung des Tenant  (unumkehrbar !)
Set-MsolCompanyMultiNationalEnabled `
   -ServiceType MicrosoftCommunicationsOnline `
   -Enable $True

Im zweiten Schritt müssen Sie dann die erlaubten Regionen hinterlegen, in denen sich Anwender befinden dürfen. Leider akzeptiert das Commandlet kein Array sondern nur jeweils eine Region. Den Befehl müssen Sie daher ggfls. mehrfach mit den gewünschten Regionen ausführen:

#Benutzer in Asia Pacific erlauben
Set-MsolCompanyAllowedDataLocation `
   -ServiceType MicrosoftCommunicationsOnline `
   -Location APC
#Benutzer in Australien erlauben
Set-MsolCompanyAllowedDataLocation `
   -ServiceType MicrosoftCommunicationsOnline `
   -Location AUS
#Benutzer in Kanada erlauben
Set-MsolCompanyAllowedDataLocation `
   -ServiceType MicrosoftCommunicationsOnline `
   -Location CAN
#Benutzer in Europa erlauben
Set-MsolCompanyAllowedDataLocation `
   -ServiceType MicrosoftCommunicationsOnline `
   -Location EUR
#Benutzer in Japan erlauben
Set-MsolCompanyAllowedDataLocation `
   -ServiceType MicrosoftCommunicationsOnline `
   -Location JPN
#Benutzer in USA erlauben
Set-MsolCompanyAllowedDataLocation `
   -ServiceType MicrosoftCommunicationsOnline `
   -Location NAM

Es könnten später durchaus weitere Regionen dazu kommen. Allerdings sind die länderspezifischen Clouddienste (DE Cloud - die deutsche Microsoft Cloud, UK Cloud,  China mit 12Vianet) etc. weder hier anzugeben noch unterstützen diese überhaupt "Multi National" als Betriebsart.

Preferred Data Location (PDL)

Damit werden aber Benutzer noch nicht verschoben. Für die Anwender ist es erforderlich, dass Sie eine "Preferred Data Location" beim jedem Benutzer verwalten. Diese Einstellung ist pro Benutzer zu setzen und für einen "Cloud Only"-Anwender auch einfach zu setzen.

# Setzten der PDL von Hand
Set-MsolUser `
   -UserPrincipalName User1@msxfaq.de `
   -PreferredDataLocation JPN

# Generieren einer Liste der User mit der preferreddaatalocation
Get-MsolUser `
| ft UserPrincipalName,preferreddatalocation

Achtung:
Das Commandlet prüft nicht die Gültigkeit der übergebenen PreferredDataLocation. Sie können quasi jeden beliebigen String eintragen. Das Commandlet kommt (Stand Okt 2017) immer ohne Fehler zurück. Allerdings wird Microsoft die Daten des Benutzers nur dann in die gewünschte Location verschieben, wenn es eine Übereinstimmung zwischen der PreferredDataLocation und einer Location bei MsolCompanyAllowedDataLocation gibt.

Das gilt selbst dann, wenn das Konto mittels AD Connect aus einem lokalen AD repliziert wird.

Wenn Sie die Benutzer mittels AD Connect aus einem lokalen Active Directory replizieren, dann sollten Sie die "Preferred Data Location" auch über AD Connect einstellen. Leider gibt es aber kein passendes Feld im lokalen Active Directory und sie benötigen mindestens Azure AD Connect ab der Version 1.1.524.0 oder höher, um das Feld in Office 365 zu setzen.

Microsoft empfiehlt dazu eines der ExtensionAttribute (ms-Exch-Extension-Attribute1 bis ms-Exch-Extension-Attribute15 oder ms-exch-extension-custom-attribute-1 bis ms-exch-extension-custom-attribute-5, Siehe auch Exchange LDAP-Felder) zu nutzen, die durch die Schemaerweiterung für Exchange addiert werden.


Quelle: Ignite 2017: BRK3248 Exchange Online Multi-Geo Capabilities https://myignite.microsoft.com/sessions/55160  etwas angepasst

Sie sehen, dass das lokale AD-Feld im AzureAD landet aber im Exchange Forest dann ein anderes Feld genutzt wird.

Unabhängig davon müssen Sie natürlich immer noch selbst festlegen, welcher Prozess welche Inhalte in diese Felder schreibt, so dass ADConnect auch die richtigen Werte in den Office 365-Tenant überträgt.

Office 365 Produkte mit Multi National

Hier eine Liste von Links zu den einzelnen Produkten:

Im Okt 2017 waren viele Dienste noch "Preview" oder in meinem Tenant noch nicht freigeschaltet. Ich versuche die Hinweise und Links bei Gelegenheit zu aktualisieren. Ich bin für Tipps aber dankbar.

Produkt Servicename Links und Beschreibung

Exchange

Exchange

Normalerweise ist ein EXO Tenant auf eine Region beschränkt. Wenn Sie ihren Tenant aber auf "Multi Nation" setzen, dann können Sie pro Benutzer bestimmen, in welcher Region das Postfach real liegt. Der Zugriff der Clients erfolgt natürlich weiterhin über "outlook.office365.com" und wird dann zum richtigen Homeserver gelenkt.

Beachten Sie dies bei der Planung ihrer ausgehenden Internetverbindungen und insbesondere der Namensauflösung, damit Office 365 ihrem Client die "richtige" Eingangstür liefert.

Bestehende Mailboxen werden im Hintergrund verschoben, wenn der User


Quelle: Ignite Vortrag: Ignite 2017

Die verfügbaren Regionen finden Sie mit der Exchange Online Powershell (Office 365 - PowerShell). Die Werte sind erst gefüllt, wenn der Service auf dem Tenant auch auf "Multi Nation" gestellt wurde.

# Anzeige der Default region
Get-OrganizationConfig | fl DefaultMailbox

DefaultMailboxRegion               : NAM
DefaultMailboxRegionLastUpdateTime : 07/07/2017 10:21:21 AM

# Anzeige der verfügbaren Regionen
get-organizationconfig | select -expandproperty AllowedMailboxregions

AUS=ausprd01.prod.outlook.com
NAM=namprd03.prod.outlook.com
JPN=jpnprd01.prod.outlook.com
EUR=eurprd03.prod.outlook.com
APC=apcprd02.prod.outlook.com

Ignite 2017: BRK3248 Exchange Online Multi-Geo Capabilities
https://myignite.microsoft.com/sessions/55160

Skype for Business

MicrosoftCommunicationsOnline

Bei Skype for Business sind eigentlich nur "Meeting" richtig relevant. Präsenzinformationen und Buddy-Listen sind keine großen Datenmengen und vor allem nicht zeitkritisch. 1:1 Verbindungen erfolgen eh entweder direkt oder über Edge-Server und haben nur geringes Potential für eine Optimierung. Bei Meeting ist es aber schon interessant das Meeting dort zu platzieren, wo der Weg der meisten Teilnehmer am geringsten ist.

Microsoft Teams

?

Microsoft Teams wird auf Azure betrieben und ist in drei Partitionen geteilt. Daten liegen in der Region gemäß der Tenant Data Affinity. Die Dateien liegen in dem Land in dem der Tenant "berechnet" wird. Es ist geplant, die Regionen weiter aufzuteilen. Eine unterschiedliche Platzierung von Daten je Team oder Channel habe ich noch nicht gefunden.

Aber Teams nutzt natürlich Exchange, SharePoint, OneDrive um Daten abzulegen, so dass diese Datenspeicher vermutlich wieder geografisch platziert werden können.

Mark took the stage at this point to talk about where Teams actually lives in the world. At present Teams only exists in the three key regions: US, EMEA and APAC. While chat data is stored in region base on tenant affinity, files are stored in the country that the tenant is billed in (where a datacentre is available). There are currently efforts to bring chat to country-based datacentres as well.
Quelle: https://techcommunity.microsoft.com/t5/Microsoft-Teams-Ignite-Blog/Ignite-Live-Blog-Get-an-overview-of-Microsoft-Teams-architecture/ba-p/110626

Ignite 2017: Get an overview of Microsoft Teams architecture - BRK3071
https://www.youtube.com/watch?v=IUFhRBX3YoU


Quelle: BRK3071 Get an overview of Microsoft Teams architecture https://www.youtube.com/watch?v=IUFhRBX3YoU ca. 19:50

OneDrive

SharePoint ?

In OneDrive können Sie "Satelliten-Standorte" definieren, in denen Sie dann den Datenspeicher für Benutzer wieder über die Preferred Data Location (PDL) vorgeben können. Die Daten werden aber nicht automatisch verschoben. Das muss ein Administrator per PowerShell anschieben:

Start-SPOUserandContentMove `
   -UserPrincipalName User@msxfaq.net `
   -DestinationDataLocation EUR

MS Mechanics Introducing Multi-Geo capabilities in Office 365 and how to configure them
https://www.youtube.com/watch?v=3d9-Vt2fArk

SharePoint

SharePoint

Die Möglichkeiten von SharePoint sind vergleichbar zu OneDrive

Ignite 2017: BRK3263 Multi-Geo Capabilites in OneDrive and SharePoint Online
https://www.youtube.com/watch?v=_l68KIEzzAg

Office Groups

?

Ich vermute, dass die Daten eines Office Group, welche letztlich in SharePoint und Exchange liegen, über diese Einstellungen mit gesteuert werden können.

Azure

Entfällt

AzureVMs können Sie heute schon wahlfrei in den verschiedenen Datacentern einrichten und starten. Da jeder Dienst für sich autark ist, gibt es hier eigentlich keinen Bedarf für "multi National". Azure ist schon immer geografisch orientiert.

Microsoft CRM

?

Ich bin kein CRM-Fachmann und kann daher nur Links liefern:

Weitere Produkte werde ich bei Gelegenheit ergänzen. Ich bin für Tipps aber dankbar.

Tenants mit MultiGeo

Auf der Seite Wer nutzt Office 365 und wie? habe ich ein paar Wege beschrieben, wie ich mehr über einen Tenant ermitteln kann, da einige Abfragen prinzipiell nicht verheimlicht werden können. MultiGeo erkennt man recht einfach, wenn die Domainliste mehrere "onmicrosoft.com"-Domains enthält. Das muss nicht zwingend sein, denn mit der Funktion eines "Sharepoint rename" kann es auch weitere Domainnamen geben.

Folgende "weltweit" verteilte Firmen habe ich allein durch Probing gefunden. Anhand der Domainnamen lassen sich sogar die Regionen ermitteln, an denen es Data Locations gibt.

Firma MultiGeo Domains

Microsoft

Ja

 
microsoft.onmicrosoft.com
msfts2.onmicrosoft.com
MicrosoftEur.onmicrosoft.com
MicrosoftAPC.onmicrosoft.com
microsoftcan.onmicrosoft.com
microsoftprd.onmicrosoft.com

SAP

Ja

 
sap.onmicrosoft.com
SAPNAM.onmicrosoft.com

Shell

Nein

 
ShellCorp.onmicrosoft.com
ShellCorp.mail.onmicrosoft.com
SPORestore.onmicrosoft.com (?)

BMW

Ja

 
bmwgroup.onmicrosoft.com
bmwgroup.mail.onmicrosoft.com
bmwgroupAPC.onmicrosoft.com
bmwgroupKOR.onmicrosoft.com

Allianz

Ja

 
allianzms.onmicrosoft.com
allianzmsAPC.onmicrosoft.com
allianzmsAUS.onmicrosoft.com
allianzmsNAM.onmicrosoft.com
allianzmsche.onmicrosoft.com
allianzmscan.onmicrosoft.com
allianzmsIND.onmicrosoft.com

Siemens

Ja

 
siemens.mail.onmicrosoft.com
siemens.onmicrosoft.com
siemensAPC.onmicrosoft.com
siemensNAM.onmicrosoft.com

Ich habe auch andere geografisch vermutlich verteilte Firmen geprüft, die aber zumindest damals nur eine "OnMicrosoft.com"-Domain hatten, z.B. BASF.COM, VW.COM, Samsung.com, apple.com, nestle.com, toyota.com, wallmart.com

Einschätzung

Microsoft ist mit der Lösung für weltweit verteilte Firmen auf dem richtigen Weg. Auch wenn es keine minimale Anzahl an Benutzern gibt, so zielt Microsoft damit erst einmal auf Firmen 10.000 und mehr User. Das ist im Bereich Exchange z.B. darin begründet, dass für diese Kunden ein eigener geografisch verteilter Ressource Forest betrieben wird während alle anderen "nicht Multi Nation"-Tenants einfach in den lokalen Forest synchronisiert werden. Wir werden aber wohl nicht erleben, dass jeder Tenants in absehbarer Zeit auf "Multi National" umgestellt wird. Ich bin auch sicher, dass die Mehrzahl der Tenants gar nicht die "Multi National"-Funktion brauchen. Für wenige Anwender in einem anderen Land lohnt es sich auch kaum den Aufwand für "Multi National" zu betreiben.

Weitere Links