UsageLocation

Diese Seite beschreibt die Bedeutung und Zusammenhänge der Einstellung "UsageLocation" mit Lizenzierung, Exchange, Teams Audiokonferenzen und ADSync.

Ein Teil der Seite war auf Office 365 Region und ist hier eingeflossen.

Die Usage-Lication hat Einfluss auf den Default Teams Dialplan

Die Usagelocation ist nicht mit der PreferredDataLocation auf dem Bereich Multi Geo Tenant zu verwechseln

Kurzfassung

Für die Vergabe von Lizenzen in Microsoft 365 ist die Pflege der "UsageLocation" in Microsoft 365 bei jedem Benutzer Pflicht. Zudem wird die Information auch beim Default Teams Dialplan verwendet. Sie sollten hier also das Land eintragen, in dem der Anwender gewöhnlich arbeitet. Dazu gibt es mehrere Optionen:

  • Manuelle Pflege
    Sie können direkt über https://admin.microsoft.com bei der Lizenzzuweisung die Usagelocation einstellen.
  • Tenant Default
    Wenn die überwiegende Anzahl der Benutzer im gleichen Land sind, können Sie die im Tenant als Default hinterlegen. Individuelle Abweichungen pro Benutzer sind weiter möglich
  • ADSync und msExchUsageLocation
    Seit ca. 2019 hat ADSync eine Regel, dass der Inhalt des lokalen Exchange Feldes msExchUsageLocation in die Cloud repliziert wird. Das Feld msExchUsageLocation wird On-Premises bislang nicht genutzt. Sie müssen aber überlegen, wie Sie das Feld lokal pflegen
  • ADSync und "c"
    Im lokalen AD gibt es schon das Feld "c" für Country, welches die ISO-Codes enthält und per AD User&Computers direkt gepflegt werden kann. Allerdings müssen Sie manuell eine Sync-Regel dazu anlegen, was aber Microsoft selbst dokumentiert hat
  • ADSync und Konstante
    Sie könne natürlich auch eine Sync-Regel anlegen, die z.B. einen festen Wert in das AzureAD schreibt

Das Feld "UsageLocation" ist durch einen Schreibzugriff von ADSync aber nicht gegen direkte Änderungen in der Cloud per Skript oder Adminportal gesperrt. Das lokale AD gewinnt aber wieder.

Bitte fragen Sie mich nicht, warum die Replikation durch ADSync nicht das Feld "c" nutzt sondern ein Feld, welches erst nach der Exchange Schema-Erweiterung im AD vorhanden ist und bislang von Exchange nicht genutzt wird.

Wenn alle Mitarbeiter die gleiche UsageLocation erhalten sollen, dann ist die Konfiguration einer "DefaultUsageLocation" für den Tenant die einfachste Möglichkeit, damit die von der UsageLocation abhängigen Lizenzen und Dienste Teams Audiokonferenz korrekt funktionieren. Wer unterschiedliche UsageLocations nicht direkt in der Cloud sondern über ADSync pflegen und manuelle ADSync regeln vermeiden will, muss das AD-Feld msExchUsageLocation setzen, welches durch das Exchange Schema addiert wird und anscheinend noch nie von Exchange genutzt wurde. Ich habe zumindest noch keinen Kunden gefunden, in dem das Feld gesetzt ist.

Bedeutung

Alle Benutzer in Microsoft 365 werden zu einem Land zugeordnet. Diese Information ist nicht nur für die korrekte Lizenzvergabe sondern z.B. auch die automatische Vergabe der Einwahlrufnummern für Teams Audiokonferenzen genutzt. Microsoft schreibt dazu:

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

Wir müssen uns also Gedanken machen, wie diese Einstellung sinnvoll zu verwalten ist.

UsageLocation pro Benutzer

