Windows Update Fehler 0x80070643 bei KB5034441 oder KB5034439

Problem

Die aktuellen Windows Updates KB5034441 (Clients) und KB5034439 (Server) verursachen gerne mal den Fehler 0x80070643.

Der Fehlercode bedeutet im wesentlichen „zu wenig Speicherplatz“. Das bezieht sich in diesem Fall allerdings nicht auf die Platte bzw. Windows-Partition, sondern die Wiederherstellungspartition („WinRE“).

Auf Clients ist diese in der Regel zu klein wenn der Fehler auftritt, auf Servern kann es auch schonmal vorkommen, dass die Partition gar nicht existiert.

Sofern ganz sicher keine Recoveryumgebung benötigt wird, kann das Update im Prinzip einfach ignoriert werden (Zitat aus den MS KB-Artikeln: „HINWEIS: Wenn Ihr ausgeführter PC nicht über eine WinRE-Wiederherstellungspartition verfügt, benötigen Sie dieses Update nicht.“)

Sollte (sicherheitshalber) doch eine Recoverypartition erwünscht sein, hier die Kurzanleitung zum (Neu-)Erstellen und Vergrößern:

Lösung:

zunächst eine Konsole als Admin starten.

WinRE Status prüfen und ggfs. deaktivieren (wenn vorher „Enabled“):

C:\> reagentc /info
C:\> reagentc /disable

Ggfs. vorhandene Recoverypartition löschen und Windows-Partition verkleinern:

C:> diskpart
DISKPART> list disk
DISKPART> sel disk <OS Disk Nummer, i.d.R. 0>
DISKPART> list part
DISKPART> sel part <OS Partitionsnummer, i.d.R. 3>
DISKPART> shrink desired=250 minimum=250
DISKPART> sel part <WinRE Partitionsnummer, i.d.R. 4>
DISKPART> del part override

Neue Recoverypartition erstellen:

DISKPART> list disk
DISKPART> sel disk <OS Disk Nummer, i.d.R. 0>

# nur für GPT-Disks:
DISKPART> create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
DISKPART> gpt attributes =0x8000000000000001

# nur für MBR-Disks:
DISKPART> create partition primary id=27

# Partition formatieren:
DISKPART> format quick fs=ntfs label=”Windows RE tools”
DISKPART> exit

Sofern es vorher bereits eine Recoverypartition gab, kann diese nun einfach wieder aktiviert werden:

C:> reagentc /enable

Sofern es vorher keine aktive Recoverypartition gab, schlägt das fehl. Dann fehlt vermutlich auch das RE-Image in C:\Windows\System32\Recovery\WinRe.wim (reagentc /enable bzw. /disable verschiebt das Image zwischen der Partition und der Datei hin und her)

Dann muss man sich diese vom Installationsmedium (ISO) holen. Das geht am einfachsten per 7zip, das kann die ISO und die darin enthaltenen install.wim Files einfach öffnen. Aus dem Pfad \sources\install.wim\1\Windows\System32\Recovery\ im ISO kann die WinRe.wim dann nach C:\Windows\System32\Recovery\ kopiert werden.

Danach sollte sich das WinRE mittels reagentc /enable dann korrekt aktivieren lassen (WinRE.wim wird wieder aus System32\Recovery\ auf die Recoverypartition verschoben)

Danach sollte sich das Update dann problemlos installieren lassen.

PowerShell: Liste alle Dienste auf allen Servern auf, die als Benutzer (oder Administrator) starten

Bei einer Kennwortänderung in kleinen Domänen, also wenn das „Administrator“ Kennwort nach laaaanger Laufzeit geändert wird, müssen einige Dienste, die im Laufe der Zeit als solcher eingerichtet wurden, ebenfalls geändert werden. In den meisten Fällen ist im Laufe der Zeit auch die Anzahl der Server gewachsen.

Wie kommt der faule Administrator als nun an eine Liste der Server, wo die Anmeldedaten von Diensten angepasst werden müssen?

Lösung

Unter der Voraussetzung, dass PowerShell Remoting eingerichtet und funktionsfähig ist, hilft dieses kleine aber feine Script.

