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.
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:
Update: Im FSLogix-Paket haben sich Pfade geändert, die unnötige Fehlermeldung zu Beginn ist entfernt und die Pfade sind angepasst.
Leider ist FSLogix nicht in Windows-Update(s) enthalten. Der Admin einer RDS-Farm muss also selbstständig für seine Updates sorgen.
Da es aber in der Tat häufiger mal Updates für FSLogix gibt (Siehe Hotfix-Liste), die beispielsweise Fehler mit der Microsoft Office 365 Aktivierung beheben, lohnt es sich diese auch wirklich zu installieren. Man kann das Setup in derselben Version auch mehrfach ausführen, es wird nur installiert, wenn wirklich etwas Neues dabei ist.
Der Vorgang ist prinzipiell einfach: Neue Version herunterladen, ZIP-Datei auspacken, App-Installer ausführen und Server neu starten. Wäre das nicht toll, wenn das auch automatisch geht?
Lösung
Bei dem letzten Einsatz, der das Problem „Leeres Microsoft 365 Anmeldefenster“ behebt, ist ein PowerShell Script das selbiges tut entstanden. Einsatz auf eigene Gefahr ☺️
# Update FSLogix to "latest"
# [email protected]
#
# Achtung: BOOTET bei Erfolg den Server neu, ohne Rueckfrage!
# Aktuelle FSLogix-Version liegt hier
$FslogixUrl= "https://aka.ms/fslogix_download"
# Download landet hier
if ( Test-Path "C:\Windows\Temp\fslogix\install" ) { Remove-Item "C:\Windows\Temp\fslogix\install" -Force -Recurse }
mkdir "C:\Windows\Temp\fslogix\install" -Force | Out-Null
Write-Host "Download von" $FslogixUrl "... (180Mbyte)"
# Ausblenden der ProgressBar macht den Download 5x schneller
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $FslogixUrl -OutFile "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -UseBasicParsing
# Auspacken
Write-Host "Auspacken von C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip ..."
Expand-Archive -LiteralPath "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -DestinationPath "C:\Windows\Temp\fslogix\install" -Force -Verbose
Set-Location "C:\Windows\Temp\fslogix\install\x64\release"
# Installieren + Neustart
Start-Process "FSLogixAppsSetup.exe" -ArgumentList "/install /quiet" -Wait -Passthru
Das Erzwingen einer „selbstständigen“ Kennwortänderung kommt schon mal vor – vor allem, wenn ein Admin mit viel Wissen ein Unternehmen verlässt. Das ist in Microsoft 365 im GUI leider nicht möglich, aber natürlich an der PowerShell.
So zwingt man einen (oder mehrere) Benutzer, das eigene Kennwort bei der nächsten Anmeldung zu ändern – ohne das Kennwort zu kennen.
Wichtig: Man muss sowohl den Parameter ForceChangePassword als auch ForceChangePasswordOnly setzen. Wenn man ForceChangePasswordOnly überspringt, wird nur ein neues Kennwort für den Benutzer (automatisch) generiert und man muss selbiges manuell verteilen (Stichwort „Initialkennwort“).
