Manchmal sind Server „weg“, bevor sie ordentlich bei Azure Arc ge-offboarded wurden; das Offboarding ist nicht immer Teil eines Dekomissionierungsprozesses. Die „veralteten“ Maschinen bleiben dann Teil des Azure Arc und liefern einfach keine Daten mehr. Diese können natürlich weg.
Lösung
Leider hat Microsoft „vergessen“ im GUI die notwendigen Knöpfe einzubauen. Das wäre aber logisch, sinnvoll und einfach.
So wird man Maschienen aus Azure Arc an der PowerShell (als Aministrator) los:
# Az Modul installieren
Install-Module Az.ConnectedMachine
# Mit Azure Arc verbinden
Connect-AzAccount
# Maschine ansehen
Get-AzConnectedMachine -Name <SERVERNAME> -ResourceGroupName <RESSOURCENGRUPPE>
# Maschine entfernen
Get-AzConnectedMachine -Name <SERVERNAME> -ResourceGroupName <RESSOURCENGRUPPE>| Remove-AzConnectedMachine
„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.
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:
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.
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:
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.
