Kategoriearchiv: Microsoft 365

Setzen der „DefaultUsageLocation“ für das Feld „UsageLocaten“ für die Lizenzierung (Exchange, Teams, Audiokonferenzen)

Veröffentlicht am von — Keine Kommentare ↓

Für die Vergabe von Lizenzen in Microsoft 365 ist die Pflege des Feldes „UsageLocation“ in EntraID bei jedem Benutzer verpflichtend.

Außerdem wird diese Information mittlerweile auch beim Teams „Dialplan“ verwendet. Man muss hier immer das Land eintragen, in dem der Anwender arbeitet.

Dazu gibt es mehrere Möglichkeiten:

  • Manuelle Pflege: Man setzt das Feld direkt im Admin-Center bei der Lizenzzuweisung für jedes Microsoft 365 Objekt einzeln
  • Tenant Default: Neue Nutzer übernehmen die im Tenant als Default hinterlegte Eigenschaft. Änderungen sind pro Benutzer weiter möglich
  • EntraID Connect (ehemals AdSync) + AD Feld „msExchUsageLocation“: Das Feld msExchUsageLocation wird On-Premises bislang zwar nicht genutzt (oder automatisch gepflegt). Wenn man das tut, wird es von EntraIDConnect automatisch synchronisiert.
    Get-AdUser -identity "EXAMPLEDUDE" | Set-AdUser -replace @{msExchUsageLocation="DE"}
  • Eine EntraID Sync-Regel erstellen, die einen festen Wert in das AzureAD schreibt oder ein anderes Feld (z.B. „c“ [Country]) dazu verwendet

Lösung

In den vermutlich meisten Fällen reicht es, das Attribut als Standard vorzugeben und die Ausnahmen zu pflegen. Bei deutschen Organisationen ~500 Nutzende war das bisher die pragmatischste und effizienteste Lösung.

Das geht recht schnell an der PowerShell, wenn man verstanden hat wie Microsoft’s Vibecoder arbeiten.

Hier ein Beispiel für die PowerShell7 (pwsh) mit dem aktuellen Graph-Modul:

Install-Module Microsoft.Graph -AllowClobber
Install-Module Microsoft.Graph.Authentication
Install-Module Microsoft.Graph.Identity.DirectoryManagement
Connect-MgGraph -Scopes Organization.ReadWrite.All

Update-MgOrganization -OrganizationId (Get-MgOrganization).Id -DefaultUsageLocation "DE"

Zur (Erfolgs-)Kontrolle des Attributes:

Get-MgOrganization | fl DefaultUsageLocation

Wenn man noch einen älteren Client mit der PowerShell 5 und den („deprecated“) MSOnline-Modulen hat, ist das hier das equivalent:

Install-Module MSOnline
Import-Module MSOnline -UseWindowsPowerShell 
Connect-MSOnlineService
Set-MsolCompanySettings -DefaultUsageLocation "DE"

Dateien in Microsoft Teams (Chats) an externe Benutzern senden erlauben

Veröffentlicht am von — Keine Kommentare ↓

In Teams-Chats mit einem externen Kontakt, einem Kunden, Lieferanten oder Partner möchte man gerne mal eine Datei versenden. Man sucht das „Plus“ Symbol und … diese Option gibt es plötzlich nicht. Wenn man versucht, eine Datei aus dem Explorer in den Chat zu ziehen, blockiert ein rotes „X“ den Versuch.

Das ist kein Fehler, sondern eine Sicherheitsrichtlinie. Standardmäßig verhindert Microsoft Teams, dass Unternehmens-Benutzer Dateien in Chats mit externen Teilnehmern anhängen. Viele uns bekannte Admins (und Endbenutzer) wissen nicht, dass der Versand überhaupt möglich ist.

Lösung: Dateiversand (und „Freigabe“) über PowerShell aktivieren

In der PowerShell kann man mit dem Teams-Modul die globale Richtlinie schnell bearbeiten:

# Teams PS-Modul installieren
Install-Module -Name MicrosoftTeams -Force -AllowClobber

# Modul Importieren/Verbinden
Import-Module MicrosoftTeams
Connect-MicrosoftTeams

# Richtlinie ansehen
Get-CsTeamsFilesPolicy

# Externe Dateifreigabe ("FileSharingInChatsWithExternalUsers") aktivieren

Set-CsTeamsFilesPolicy -Identity "Global"-FileSharingInChatsWithExternalUsers Enabled

Die „Global“ Richtlinie gilt stets für alle Benutzer des Mandanten.

Wenn man die Berechtigung nur bestimmten Benutzern (oder Gruppen) gewähren möchten, erstellt man stattdessen eine benutzerdefinierte Richtlinie und weiset diese den entsprechenden Objekten zu. Die Globale lässt man auf „disabled“.

Die Änderung der Richtlinie greift sofort. In größeren Tenantns (400+ Nutzer) haben wir auch schon minutenlange Wartezeit gesehen, aber grundsätzlich geht das schnell und benötigt überraschenderweise keinen Neustart des Teams-Clients.

„Self-Service-Testversionen“ in Microsoft 365 vollständig deaktivieren

Veröffentlicht am von — Keine Kommentare ↓

„Self-Service-Testversionen“ sind kostenlose Testphasen für Microsoft 365 Apps und Services, die Nutzer eigenständig und ohne Einbindung der IT aktivieren können.

Testversionen ermöglichen dem Nutzenden in der Regel „sofort“ Zugriff auf Premium-Funktionen, laufen in der Regel 30 oder 90 Tage und können sich, sofern Zahlungsmethoden direkt bei Microsoft hinterlegt wurden, mehr oder weniger automatisch in kostenpflichtige Abonnements umwandeln.

