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

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

Super Simples DynDNS (DDNS) Update via PowerShell

Manchmal muss man nur „schnell mal eben“ eine IP-Adresse im DNS via DynDNS aktualisieren. Zum Testen, für schnelle Hostname-Verbindungen, um einen PC erreichbar zu machen oder ähnliches. Dynamisches DNS hat auch in der heutigen Zeit noch eine große Bedeutung.

Wie aktualisiert man also einen DDNS Namen an der Kommandozeile?

Lösung

Sehr schnell und sehr einfach, ohne Fehlerhandling:

# Supersimpler DDNS Client für PowerShell von ugg.li

# --- configuration ---
$updateURL = "UPDATEURL zB. http[s]://dynupdate.no-ip.com:8245/ducupdate.php"
$hostname = "HOSTNAME.EXAMPLE.COM"
$username = "USERNAME"
$password = "PASSWORD"

# --- IPs holen (v4 und v6) ---
$ipv6 = (Resolve-DnsName myip.opendns.com -Server 2620:119:35::35 -Type AAAA).IPAddress
$ipv4 = (Resolve-DnsName myip.opendns.com -Server 208.67.222.222 -Type A).IPAddress

# --- update DNS (v4 und v6) ---
curl.exe --user "${username}:${password}" "${updateURL}?hostname=${hostname}&myip=${ipv4}&myip6=${ipv6}"

Das Script holt sich die anfragenden (z.B. NAT) Adresse via DNS, genauer via openDNS. Schneller und sicherer (z.B. bei multihomed Hosts) ist das kaum möglich.

Natürlich gibt es auch jede Menge DDNS-Clients („DUC“ oder „NUC“) die das übernehmen können und mehr oder weniger komfortabel zu handhaben sind.

Im Wesentlichen ist dieser Schnipsel ein „aus der Not geborener“ Einzeiler der nach und nach ein bisschen gewachsen ist. Bisher gibt es keinen Plan, hieraus eine „echte“ Software mit Caching und so weiter zu machen.

Alle Systemvariablen in der PowerShell anzeigen

Mein Hand->Stirn*klatsch* Moment des Tages war grade, als ich (nach viel zu viel googlen) realisierte, dass man nicht alle PowerShell Systemvariable auswendig können muss.

Genau wie die Registry, das Filesystem, Zertifikate und so weiter sind auch die (System-)Variablen ($env) ein ganz normales PS „Drive“ und dort aufzulisten und zu nutzen.

Alle Variablen auflisten

In der PS alle Systemvariablen anzeigen:

PS C:\> gci env:*

Oder etwas mehr fancyness:

PS C:\> Gci env:* | Sort-Object name

… und dann kann man die aufgelisteten Variablen verwenden. Beispielweise:

PS C:\> $env:computername

Ein Gruppenrichtlinienobjekt (GPO) auf alle Organisationseinheiten (OUs) mit bestimmtem Namen unterhalb eines DNs anwenden (linken)

Problem

Als Windows-Administrator wird man mit Aufgaben konfrontiert, die recht einfach klingen. Bis man sie sehr oft von Hand ausführen muss.

Ein Beispiel aus der Praxis:
„Erstelle eine neue GPO und verlinke diese auf alle OUs, die ‚Würstchen‘ heißen, unterhalb von OU=Speisekarte“.

Oder anders formuliert: Verknüpfe eine Gruppenrichtlinie auf alle 3673409 OUs mit diesem Namen.

Das ist in der Gruppenrichtlinienverwaltung technisch gar kein Problem; sofern die Anzahl übersichtlich ist (und die OUs nicht über mehrere Ebenen verteil sind). Man klickt sich durch die AD-Verwaltungskonsole, öffnet Eigenschaften, fügt die GPO hinzu … und wiederholt das sehr oft.

Lösung

Das kann man glücklicherweise ganz gut mit der PowerShell automatisieren.

Dieser Schnippsel durchsucht mit -like alle OUs unterhalb eines angegebenen DN nach einem bestimmten Begriff und verlinkt automatisch die gewünschte GPO dazu.

$BaseDN = "OU=UNTERSTRUKTUR,DC=EXAMPLE,DC=COM"
$Suchbegriff = "WÜRSTCHEN"
$GPO = Get-Gpo -Name "NEUE_GRUPPENRICHLINIE"

Get-ADOrganizationalUnit -SearchBase $BaseDN -Filter * -SearchScope Subtree |
    Where-Object { $_.Name -like "*$Suchbegriff*" } |
    ForEach-Object {
    New-GPLink -Guid $GPO.id -Target $_.DistinguishedName -LinkEnabled Yes
    }

Mit diesen Zeilen wird aus ermüdender Klickarbeit eine schnelle Aktion.

Microsoft Azure AD Connect Sync Fehler „permission-issue“ mit „Connected data source error code: 5“

Wir hatten einen spannenden AADConnect (Entra ID Connect) Fehler zu suchen. Manche Microsoft 365 Gruppen wurden nicht (mehr) korrekt in das lokale AD zurückgeschrieben. Der Fehler lautete, natürlich ohne weitere Details, „Zugriff verweigert“ (permission-issue). Der Hinweis der „Connected data source error code: 5“ ist zwar ein Indiz, aber keine Lösung.

Lösung

Was die Ursache dazu war, ist nicht bekannt. Aber es sind die AD-Berechtigungen für das Synchronisationskonto auf den betroffenen Objekten. In diesem Fall „Generisches Lesen/Schreiben“ von allen Attributen einer Objekttypgruppe (und von deren Unterobjekten).

Auf dem AADConnect-Server in einer PowerShell (als Administrator) ist der Fehler schnell behoben:

# AAD Connect PS-Modul importieren
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

# Sync-Account-Namen besorgen
Get-ADSyncADConnectorAccount
# (den "ADConnectorAccountName" kopieren)

# Berechtigungen schreiben
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName "<ADConnectorAccountName>" -ADConnectorAccountDomain EXAMPLE.LOCAL

Beispiel:

Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName "MSOL_1111aaaa1111" -ADConnectorAccountDomain mydomain.local