Die meisten kleineren Tenants werden den ersten Kontakte mit der Einstellung bei der Vergabe von Lizenzen machen. Ohne die Definition der UsageLocation beim Benutzer können Sie keine Lizenz über das Admin-Portal zuweisen.

Sobald sie diese Einstellung vorgenommen haben, können Sie nicht nur die gewünschte Lizenz zuweisen sondern auch Exchange Online und Microsoft Teams nutzen diese Informationen für weitere Einstellungen. Microsoft Teams werte das Land z.B. dahingehend aus, dass die Einwahlrufnummern in Audiokonferenzen damit bestimmt werden.

Natürlich können Sie die UsageLocation eines Benutzers auch per PowerShell setzen. Warten Sie damit aber noch etwas, denn größere Firmen können den Wert auch per ADSync setzen. Wenn Sie eh nur ein einem Land aktiv sind, dann können Sie eine DefaultUsageLocation auf dem Tenant setzen

Install-Module MSOnline
Import-Module MSOnline -UseWindowsPowerShell
Connect-MSOnlineService

# Auf Deutschland setzen
Set-MsolUser -UserPrincipalName user@msxfaq.com -UsageLocation DE

# UsageLocation wieder leeren. INteressanterweise geht ein "$null" hier nicht
Set-MsolUser -UserPrincipalName user@msxfaq.com -UsageLocation ""

# Countrcode muss aus der ISO-Liste stammen
set-MsolUser -UserPrincipalName user@msxfaq.com -UsageLocation NN
Set-MsolUser: Invalid value for parameter. Parameter Name: UsageLocation.

Default Usage Location (Tenant)

Wenn Sie nur in genau einem Land unterwegs sind, können Sie sich viele Anpassungen aber sparen, wenn Sie eine Standarteinstellung vornehmen. Die Einstellung kann auch pro Tenant festgelegt werden. Allerdings macht die Microsoft nicht per Default, sondern das Feld ist erst einmal leer.

Install-Module MSOnline
Import-Module MSOnline -UseWindowsPowerShell 
Connect-MSOnlineService
(Get-MsolCompanyInformation) | fl country,countrylettercode,PreferredLanguage,Replicationscope,default*


Country              :
CountryLetterCode    : DE
PreferredLanguage    : en
ReplicationScope     : EU
DefaultUsageLocation :

Sie können diese Thematik 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 wäre das.

Set-MsolCompanySettings 
   -DefaultUsageLocation DE

Sie sollten diese Einstellung natürlich nur tun, wenn Sie wirklich per Default alle Benutzer ohne individuelle UsageLocation in diese Location einordnen wollen. Denken Sie spätestens mit dem ersten Mitarbeiter in einem anderen Land daran, dass die dort dann die UsageLocation separat setzen.

Ich nutzt die DefaultUserLocation wirklich nur für kleine Firmen, die nur in einem Land aktiv sind.

Die Herausforderung besteht darin, dass Sie Lizenzen z.B. auch über Gruppenmitgliedschaften vergeben können (Office 365 Lizenzen mit Azure Groups) und hier keine Rückfrage zu UsageLocation kommt.

UsageLocation mit ADSync und Exchange

Diese Funktion ist seit ca. 2019 in ADSync hinterlegt. Davor mussten sie noch eigene Regeln erstellen.

Firmen, die aber heute schon mit ADSync ihre Identitäten in der Cloud anhand lokaler AD-Benutzer und Gruppen verwalten, können die UsageLocation aus dem lokalen Active Directory ableiten. Ein Blick in die ADSync Rules zeigt schnell, dass ADSync hier das Feld msExchUsageLocation ausliest und in die Cloud überträgt.