Zuerst wird eine Liste aller Server aus dem AD geholt und dann via WMIC eine gefilterte Liste der Dienste geholt, die nicht als „LocalSystem“ oder „NT Author%“ gestartet werden. Letzteres ist ein Trick, um sowohl „NT Authorität“ als auch „NT Authority“ auf Deutsch und Englisch zu erwischen.

Import-Module ActiveDirectory

$Servers = ( (Get-ADComputer -Filter 'operatingsystem -like "*server*" -and enabled -eq "true"').dnshostname )
$ServiceName =  @{ Name = 'ServiceName'; Expression = {$_.Name}}
$ServiceDisplayname = @{ Name = 'Service DisplayName';  Expression = {$_.Caption}}

foreach ($server in $servers) {
    Invoke-Command $server -ScriptBlock {
        Get-CimInstance -Class Win32_Service -filter "StartName != 'LocalSystem' AND NOT StartName LIKE 'NT Author%' " } | 
            Select-Object SystemName, $ServiceName, $ServiceDisplayname, StartMode, StartName, State | format-table -autosize
}

PowerShell startet nicht mehr (System.ArgumentException, SHostUserInterface.GetTranscriptOptionFromSettings, System.IO.Directory.CreateDirectory)

Unter Windows Server 2012R2 startet die PowerShell „auf einmal“ nicht mehr. Nach dem Start erscheint direkt „powershell funktioniert nicht mehr“ und der Konsolenhost schießt sich wieder.

Server 2012R2 ist zwar bekanntermaßen EOL und muss weg, aber manchmal braucht man für den Wechsel auf ein neues System nun ebenjene PowerShell.

Die PowerShell stürzt ab mit diesem Fehler:

Problemsignatur:
  Problemereignisname:	PowerShell
  NameOfExe:	powershell.exe
  FileVersionOfSystemManagementAutomation:	6.3.9600.21616
  InnermostExceptionType:System.ArgumentException
  OutermostExceptionType:System.ArgumentException
  DeepestPowerShellFrame:SHostUserInterface.GetTranscriptOptionFromSettings
  DeepestFrame:System.IO.Directory.CreateDirectory
  ThreadName:	Consol.. main thread
  Betriebsystemversion:	6.3.9600.2.0.0.400.8
  Gebietsschema-ID:	1031

Lesen Sie unsere Datenschutzbestimmungen online:
  http://go.microsoft.com/fwlink/?linkid=280262

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
  C:\Windows\system32\de-DE\erofflps.txt

Lösung

In diesem Fall war es die Gruppenrichtlinie „PowerShell-Aufzeichnung aktivieren“ (Computer > Administrative Vorlagen > Windows-Komponenten/Windows PowerShell > PowerShell-Aufzeichnung aktivieren).

Die GPO setzt diesen Registry-Schlüssel:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription]
"EnableTranscripting"="1"

Server 2012R2 erwartet aber nicht nur diesen Key, sondern auch noch den Ausgabepfad als Zeichenkette (OutputDirectory). Bleibt die Zeichenkette leer, startet die PowerShell nicht mehr. Als Gegenprobe: Setzt man den Eintrag „EnableTranscripting“ auf „0“ funktioniert sofort wieder alles – bis die GPO den Eintrag wieder zurückändert.

Also gibt es als schnelle Lösung eine *.reg-Datei, die einfach dort einen Pfad (den es geben sollte!) hinzufügt:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription]
"OutputDirectory"="C:\\Windows\\Temp"

Solle die GPO beim nächsten gpupdate den Pfad wieder leeren, müsste man seine Richtlinie entsprechend anpassen. Oder (empfohlen) die Migration des 2012R2-Systems ASAP abschießen.

Windows Updates über die Eingabeaufforderung deinstallieren

Aus gegebenem Anlass 🥴 hier die schnelle Notiz zur Entfernung von Windows-Updates an der Kommandozeile. Das braucht man schon mal, wenn mal wieder ein Windows 11 den Nutzer mit einem leeren schwarzen Bildschirm begrüßt. Das eine oder andre Update löst diesen Effekt ja bekanntermaßen aus.

In so einem Fall kann man (zum Glück) mit STRG+ALT+ENTF den Taskmanager starten und von dort aus eine Kommandozeile „Als Administrator“ ausführen.

Lösung

Updates auflisten:

dism /online /get-packages

Updates deinstallieren:

dism /online /remove-package /packagename:<NAME>

