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

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" zwar ändern aber nicht die "Country or region". Die gleichen Daten erhalten Sie auch über die PowerShel

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

• Get-MsolCompanyInformation
  https://docs.microsoft.com/en-us/powershell/module/msonline/get-msolcompanyinformation?view=azureadps-1.0

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.

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
• 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.

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. 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.

AADConnct/DirSync

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.

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

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

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

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

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 cih 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
• 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/