Das funktioniert natürlich nur unter folgenden Voraussetzungen:

  • Exchange Schema Erweiterung
    Das lokale Active Directory muss natürlich das Feld "msExchUsageLocation" kennen
  • ADSync Installation mit Exchange Regeln
    Bei der Installation von ADSync wird geprüft, ob Exchange installiert ist und nur dann werden die Regeln auch angelegt. Wenn Sie fehlen, sollten Sie die ADSync-Konfiguration starten und das Schema aktualisieren.
  • Inhalt von "msExchUsageLocation"
    Normalerweise ist das Feld nicht gefüllt. Sie müssen sich also überlegen, wie Sie dieses Feld in ihrem Provisioning mit füllen.

Eine einfache Möglichkeit ist natürlich die initiale Aktualisierung anhand des Feld "c" über folgende PowerShell-Zeilen. Sie holen erst alle AD-Objekte, bei denen das Feld "c" gefüllt ist aber "msExchUsagelocation" leer ist um dann den Inhalt zu kopieren.

Get-ADUser `
   -LDAPFilter "(&(!(msExchUsageLocation=*)(c=*)(samaccountname=fcarius)))" `
   -properties c `
|foreach-object { `
   Write-Host " Set msexchUsageLocation  $($_.c) on $($_.distinguishedname)" 
   Set-ADUser `
     -Identity $_.distinguishedname `
     -replace @{'msExchUsagelocation'=$_.c}
}

Danach sollten Sie beim nächsten ADSync-Lauf sehen, dass diese Änderung aus dem AD in das Metaverseimportiert und dann in die Cloud exportiert wird.

Und im nächsten Schritt landen die Daten im AzureAD:

Die Regeln von ADSync sind damit schon vorbereitet, um die UsageLocation in der Cloud basierend auf einem lokalen AD-Feld zu setzen.

Allerdings frage ich mich schon, warum Microsoft die kaum genutzte Exchange Einstellung "msExchUsageLocation" als Quelle für die UsageLocation in der Cloud heranzieht und nicht das "c"-Feld nutzt.

Änderung der UsageLocation