Der Name ist die „Paketidentität“ in ganzer Länge. Die Liste ist zwar leider etwas länger und nicht nach einem erkennbaren Muster sortiert, aber so kann man imerhin das „neueste“ Rollup suchen und entfernen.

Samba-Freigabe (SMB/CFIS) von Windows unter Ubuntu/Debian mounten

Samba ist das Standard-Tool für Unix-basierte Betriebssysteme um mit Windows-Freigaben via SMB oder CIFS zu interagieren. Es ermöglicht unter Linux die Datei- und Druckfreigabe von Windows-Computern aus zu nutzen. Grundsätzlich verwendet Samba das SMB/CIFS-Protokoll für einen ziemlich sicheren, stabilen und zuverlässigen Datei-/Druckerfreigabezugriff.

Gestandene Admins nutzen Samba natürlich auswendig. Für alle anderen ist diese Schritt-für-Schritt Anleitung gedacht.

Wir möchten einen Samba-Share (eine Windows-Freigabe) permanent unter Linux verbinden, so dass diese auch nach einem Neustart zur Verfügung steht.

Schritte zum Mounten von einer Freigabe unter Ubuntu und Debian

1. Das Debian-Paket cifs-utils auf dem System installieren:

sudo apt-get install cifs-utils

2. Erstellen des Ziel-Verzeichnis zum Mounten der Freigabe

sudo mkdir /media/freigabe

3. Credentials (Anmeldeinformationen) ablegen. Die Datei wird die unverschlüsselten Zugangsdaten enthalten und sollte daher aus Sicherheitsgründen mit einem Punkt (.) zu einer versteckten Datei gemacht werden. Es empfiehlt sich außerdem, diese im Home-Verzeichnis zu erstellen und mit entsprechend restriktiven Rechten zu versehen.

Datei anlegen …

vi /root/.smbcredentials

… mit diesem Inhalt:

username=benutzername
password=passwort

Zum Beispiel:

username=AD.EXAMPLE.COM\t.musterfrau
password=Schlup2s3i4mu867psie

Diese Datei dann speichern und idealerweise nur für root lesbar machen. Dadurch wird der Zugriff von allen Nicht-Root-Konten ausgeschlossen.

chown root:root /root/.smbcredentials
chmod 400 /root/.smbcredentials

4. Testen. Mit dem folgenden Befehl kann man die Windows-Freigabe jetzt auf dem Linux-System bereitstellen

sudo mount -t cifs -o rw,vers=3.0,credentials=/root/.smbcredentials //SERVER.AD.EXAMPLE.COM/freigabe /media/freigabe

Das jetzt manuell gemountete Dateisystem bleibt für dieses Sitzung erhalten. Nach einem Reboot ist /media/freigabe aber wieder leer.

5. Automount: Der Share kann nun zur /etc/fstab hinzugefügt werden. Dann wird die Remote-Freigabe beim Systemstart automatisch bereitgestellt.

sudo vi /etc/fstab

Am Ende der Datei diese Zeile hinzufügen:

//SERVER.AD.EXAMPLE.COM/freigabe /media/freigabe cifs vers=3.0,credentials=/root/.smbcredentials

Ausprobieren

Datei dann speichern und schließen. Die Verbindung lässt sich nun auch ohne echten reboot testen:

sudo umount /media/freigabe
sudo systemctl daemon-reload
sudo mount -a

Mögliche Fehler und Samba-Fehlersuche

Es gibt zahlreiche Dinge, die beim mounten schiefgehen könnten. Hilfreich ist bei der Fehlersuche immer die verbose Ausgabe von mount:

sudo mount -vvvv -t cifs -o rw,vers=3.0,credentials=/root/.smbcredentials //SERVER.AD.EXAMPLE.COM/freigabe /media/freigabe

Ich habe ein paar mal den Fehler „cifs_mount failed w/return code = -13“ gesucht. Der Fehler „-13“ bedeutet ausgeschrieben:

CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE

Das steht schlicht für Name/Kennwort falsch. Mal stimmt die Domäne nicht, mal das Kennwort, mal der Name. Ein spezieller Stolperstein ist hier auch gerne die Begrenzung auf 20 Zeichen lange Benutzernamen – ist der Name länger, schlägt die Anmeldugn auf jeden Fall fehl.