Aktuelle Windows Update-Quelle anzeigen

Manchmal muss man „mal eben“ herausfinden, von welcher Update-Quelle ein lokales Windows Computer seine Updates beziehen möchte. Leider gibt es seit (Windows 2003) keine einfache, schnelle und zuverlässige Anzeige dafür.

Man kann die tatsächliche aktuelle Update-Quelle (natürlich nur zur Sicherheit) am zuverlässigsten direkt über den Windows Update-Dienst mit einem kurzen PowerShell-Befehl ausgeben. Der aktuelle Zustand des Dienstes wird sofort angezeigt, ganz ohne den Zugriff auf Registry-Schlüssel, Intune-Konfigurationen oder Gruppenrichtlinien.

Lösung

Man benötigt eine PowerShell „Als Administrator“:

(New-Object -ComObject Microsoft.Update.ServiceManager).services | Select-Object Name,IsDe*

Dekommissionierte Server aus Microsoft Azure Arc entfernen

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“ 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