Natürlich wollte ich wissen, wie sich das Feld in der Cloud verhält, wenn ich es manuell überschreibe. Technisch können Sie dies einmal per MSOL-PowerShell machen oder über das Microsoft 365 Admin Portal (https://admin.microsoft.com) " beim Benutzer in den Lizenzen die Location geändert.

Die Änderung war problemlos möglich und wurde nicht verhindert oder gewarnt, dass dieses Feld durch ADSync verwaltet wird.

Allerdinge sehen sie beim nächsten Delta-Sync, dass ADSync beim "Delta Import" aus dem AzureAD die Änderung ins Metaverse überträgt aber die lokale Vorgabe gewinnt. Beim nächsten Export zum Office 365 Tenant wird die Einstellung wieder zurück gedreht. ADSync sorgt also dafür, dass die lokale Vorgabe auf jeden Fall eingehalten wird.

Als Gegenprobe wollte ich dann das Feld "country" im AzureAD ändern. 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 hat Microsoft 365 anscheinend unterschiedliche Schutzmechanismen für die Felder vorgesehen. Es macht durchaus Sinn, das Feld "UsageLocation" hier nicht zu sperren, denn welcher Administrator wird in einer mittels ADSync abgeglichenen Umgebung sofort die Ursache erkennen, wenn er doch nur eine Lizenz zuweisen möchte

Leeren von msExchUsageLocation

Ein weiterer Test besteht darin, das lokale AD-Feld zu leeren. Das kann ja durchaus mal passieren. Bei der Kontrolle per ADSync habe ich dann gesehen, dass beim "Delta Import" und "Delta Sync" aus dem lokalen ADA die Löschung erkannt und ins Metaverse repliziert wurde. Allerdings wurde die Löschung nicht ins AzureAD übertragen. Ein Blick auf die Export-Rules zeigt auch den Grund dafür:

In der ausgehenden Regel zur Replikation des Feldes "usageLocation" steht folgende Formel:

IIF(IsNullOrEmpty([usageLocation]),IgnoreThisFlow,[usageLocation])

Wenn das Feild im Metaverse "leer" ist, dann wird es nicht exportiert. Damit ist ein Löschen im lokalen AD unkritisch.

UsageLocation mit ADSync ohne Exchange

Die manuelle Konfiguration war bis ca. 2019 notwendig. Spätere Versionen von ADSync nutzen msExchUsageLocation als Quelle.

Damit bleibt nun noch die Frage, was die Firmen ohne Exchange machen. Sie könnten ja ein anderes Feld wie z.B. "c" als Quelle nutzen und eine eigene Regel dafür anlegen. Diese ist erlaubt und supported, wenn Sie sich an die Vorgehensweise halten.

Microsoft zeigt in einem Sample, wie sie eine Regel mit einer statischen Vorgaben "US" als auch mit dem Feld "c" als Quelle aufbauen. Das können Sie natürlich auch selbst umsetzen und beschreibe ich gleich.

Wenn Sie heute (2022) ADSync mit Exchange Online einsetzen und keinen lokalen Exchange Server haben, müssen Sie dennoch die Exchange Properties alle im lokalen AD pflegen (Siehe auch Exchange Management Rolle, ADSync mit Ex Online Only, Hybrid Connector Server u.a.

Daher würde ich keine eigenen Regeln anlegen sondern mit eher überlegen, wie Sie das Exchange Schema in ihr lokales AD bekommen und die erforderlichen Felder befüllt werden. Wenn sie davon abweichend doch ihre eigenen Regeln anlegen wollen, dann sollten Sie wie folgt vorgehen.

Schritt erledigt

ADSync pausieren

Wie jede Anpassung an den Regeln ist es ratsam zu verhindern, dass ADSync gerade "aktiv" wird während wir an der Konfiguration schrauben. Daher halten wir den eingebauten Scheduler an.

Set-ADSyncScheduler -SyncCycleEnabled $false

Die AzureAD Connect Konsole macht dies auch aber der Rule-Editor, den wir nun brauchen macht dies nicht.

ADSync Inbound Rule anlegen

Wenn Sie den "Synchronization Rule Editor" noch nicht genutzt haben, finden Sie ihn im Startmenü:

Direkt ohne Willkommensschirm werden alle vorhanden Regeln angezeigt aber der erste Filter steht schon auf "Inbound", d.h. Regel mit denen ADSync Daten aus anderen Verzeichnissen in sein Metadirectory einliest.

Hier brauchen wir nun eine neue Regeln um das Feld "c" erst mal in das Metaverse zu übertragen. Sie drücken als rechts auf "Add new Rule" und füllen das erste Fenster des Assistenten aus.

Die Felder bedeuten:

  • Name: Eine Beschreibung der Regel
  • Description: Noch mehr Platz für Dokumentation
  • Connected System: Die Quelle ist hier das lokale Active Directory
  • Connected System Objekt Type: Uns interessieren nur "User"
  • Metaverse Object Type: Das Objekt im Metaverse, auf das die Änderungen angewendet werden.
  • Link Type: Join bedeutet, dass die Daten zu einem bestehenden Objekte zusammengeführt werden.
  • Precedence: Die Priorität in der sich diese Regel in andere Regeln einfügt. Die Regel sollte eine niedrige Nummer haben als andere Regeln.
  • Tag:

Die beiden nächsten Eingabemasken für "Scoping Filter" und "Join Rules" werden nicht genutzt. Weiter geht es dann auf "Transformations", auf der die Zuordnung der Felder addiert wird. Über "Add Transformation" addiere ich eine neue Zeile, in der ich dann eingeben:

  • Flowtype: Expression
  • Target Attribute: UsageLocation
  • Source : IIF(IsNullOrEmpty([c]),"DE",[c])
    Achten Sie beim kopieren darauf, dass "Computer Anführungszeichen" im Ziel laden, Es gibt je nach Zeichensatz ja durch aus mehrere wie " und ”. Der Code kopiert den Inhalt von "c", wenn er nicht leer ist. Ansonsten schreibt er ein "DE" als Default rein, was für deutsche Anwender natürlich passender ist. Am Anfang steht wirklich ein "IIF" mit zwei "I"

Mit einem "ADD" wird die Regel addiert und wir landen wieder auf dem Startfenster.

Wenn beim "Add" ein Fehler kommt, das ein Objekt nicht referenziert ist, dann gehen Sie noch mal zur erste Seite zurück und addieren im Feld "Tag" einfach einen beliebigen String. Das war wohl ein Problem von früheren Versionen in der Fixliste ist der Fehler ab Version 1.1.614.0 vom 5. Sep 2017 als gefixt aufgelistet

ADSync Inbound Rule anlegen

Nun müssen wir natürlich noch eine zweite Regel anlegen, um das Feld auch ins AzureAD zu übertragen. Dazu müssen Sie im Rule Editor erst einmal die Einstellung auf "Outbound" umstellen

Wenn Sie dann auf "Add new Rule" klicken, sieht das Fenster fast genauso aus. Links oben sollte aber nun "Create outbound synchronization rule" stehen. Auch hier füllen Sie die erste Seite wieder aus mit

Auch hier sollte die Precedence niedriger sein als der niedrigste Eintrag. Bei mir war der bei 145 so dass ich den Vorgaben des Blog-Artikels gefolgt bin. Die zwei folgenden Eingabemasken für "Scoping Filter" und "Join Rules" bleiben ungenutzt und es geht auf "Transformations" weiter. Auf der die Zuordnung der Felder addiert wird. Über "Add Transformation" addiere ich eine neue Zeile, in der ich dann folgendes eingeben.

Meine Eingabe unterscheidet sich auch hier vom US-Blog, der Werte anzeigt, die bei mir gar nicht möglich sind. Ich habe z.B. gar kein Targetattribute "c" in AzureAD. Die obige Zeile macht aber genau, was ich will.

Manueller Lauf

Damit die Änderungen schnell aktiv werden, wir manuell ein Lauf gestartet

Start-ADSyncSyncCycle -PolicyType Delta

Nach all den Änderungen lassen wir ADSync wieder "geplant" laufen. Dieser Hinweise fehlte im englischen Post

Set-ADSyncScheduler -SyncCycleEnabled $true

Denken Sie aber nun immer daran, dass Sie hier manuell einen Abgleich addiert haben und die UsageLocation in der Cloud quasi immer von dem Feld "c" im lokalen On-Prem Active Directory bestimmt wird.

Das wird aber auch von Microsoft nicht wirklich kritisch gesehen.

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.
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-licensing-group-advanced

Im produktiven Tenant von Net at Work habe ich diese Änderungen im Jahr 2017 schon umgesetzt, als ADSync sich noch nicht um die UsageLocation gekümmert hat. Als ADSync dann auch die UsageLocation schreiben wollte, hatte ich zwei Regeln mit dem gleichen Ziel und unterschiedlichen Quellen. Allerdings waren die Regeln so geschickt angelegt, dass leere Felder nicht gelöscht haben sondern einfach ignoriert wurden. So konnte ich in aller Ruhe die gewünschten Werte aus "c" auch nach "msExchUsageLocation" kopieren und dann die manuelle Regel entfernen. Auch der FullSync nach der Regeländerung hat keine Änderungen in der Cloud verursacht.

Auswirkungen

Ich habe Testweise bei einem Benutzer die UsageLocation mehrfach geändert aber keine direkten Auswirkungen bemerkt. Es wurde weder meine Outlook oder Exchange Sprache umgestellt noch wurde die Einwahlkonferenznummer geändert und damit auch keine neuen Meeting-Updates versendet.

Das bedeutet aber nicht, dass dies immer und auch zukünftig der Fall ist. Prüfen Sie Änderungen zuerst mit Pilotbenutzern

Weitere Links