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.
- Office 365 Sprachen
- Multi Geo Tenant
- Get-MsolCompanyInformation
https://docs.microsoft.com/en-us/powershell/module/msonline/get-msolcompanyinformation?view=azureadps-1.0 - Office 365 – You can not change the
country accociated with your tenant
https://www.hametbenoit.info/2013/04/27/office-365-you-can-not-change-the-country-associated-with-your-tenant/ - Allow tenant to change region
https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/9217677-allow-tenant-to-change-region
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.
- Office 365 aus Deutschland
- Explore where Office 365 stores your
customer data
https://aka.ms/wheresmydata
https://products.office.com/en-us/where-is-your-data-located
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
- Set-MsolCompanySettings
https://docs.microsoft.com/en-us/powershell/module/msonline/set-msolcompanysettings?view=azureadps-1.0 - Where is your data located?
https://products.office.com/en-us/where-is-your-data-located?geo=Europe#Europe - ISO 3166-1
https://en.wikipedia.org/wiki/ISO_3166-1
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
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: |
DropDown. Im Feld steht der 2-stellige ISO Ländercode |
Exchange Web
App Optionen -
Allgemein - Mein
Konto
|
Azure
PowerShell: Exchange
PowerShell: |
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.
- Azure AD
Connect-Synchronisierung: Mit
Azure Active Directory
synchronisierte Attribute
https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized - Where does Microsoft Azure
Active Directory (Azure AD)
store identity data for European
customers
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-data-storage-eu
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
- ADSync mit Exchange Online
- Office 365 Sprachen
- Multi Geo Tenant
- Set-MSOLUser
https://msdn.microsoft.com/de-de/library/azure/Dn194136.aspx - Use AADConnect to Populate
Office 365 Usage Location
https://blogs.technet.microsoft.com/undocumentedfeatures/2016/07/22/use-aadconnect-to-populate-office-365-usage-location/
Addiert eine neue Transformation-Rule, um immer "US" einzuschreiben. Das geht sicher besser - Office 365 – Assign
Licensing “User Location” via
Active Directory
http://blogs.perficient.com/microsoft/2014/11/office-365-assign-licensing-User-location-via-active-directory/ - Where does Microsoft Azure
Active Directory (Azure AD)
store identity data for European
customers
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-data-storage-eu - ISO 3166-1
https://en.wikipedia.org/wiki/ISO_3166-1
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 - Office 365 – You can not
change the country accociated
with your tenant
https://www.hametbenoit.info/2013/04/27/office-365-you-can-not-change-the-country-associated-with-your-tenant/ - Where is my Office 365
tenant located?
http://danpatrascu.com/office-365-tenant-located/