Office 365 Region und UsageLocation

Office 365 wird weltweit angeboten aber nicht alle Funktion sind überall verfügbar. Einige der Funktionen hängen direkt am Tenant, also wo die Instanz betrieben wird. Andere Einstellungen hängen an einer Einstellung die pro Benutzer gesetzt werden kann. Hier gibt es eine ganze Menge von Feldern, die einer Aufklärung bedürfen.

Beachten Sie dazu auch die Seite Office 365 Sprachen und Multi Geo Tenant und Office 365 Tenant Region ändern

Die Region des Tenant

Ehe ich auf die Regionen einzelner Dienste und der Zuordnung von Benutzern eingehe, sollten Sie wissen, dass Sie bei der Beantragung ihres Tenant ein Land festlegen, welches nicht mehr geändert werden kann.

Es ist für eine Firma absolut entscheidend, welche Auswahl sie hier treffen. Sie bestimmt z.B.: über die primäre DataLocation. Die Einstellung können Sie auch nachträglich im Webportal anzeigen lassen, wenn Sie auf https://portal.office.com/AdminPortal/Home#/companyprofile auf den Button "Edit" gehen:

Sie können die "Preferred Language" ändern aber nicht die "Country or Region". Die gleichen Daten erhalten Sie auch über die PowerShell.

PS C:\> (Get-MsolCompanyInformation) | fl PreferredLanguage,country,countryletterCode,DefaultUsageLocation

PreferredLanguage : de
Country           :
CountryLetterCode : DE
DefaultUsageLocation :

Das sind die Standardeinstellungen eines meiner Tenants. Sie sehen, dass hier vier Properties etwas mit der Region zu tun haben könnten.

Allerdings gibt es kein Gegenstück in der Form "Set-MsolCompanyInformation" um die Werte anzupassen. Der "Country Letter Code" ist nach meinem Kenntnisstand unverrückbar.

Region und Datacenter

Microsoft gliedert die geografischen Kontinente in unterschiedliche Regionen. So gibt es NA, SA, EU, AP und vermutlich noch weitere Regionen. Eine Region enthält aber immer mindestens zwei Datacenter. Für Europa werden es sogar immer mehr und seit Ende 2019 gibt es sogar zwei Datacenter in Deutschland (Siehe Office 365 aus Deutschland), die aber zur Region EU dazu gehören. Wer in 2020 einen neuen Tenant anlegt, der wird sogar sofort in diesen deutschen Systemen gehostet.

Alle Bestandskunden in Deutschland, die früher in den Niederlanden und Irland lagen, sollen im Laufe von 2020 alle nach Deutschland verlagert werden. Verwechseln sie diese Location nicht mit der DE Cloud.

Über die Microsoft Office 365 PowerShell erhalten Sie noch viel mehr Informationen. Hier ein Auszug eines größeren produktiven Tenants, der schon länger in Europa angemeldet wurde und in Deutschland ist. Im Feb 2020 waren die Dienste noch nicht nach DE verlagert.

PS C:\>Connect-MsolService
PS C:\>(Get-MsolCompanyInformation).AuthorizedServiceInstances
MicrosoftFormsProTest/NA001
MicrosoftKaizala/NA001
Bing/NA001
DYN365AISERVICEINSIGHTS/NA001
WhiteboardServices/NA001
WindowsDefenderATP/NA001
Windows/SDF
UniversalStoreService/NA001
ProjectProgramsAndPortfolios/NA001
HCMOnboarding/NA001
HCMCollaborativeHiring/NA001
ERP/ERP_Default1
DynamicsHCMWorkload/NA001
AzureAdvancedThreatAnalytics/NA001
AadAllTenantsNotifications/EUGB06
BDM/NA026
To-Do/NA001
SharePoint/SPOS1181
Netbreeze/PROD1-4
CRM/EMEA01
OfficeForms/NA001
MicrosoftStream/NA001
TeamspaceAPI/NA001
ProcessSimple/NA001
PowerAppsService/NA001
Deskless/NA001
AccessControlServiceKey/SharedKeys
Adallom/EU001
KratosAppsService/NA001
ProjectWorkManagement/PROD_EU_Org_Ring_150
PowerBI/EU001
Sway/NA001
MultiFactorService/NA001
AADPremiumService/NA001
WindowsAzure/EMEA001
AzureAnalysis/SDF
GroupBasedLicensePropagation/NA001
DirectoryToCosmos/EU001
ExchangeOnlineProtection/emea03-04
DirectoryToCosmos/D2C001
YammerEnterprise/NA001
SCO/PROD_MSUB02
RMSOnline/EU
Metro/NA001
AccessControlServiceS2S/EU3
AccessControlServiceS2S/EU2
AccessControlServiceS2S/EU
exchange/eurprd04-1
MicrosoftOffice/NorthAmerica
MicrosoftCommunicationsOnline/Instance03

