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.
- ISO 3166-1
https://en.wikipedia.org/wiki/ISO_3166-1
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 - Audio Conferencing Policies
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.
- Office 365 Lizenzen mit Azure Groups
- Set-MsolCompanySettings
https://docs.microsoft.com/en-us/powershell/module/msonline/set-msolcompanysettings - Azure Active Directory PowerShell for Graph
https://learn.microsoft.com/en-us/powershell/azure/active-directory/overview - Modul MSOnline
https://learn.microsoft.com/en-us/powershell/module/msonline/ - Set-MsolCompanySettings
https://learn.microsoft.com/en-us/powershell/module/msonline/set-msolcompanysettings - Nutzungsspeicherort (Usage Location) mit
Azure AD Connect synchronisieren
https://jans.cloud/2019/10/nutzungsspeicherort-usage-location-mit-azure-ad-connect-synchronisieren/
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.
- How to customize a synchronization rule
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-create-custom-sync-rule - 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/
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 pausierenWie 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 anlegenWenn 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:
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:
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 anlegenNun 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 LaufDamit 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. |
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
- ADSync mit Exchange Online
- Exchange Management Rolle
- Hybrid Connector Server
- Audio Conferencing Policies
- 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/ - 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 - 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 - 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/ - Nutzungsspeicherort (Usage
Location) mit Azure AD Connect
synchronisieren
https://jans.cloud/2019/10/nutzungsspeicherort-usage-location-mit-azure-ad-connect-synchronisieren/