Im Admin-Center Einstellungen > Organisation > Testversionen

Die ablenkenden Premium-Buttons in Apps von Teams bis PowerBI stellen eine nervige Werbung dar. Außerdem kommt es manchmal auch zu „spannende“ Situationen, wenn Nutzer eines Unternehmens ungewollt an der IT-Organisation vorbei, Prozesse in einer solchen Schatten-IT erstellen. Das geschieht, so unterstellen wir, zwar oft in guter Absicht, stellt aber eine schwelende Gefahr dar.

„Self-Service-Testversionen“ für alle Produkte via PowerShell abschalten

Wie es sich für einen kundenfernen Großkonzern wie Microsoft gehört, ist die Deaktivierung der Funktion(en) (es sind mehrere) eine fummelige Kleinarbeit im GUI – oder für Admins denkbar umständlich.

PowerShell, natürlich „als Administrator“ ausführen, als Globaler Admin am m365 anmelden.

# PS Modul installieren und verbinden
Install-Module -Name MSCommerce
Import-Module -Name MSCommerce
Connect-MSCommerce

# Optional: Produkte mit Erlaubnis auflisten
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

# Alles abschalten
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Where { $_.PolicyValue -eq "Enabled"} | ForEach { Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductID -Enabled $false }

Selbstverständlich muss das mit jedem neu erscheinenden Produkt erneut ausgeführt werden; die Einstellung gilt pro Produkt, nicht global.

Azure Update Manager für Server in Betrieb nehmen (WSUS Nachfolge) – von Null

Veröffentlicht am von — Keine Kommentare ↓

Der Azure Update Manager ist ein Dienst, der als designierter WSUS Nachfolger Updates für Server (Windows und Linux) verwalten kann. Azure Arc ist dabei die „Brücke“ zwischen Servern und der Azure Verwaltung, der Update Manager nutzt die Arc-Verbindung für das Update Management.

Wir wurden ein einige Male gefragt, wie man nun genau zu seinem Arc-Manager kommt. Auf die Lizenzierung, Kosten und die Konfiguration von Wartungsfenstern für Server geht dieser Artikel nicht ein.

Von „Null“ zum Azure Arc Update Manager

Zuerst braucht man eine Azure Subscription. Aktuell geht das auf zwei Arten:

  1. Azure Subscription mit einer Kreditkarte einrichten. Ohne CC geht es nicht.
  2. Azure Plan über einen guten CSP-Partner einrichten lassen. Wenn Kosten entstehen (und auch nur dann), bekommt man von diesem eine Rechnung. Außerdem kann der oft bei Problemen weiterhelfen.

Wenn das geschehen ist, hat man (mehr oder weniger automatisch) einen „Mandanten“ und durch den Plan/Subscription ein „Abonnoment“.

Nun braucht man noch eine „Ressourcengruppe„.

1. Das Azure Portal öffnen, einloggen und zu Ressourcengruppen wechseln, „Erstellen“ klicken.

    2. Abonnement auswählen, Namen (ohne Leerzeichen) vergeben. Dann mit „überprüfen und erstellen“ bestätigen.

    Das war es schon. Ab jetzt kann man den „AzureConnectedMachineAgent“ einrichten und verwenden.

    Klassisches Outlook ersetzt Umlaute und Sonderzeichen beim Senden durch Fragezeichen

    Veröffentlicht am von — 2 Kommentare ↓

    Dass Microsoft seit 2025 ein ausgewachsenes Vibecoding-Problem hat, ist Eingeweihten nicht neu. Hier das neueste „kreative“ Office-Problem.

    Problem

    Wenn man Umlaute in eine E-Mail verwendet (ä, ü, ö) oder Sonderzeichen nutzt (Wie das Durchmesser-Symbol „⌀“) werden diese als Fragezeichen verschickt. Das Fragezeichen bleibt auch in den „Gesendeten Objekten“ als solches erhalten.

    Lösung

    Laut dem zugehörigen Microsoft-Artikel ist das Problem zwar schon länger bekannt, aber es gibt noch keine Lösung:

    https://support.microsoft.com/de-de/topic/das-klassische-outlook-ersetzt-akzentierte-und-erweiterte-zeichen-durch-fragezeichen-c1fdb067-38ca-464a-bcb1-bd657a85e1d3

    Es gibt aber zwei Workarounds.

    Workarounds

    Workaround #1: Das neue Outlook (…) oder Outlook Web Access (OWA) verwenden. Dort tritt der Fehler bisher nicht auf. Vermutlich bis es ein noch neueres Outlook new new 2 final gibt (</sarkasmus>).

    Workaround #2: Auf eine funktionierende Version downgraden.

    Um auf die (bekannt funktionierende) Version 2512 (Build 19530.20184) zurückzuspringen, öffnet man eine Eingabeaufforderung „als Administrator“ und sagt dem Click-to-Run Client das man ein bestimmtes Image starten möchte:

    "%programfiles%\Common Files\Microsoft Shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.19530.20184

    Dann deaktiviert man in einer Office-App unter Datei > Office-Konto > Updateoptionen auswählen > „Updates deaktivieren“ die erneute Aktualisierung.

    ⚠️ Updates, auch Sicherheitsupdates, bleiben dann abgeschaltet. Das sollte keine Dauerzustand sein. Microsoft meint, das man zum „10. März“ Updates erneut versuchen soll. Vielleicht ist der Fehler ja dann behoben.