Auf der Seite Office 365 aus Deutschland habe ich ein Beispiel eines im Februar 2020 angelegten Office 365 Tenants beschrieben.

UsageLocation und DefaultUsageLocation

Es gibt aber andere Commandlets, die zumindest einen Teil der Felder ändern können. Besonders ist hier das Feld "DefaultUsageLocation" interessant, welches per Default erst einmal "$null" ist. Pro Benutzer gibt es das Feld "UsageLocation", welches den Standort des Benutzers vorgibt und Auswirkungen auf die für diese Region verfügbaren Dienste hat. Mir sind bislang folgende zwei Stellen aufgefallen

  • Lizenz-Zuweisung
  • Exchange Einstellungen

Usage location
Some Microsoft services are not available in all locations. Before a license can be assigned to a User, the administrator has to specify the Usage location property on the User. In the Azure portal ( https://portal.azure.com/), you can specify in User > Profile > Settings.
For group license assignment, any Users without a usage location specified will inherit the location of the directory. If you have Users in multiple locations, make sure to reflect that correctly in your User objects before adding Users to groups with licenses.

Group license assignment will never modify an existing usage location value on a User. We recommend that you always set usage location as part of your User creation flow in Azure AD (e.g. via AAD Connect configuration) - that will ensure the result of license assignment is always correct, and Users do not receive services in locations that are not allowed.

Scenarios, limitations, and known issues using groups to manage licensing in Azure Active Directory
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-licensing-group-advanced

Sie müssen daher bei jedem Benutzer eine "Usage Location" zuweisen, ehe Sie ihm eine Lizenz zuweisen können

Sie können diese Thematik auch global lösen, indem Sie das Feld "DefaultUsageLocation" auf dem Tenant setzen. Das geht recht einfach, indem Sie folgenden Befehl mit dem "ISO 3166 Alpha2 Code" ausführen. Für Deutschland ist das:

Set-MsolCompanySettings 
   -DefaultUsageLocation DE

Sie sollten diese Einstellung natürlich nur tun, wenn Sie wirklich alle Benutzer in diese Location einordnen wollen und abweichende Anwender dann eine individuelle UsageLocation zuweisen. Das ist kein Problem für Firmen, die nur in einem Land aktiv sind. Geografisch verteilte Unternehmen werden vermutlich den Default leer lassen und so eine unvollständige Konfiguration der Benutzer spätestens bei der Zuweisung von Lizenzen erkennen. Sie können mit einem Setup diese Feld bei jedem Benutzer auch durch AADConnect füllen lassen. Dazu gleich mehr

Regionen in Office 365

Zuerst habe ich mal per Webbrowser nach Stellen gesucht, an denen Land, Region oder Sprache auftauchen.

Office 365 Web PowerShell Property Inhalt

Office 365 Admin Portal beim Benutzer

Azure PowerShell: Country

Beliebiger Freitext

Office 365 Admin Portal beim Benutzer

Azure PowerShell:
UsageLocation

DropDown. Im Feld steht der 2-stellige ISO Ländercode

Exchange Web App Optionen - Allgemein - Mein Konto

Azure PowerShell:
Get-MSOLUser: UsageLocation

Exchange PowerShell:
Get-Mailbox:
UsageLocation

Ausgeschriebene Version des Landes. Mit Set-MSOLUser - UsageLocation <> muss der 2-Letter ISO-Code angegeben werden.

Nicht über die Exchange Webseite änderbar.

Exchange Web App Optionen - Allgemein - Regionen

Get-MailboxRegionalsettings: Language

Und der erste Eintrag im Array

Get-mailbox:Languages

Get-MailboxRegionalsettings: Language

Und der erste Eintrag im Array

Get-mailbox:Languages

Auch wenn hier in der GUI an verschiedenen Stellen sogar die Möglichkeit einer Veränderung angezeigt wird, so sind die meisten Felder nicht über die Webseite zu ändern. Insbesondere, wenn die Daten über einen DirSync aus einem On-Prem AD gepflegt werden.

Felder mit PowerShell

Da Office 365 bzw. Azure-AD keinen LDAP-Zugriff erlaubt, können die Felder nur per Remote PowerShell ausgelesen werden. Einige der Daten sind auch per Webportal einsehbar und teilweise änderbar.

MSOLUser

Bei MSOLUser sind zwei Felder interessant: Das Feld "Country" ist einfach nur ein Land und kann jeden String enthalten. Es erscheint im Adressbuch aber scheint sonst keine Systemeinstellungen zu steuern. Anders ist dies bei "UsageLocation".

Get-MsolUser -UserPrincipalName <upn>  |fl

Country                     : DE
Department                  :
Office                      :
PreferredLanguage           : de-DE
State                       : NRW
UsageLocation               : DE

Das Feld UsageLocation kann über Set-MSOLUser gesetzt werden, selbst wenn das Konto ein "DirSync" User ist.

Set-MSOLUser `
   -userPrincipalName <upn> `
   UsageLocation DE

Das Feld "Country" hingegen kann nur für Cloud-User geändert werden. Ein Versuch das Feld Country für einen DirSync-User zu ändern, wird mit einem Fehler quittiert, obwohl der Parameter "Country" beim Commandlet "Set-MSOLUser" vorhanden ist:

Hier ist dann die Eintragung im lokale AD vorzunehmen.

Get-Mailbox

Über die Exchange Remote PowerShell werden ebenfalls Felder angezeigt: Hier ist es aber erst einmal das Feld "Languages", welches ein oder mehrere Sprachen enthält und wieder die UsageLocation.

Get-Mailbox <upn>

Languages : {de-LI, de-DE}
UsageLocation : Deutschland

Die UsageLocation ist nicht per Set-Mailbox änderbar. Das Feld "Languages" aber wohl, selbst wenn der Benutzer ein DirSync-Anwender ist.

Zuletzt gibt es natürlich noch die Sprache der Mailbox selbst. Diese Information steht schon beim On-Prem-Exchange nicht im Active Directory, sondern in der Mailbox und ich gehe davon aus, dass es in Office 365 weiterhin so ist. Dieser Wert lässt sich nämlich weder mit Get-MSOLUser, Get-Mailbox, Get-Recipient o.ä. auslesen, sondern nur per Get-MailboxRegionalConfiguration.

Get-MailboxRegionalConfiguration <upn> |fl

Language : de-DE
DefaultFolderNameMatchingUserLanguage : True
TimeFormat : HH:mm
TimeZone : W. Europe Standard Time

Damit ist dieses Feld auch nicht beim DirSync zu beachten.

ADSync und Länderdaten

Sobald Sie die Identitäten in der Cloud nicht mehr manuell pflegen, sondern mittels AADConnect von einem lokalen Active Directory pflegen lassen, werden die meisten Felder nicht mehr per PowerShell oder Webseite zu editieren sein. Ein "synchronisiertes Objekt" wird durch Felder in ihrem On-Premises Active Directory verwaltet und Einstellungen in der Cloud folgen den lokalen Einstellungen. Damit ist es natürlich wieder interessant, welche Felder aus dem Active Directory auf die entsprechenden Felder in der Cloud fallen. Dazu gibt es gleich mehrere Transformationrules, die Daten eingehend verarbeiten.

  • Inbound from AD - User Common
  • Inbound from AD - User Exchange

    Sieh sehen aber hier, dass die UsageLocation erst synchronisiert wird, wenn das Objekt auch im lokalen AD für "Exchange Enabled" ist. AzureADConnect macht dies am feld "mailnickname" fest, welches im "Scoping Filter" (nicht abgebildet) hinterlegt ist.

Hier mal eine Übersicht welche Felder hinsichtlich Land, Region, Sprache repliziert werden.

AD-Feld Rule Office 365 Bemerkung

c

IN from AD - User Common

c

ISO-Codes des Landes

co

IN from AD - User Common

co

Ein einfaches Freitext-Feld für die Beschreibung des Landes. Es gibt keine Validierung des Inhalts. Insofern ist nicht mal vorgeschrieben, ob da nun "Deutschland", "Germany", "Allemagne" oder vielleicht sogar "Federal Republic of Germany" drin stehen sollte. Allerdings "sehen" Anwender das Feld in Adressbüchern.

countryCode

IN from AD - User Common

countryCode

Land/Region mit dem ISO 3166 Numeric Code., Deutschland hat die 276

PreferredLanguage

IN from AD - User Common

PreferredLanguage

Bei einem CloudOnly-User können Sie das Feld noch setzen. Sobald es ein synchronisierter Benutzer ist, geht es nicht mehr:

Das Feld muss daher im lokalen AD gesetzt werden, z.B. mit 

Set-ADUser adUser1 -Replace @{‘preferredLanguage’="DE-DE"}

msExchUsageLocation

Inbound from AD - User Exchange

UsageLocation

Obwohl dies On-Prem eigentlich ein Exchange Feld ist, wird es von Office 365 nicht nur für die Anzeige in Exchange sondern auch zur Steuerung der Lizenz-Optionen genutzt. Auch hier überstimmt AADAConnect das Feld in der Cloud. Sie sollten daher On-Premises dafür sorgen, dass hier in "msExchUsageLocation" das zweistellige ISO-Kürzel des Landes steht. Der Wert steht übrigens auch im Feld "c"

Get-ADUser -Filter 'msExchUsageLocation -like "*"'

Set-ADUser adUser1 -Replace @{‘msExchUsageLocation’="DE"}

Entfällt

 

Language

Die Einstellung der Mailbox-Sprache wird nicht im AzureAD sondern im Postfach gespeichert und damit nicht für AADConnect relevant.

Wie sie gut sehen können, werden alle Felder mit Ausnahme von "msExchUsageLocation/UsageLocation" schon beim ganz normalen Benutzer synchronisiert. Erst wenn Sie auch das Exchange Schema im lokalen Active Directory installiert haben und AADConnect die Regeln für den Exchange-Hybrid-Mode aktiviert hat, wird auch dieses Feld mit repliziert.

Diese Angaben basierend auf meinen Beobachtungen und Tests, aber sind nicht von Microsoft bestätigt worden und könnten sich auch wieder geändert haben.

UsageLocation immer replizieren

Sie haben im vorherigen Kapitel schon gesehen, dass das Feld "UsageLocation" im Metaverse und später auch im AzureAD anhand des Felds "msExchUsageLocation" nur dann repliziert wird, wenn sie auch Exchange-Felder replizieren und das Quellobjekt für Exchange aktiv ist. Das ist natürlich ungeschickt, wenn Sie Benutzer replizieren und mit einer Lizenzen versehen wollen, die aber nicht für Exchange relevant sind. Sicher ist der Fall eher selten, denn ein Postfach braucht doch jeder. Aber es gibt doch Fälle, bei denen Anwender eben nur andere Dienste von Office 365 nutzen sollen. Über eine kleine Änderung in den Synchronization Rules können Sie es erreichen, dass das Feld auch bei "normalen" Anwendern abgeglichen wird.

Zuerst habe ich mal geprüft, Wann das Feld ins AzureAD geschrieben wird. In der Regel "Out to AAD - User Join" habe ich in den Transformations den Eintrag gefunden. Das Feld wird also auf jeden Benutzer geschrieben, wenn es denn im MetaVerse landet.

Ich muss also nur in einer "In from AD"-Regel für Benutzer die Zuordnung addieren. Eingehend gibt es eine ganze Menge von Regeln aber über einen entsprechenden Filter bleiben wenige übrig. Dieser AADConnect hat z.B. gar keine Exchange Regeln aktiviert:

Dennoch möchte ich auch hier das Feld "msExchUsageLocation aus dem AD in das MetaVerse übertragen. Ich erweitere daher die Regel "In from AD - User Common". Wenn ich eine Regel erweitere, dann fragt mit der Editor wieder, ob ich die bestehende Regel kopieren und die alte dafür deaktivieren will. Damit man Änderungen leichter nachverfolgen kann und spätere Updates meine Änderung nicht überschreiben, nutzt ich das Angebot und hängt die Kopie diesmal aber in der Preference hinten dran, damit sie nach dem "In from AD - User Join" bleibt. In der neuen Regel addiere ich mit "Add transformation" eine neue Zeile in der ich dann "usageLocation" als Target Attribute im Metaverse und als Source das Feld "msExchUsageLocation" aus dem lokalen AD nutze.

Das Feld "msExchUsageLocation" ist im lokalen AD aber natürlich nur vorhanden, wenn das Exchange Schema installiert wurde. Sie müssen aber keinen Exchange Server installiert haben. Sie können natürlich auch jedes andere Feld als Quelle verwenden, in welches Sie die Daten in dem "richtigen Format "vorliegen haben. Interessant fände ich z.B. das Feld "c" (Country), welches auch den 2-stelligen ISO-Code enthält. Aber vielleicht haben Sie doch den Sonderfall, dass jemand hinsichtlich der Lizenzen ein anderes Land braucht, als bei ihm in der Postadresse hinterlegt ist. Daher würde ich auch hier nahe am "Standard" bleiben.

Weitere Links