Wie man FSLogix automatisch aktualisiert (FSLogix Update)

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 der selben 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", 20231115
# [email protected] mit input von @j_vanneuville
#
# Achtung: Startet bei Erfolg den Server neu!

# URL zur aktuellen Version
$FslogixUrl= "https://aka.ms/fslogix_download"

# Download hierher
# Die literalen Pfade sind Absicht, anders waere RDS auch nicht supported
Remove-Item "C:\Windows\Temp\fslogix\install" -Force -Recurse
mkdir "C:\Windows\Temp\fslogix\install" -Force | Out-Null
Set-Location "C:\Windows\Temp\fslogix\install"
Write-Host "Download von" $FslogixUrl "... (180Mbyte)"
# Ausblenden der ProgressBar macht den Download 50x schneller m(
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $FslogixUrl -OutFile "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -UseBasicParsing

# Auspacken hierher
Write-Host "Auspacken von FSLogixAppsSetup.zip ..."
Expand-Archive -LiteralPath "FSLogixAppsSetup.zip" -DestinationPath "C:\Windows\Temp\fslogix\install" -Force -Verbose

# Installieren + Neustart
Set-Location "C:\Windows\Temp\fslogix\install\FSLogix_Apps_*\x64\release"
Start-Process "FSLogixAppsSetup.exe" -ArgumentList "/install /quiet" -Wait -Passthru

Wir finde ich schnell heraus, welcher Prozess auf einem Port lauscht?

Manchmal muss ein Admin „mal eben“ wissen, welcher Prozess einen listening Port blockiert nutzt. Auf Servern mit vielen abhörenden Ports in TCP und UDP wird die Ausgabeliste von netstat nur schnell unübersichtlich

Lösung

An der CMD- oder PowerShell geht das schneller als gedacht. ⚠️ Achtung: da die Shell international übersetzt ist, muss man find das jeweilig passende Suchwort mitgeben (English: „LISTEN“, deutsch „ABHÖREN“).

(CMD/PS) Zuerst die PID des lauschenden Prozesses finden …

netstat -ano | find "<PORT>" | find "ABH"

(PS) … dann den Prozess mit Pfad auflisten:

Get-WmiObject Win32_Process | Select ProcessId,CommandLine | findstr <PID>

(CMD) Das geht natürlich auch mit tasklist, allerdings nur ohne Pfad:

tasklist /fi "PID eq <PID>"

Die allerschnellste und PowerShell-Only Variante geht so:

Get-Process -Id (Get-NetTCPConnection -LocalPort <PORT>).OwningProcess

Das Microsoft Defender Security Portal empfielt jetzt „Windows deinstallieren“

Das Microsoft Windows Server 2012 R2 seit dem 10. Oktober diesen Jahres wirklich am Support-Ende angekommen ist, ist nicht neu. ESU natürlich ausgenommen, die Installationsbasis ist ja immer noch relativ groß.

Neu ist, zumindest für uns, aber die eindringliche „Sicherheitsempfehlung“ im Defender-Portal, das Betriebssystem schlicht zu deinstallieren 😂

Windows CA: Zertifikatsregistrierungs-Webdienst lässt sich nah Migration nicht installieren (Configuration Failed 0x80070057 (WIN32: 87))

Wenn man eine Windows CA erfolgreich migriert hat (Backup+Restore), kommt beim Versuch den CertSvc-Webdienst via ServerManger zu installieren die folgende Fehlermeldung:

Webregistrierung der Zertifizierungsstelle: Konfiguration fehlgeschlagen.
Die Einrichtung der Active Directory-Zertifikatdienste ist mit folgendem Fehler fehlgeschlagen: Der Parameter ist falsch. 0x80070057 (WIN32: 87)

Das passiert nach einer Migration und auch nur mit dem Webdienst – den man korrekterweise erst nach der CA „dazuinstalliert“. Natürlich ist das ein bekannter und bisher (Windows Server 2003-2022) ungepatchter Bug.

Lösung

Das Problem besteht darin, dass der Wert von SetupStatus in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration noch den Wert „hat“Web ist installiert“ hat. Wenn das der Fall ist, scheitert der Windows ServerManager.

Der Hexadezimalwert 6003 sagt „ist schon installiert“
Der Hexadezimalwert 6001 sgat „ist frei“

Man ändere also mal eben den Wert von SetupStatus der Registrierung auf 6001 und dann läuft die Installation des „Zertifikatsregistrierungs-Webdienstes“ durch.

Update

Ich habe soeben herausgefunden, das das sogar an der Kommandozeile vie certutil möglich ist:

certutil -setreg config\setupstatus 0x6001

Es wird noch besser, es gibt sogar eine named procedure in certutil dazu, die ebenfalls genau das selbe tut:

certutil -setreg config\setupstatus - SETUP_CLIENT_FLAG

Windows 10/11 und Windows Server „Automatische Reparatur“ vollständig abschalten

Windows 10/11 und Windows Server meinen es eigentlich gut, wenn Sie nach jeweils zwei „unerwarteten Neustarts“ (z.B. Strom aus) in die „Automatische Reparaturumgebung“ booten, anstatt das eigentlich Betriebssystem zu starten. Die Automatische Reparatur kann man zwir überspringen, aber nur wenn man eine Taste drücke.

Im Prinzip eine nette Idee, denn bei plötzlichen Stromausfällen könnte ja das Dateisystem beschädigt worden sein.

Manchmal braucht man aber ein System, das IMMER bootet. Beispielsweise für POS-Geräte die nur Informationen anzeigen sollen oder Geräte die gar keine Tastatur angeschlossen haben. Solche Geräte werden gerne öfter mal „hart“ ohne „herunterfahren“ ausgeschaltet und starten dann nicht mehr alleine.

Lösung

Um den freundlichen „Automatic Repair“ Assistenten vollständig loszuwerden, sind mehrere Schritte notwendig. Alles natürlich an der Administrator („Als Admin“) CMD Kommandozeile.

1. Die WinRE Umgebung komplett abschalten

reagentc /disable

2. Ruhezustand („Fastboot“) grundsätzlich abschalten

powercfg -h off

3. Die Recovery-Umgebung im Windows Bootlaufwerk abschalten
{current} ist dabei die Windows-Installation um die es geht. Eine Liste aller Installationen gibt bcdedit aus.

bcdedit /set {current} recoveryenabled no

4. Alle Startfehler beim booten ignorieren (auch das „dirty“ flag von NTFS)

bcdedit /set {current} bootstatuspolicy IgnoreAllFailures

Ab jetzt startet die Reparaturumgebung wirklich nicht mehr und man benötigt einen bootfähigen USB-Stick um das System im ernstfall zu prüfen.