Windows Server 2008R2 Windows Update Fehler 0x80092004

Windows Server 2008 R2 ist zwar schon in die Jahre gekommen, läuft aber hier und da noch und soll auch Updates bekommen. Die aktuellen Updates (zum Beispiel „2020-01 Sicherheitsupdate für .NET Framework 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 für Windows 7 und Server 2008 R2 für x64 (KB4534976)“ schlagen aber mit dem Fehler 0x80092004 fehl.

Grund ist die Signatur der aktuellen Patches. Der Fehlercode 0x80092004 steht für CRYPT_E_NOT_FOUND. Das Windows Update konnte einen kryptografischen Wert nicht verifizieren und lehnt das Update daher ab. Die besagten Pakete sind alle nur noch mit einem SHA2 Hash signiert – Windows 2008 R2 versteht aber kein SHA2.

Lösung

Manuell Installation des „Servicing stack update for Windows 7 SP1 and Windows Server 2008 R2 SP1: March 12, 2019“ (KB4490628) von:

http://www.catalog.update.microsoft.com/search.aspx?q=4490628

Sobald das Update SHA2ermöglichst, läuft die Installation der weiteren sofort fehlerfrei Updates durch.

Veeam Backup & Replication Console startet nicht (veeam.backup.shell.exe System.Xml.XmlException)

Problem

Die Veeam Backup & Replication Console startet „auf einmal“ nicht mehr. Gestern ging es noch, heute passiert (scheinbar) nichts mehr, es ist nicht einmal der Anmeldedialog zu sehen. Im Ereignisprotokoll sind nach jedem Versuch veeam.backup.shell.exe zu starten diese Fehler zu sehen:

  • Protokoll: Anwendung
  • Quelle: .NET Runtime
  • Ereignis-ID: 1026
Anwendung: veeam.backup.shell.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.Xml.XmlException
bei System.Xml.XmlTextReaderImpl.Throw(System.Exception)
bei System.Xml.XmlTextReaderImpl.ParseText(Int32 ByRef, Int32 ByRef, Int32 ByRef)
bei System.Xml.XmlTextReaderImpl.ParseText()
bei System.Xml.XmlTextReaderImpl.ParseElementContent()

[...]

Lösung

Warscheinlich ist nur die Benutzerkonfiguration der Konsole kaputt. Das .NET Framework ist (ausnahmsweise) da mal nicht schuld.

Es hilft das Löschen der Datei:

%USERPROFILE%\AppData\Local\Veeam_Software_Group_GmbH\veeam.backup.shell.exe_Url_hu1utqnj52thvmhrg5kie2bl15o22i22\10.0.0.0\user.config

Danach startet die Konsole sofort wieder.

TEMP-Verzeichnisse aller Benutzer (und Windows) auf einmal aufräumen

Problem

Terminalserver, oder mit der modernen Bezeichnung „RemoteDesktop Sessionhosts“, neigen trotz aller Pflege dazu nach und nach „Voll zu müllen“.

Vor allem die verschiedenen TEMP-Verzeichnisse sammeln im Laufe der Zeit (meist) unnötige Daten an. Zu den „üblichen Verdächtigen“ wie %WINDIR%\Temp und %Windows%\Prefetch gesellen sich vor allem die Benutzer-Verzeichnisse Appdata\Local\Temp\.

Lösung

Mit der PowerShell kann dieses Problem in zwei Zeilen (und einem regelmäßigen Start mit enstsprechenden Rechten) gelöst werden:

$tempfolders = @("C:\Windows\Temp\*", "C:\Windows\Prefetch\*", "C:\Users\*\Appdata\Local\Temp\*" )

Remove-Item $tempfolders -force -recurse

Die erste Zeile enthält in einem Array die entsprehenden Ordner (PS versteht auch Platzhalter wie ‚*‘), die zweite Zeile den Befehl der dafür ausgeführt wird.

Einfaches WordPress Backup via Bash-Script

Bevor ich beim nächsten Fall schon wieder alles einzeln zusammensuche, hier eine kleine und schnelle Copypasta aus dem Admin-Alltag:

Sicherung einer WordPress-Instanz

Achtung: WordPress wird damit zwar vollständig eingepackt und die Datenbank gesichert, aber es gibt keine Fehlerbehandlung (Datei existiert bereits …) und auch keinen CSRF-Schutz. Die Kommandozeilen-Argumente werden un-escaped ausgeführt.

⚠ Das Backup landet automatisch in ~/priv wenn man den zweiten Parameter weglässt.

Syntax:

./wordpress-backup.sh /var/www/path-to-wordpress

Code:

#!/bin/bash
#
# SEHR einfaches WordPress-Backup

# Commandline-Argumente da?
if [ $# -eq 0 ]; then
    echo "SYNTAX: wordpress-backup.sh <path-to-WordPress> <path-to-BackupFolder> [dbonly]"
    exit 1
fi

wpdir=$1
bakdir=$2

# Backupverzeichnis angegeben?
if [ -z "$bakdir" ]; then
    bakdir="~/priv"
fi

# Verzeichnisse da?
if [ ! -d $wpdir ]; then
    echo "Directory $wpdir does not exist."
    exit 1
fi
if [ ! -d $bakdir ]; then
    echo "Directory $bakdir does not exist."
    exit 1
fi

# Sinnvolle Dateinamen zusammenbauen
db_backup_name="wp-db-backup-"`date "+%Y%m%d"`".sql.gz"
wpfiles_backup_name="wp-files-backup-"`date "+%Y%m%d"`

# Zugangsdaten aus der config suchen
db_name=`grep DB_NAME $wpdir/wp-config.php | cut -d \' -f 4`
db_username=`grep DB_USER $wpdir/wp-config.php | cut -d \' -f 4`
db_password=`grep DB_PASSWORD $wpdir/wp-config.php | cut -d \' -f 4`

# MySQLdump, gzip
mysqldump --opt -u$db_username -p$db_password $db_name | gzip > $bakdir/$db_backup_name

# Nur wenn der dbonly Parameter nicht gesetzt ist
if [ ! "$3" = "dbonly" ]; then
    # WordPress einpacken
    tar -czvf $bakdir/$wpfiles_backup_name.tar.gz $wpdir

    # Oder als zip:
    #zip -r $bakdir/$wpfiles_backup_name $wpdir
fi

Festplatten („Datenträger“) werden nicht (vollständig) im Taskmanager angezeigt

Auf manchen Systemen starten die Leistungsindikatoren für physische Datenträger nicht automatisch und im Taskmanager werden daher die Leistungsdaten der Dateträger nicht angezeigt.

Wenn man etwas über den Durchsatz wissen möchte, müsste man dort immer den Ressourcenmonitor starten, aber es geht auch schneller.

Es werden nicht immer alle Datenträger angezeigt

Die Leistungsindikatoren der Festplatten „disks“ werden mit „diskperf“ gesteuert. Mit diesen Befehl schaltet man alle Leistungsindikatoren ein und sorgt dafür, das diese beim nächsten start auch automatisch geladen werden:

C:\>diskperf -Y

Logische und physische Leistungsindikatoren auf diesem System
        werden automatisch aktiviert.
Raw-Leistungsindikatoren werden auch für IOCTL_DISK_PERFORMANCE verwendet.

C:\>

Ereignis 513 von CAPI2 „An error occurred in Cryptographic Services while processing the OnIdentity()call in System Writer Object.“

Unter Windows Server 2016/2019 meldet der Volume Shadow Copy Service (VSS) auf einigen Systemen das Fehler-Ereignis 513:

Protokollname: Anwendung
Quelle: Microsoft-Windows-CAPI2
Ereignis-ID: 513
Aufgabe Kategorie: keine
Ebene: Fehler

Beschreibung
Fehler im Kryptografiedienste beim Verarbeiten der OnIdentity()System Writer-Objekt.

Das Original der CAPI2 Fehlermeldung in Englisch:

Log Name: Application
Source: Microsoft-Windows-CAPI2
Event ID: 513
Task Category: none
Level: Error

Description:
An error occurred in Cryptographic Services while processing the OnIdentity()call in System Writer Object.

Details:
AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol.

System Error:
Access is denied.

Lösung

Das Problem tritt auf, wenn der VSS Writer „System“ nicht über die passenden Berechtigung zum auslösen des VSS-Prozesses verfügt. Die Anmelderegistrierung erstellt dann für das Dienstkonto (Lokaler Dienst) diesen Fehler.

Man muss nur die Berechtigungen für „Lokaler Dienst“ zu mslldp hinzufügen. Die vorhandenen Berechtigungen zeigt man an mit:

sc sdshow mslldp

An diesen String hängt man die ID für „Lokaler Dienst“ an, die etwa so aussieht:

(A; CCLCSWLOCRRC;;; SU)

Und fügt dann alles zusammen (also den originalstring und den Bezeichner von Lokaler Dienst) an. Das sieht (zum Beispiel) so aus:

sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;CCLCSWLOCRRC;;;SU)

Windows 10 VPN Einwahl bricht ab, Ereignisprotokoll zeigt Fehler 720

Nach einigen Windows-Updates mag so manche Windows 10 Installation plötzlich keine VPN-Verbindungen mehr herstellen. Das passiert häufig wenn es eine weitere Software-Adapterlösung auf der Maschine gibt (NordVPN, TeamViewer VPN Adapter …).

Bei dem Fehler 720 bei VPN-Verbindungen unter Windows 10 gibt es aber diese beiden Lösungen, die fast immer helfen.

Die offizielle Fehlermeldungen-Liste von Microsoft hilft da leider auch nicht weiter und sagt nur dise Meldung bedeutet „Keine PPP-Kontrollprotokolle konfiguriert“ (oder in Englisch: „No PPP control protocols configured“). Zum Schmunzeln: Der zugehörige Artikel ist auch noch von der KI übersetzt und nennt sich selbst „Fehler 720: keine PPP steuern konfiguriert“. Das wird es sein 🙂

Möglichkeit 1: WAN-Miniports neuinstallieren

Im Gerätemanager sind unter dem Netzwerkadapter für jedes Verbindungsprotokoll einzeln die WAN Miniports aufgeführt (WAN Miniport IKEv2, WAN Miniport IP, …).

Diese Miniports einfach ALLE entfernen (Rechte MT, dann „deinstallieren“ wählen) und danach den PC neu starten. Nach dem reboot funktioniert das VPN in der Regel sofort wieder wie vorher. In seltenen Fällen mussten wir die VPN-Verbindung neu erstellen bevor es wieder lief.

Möglichkeit 2: TCP/IP komplett zurücksetzen

Achtung, nach diesem Schritt sind keine manuellen IP-Konfigurationen mehr da, man muss seine Adapter alle neu konfigurieren!

In einer „Als Administrator“ geöffneten Shell tippt man:

C:\> netsh int ip reset

Das setzt alle TCP/IP-Bindungen komplett zurück und erstellt neue IDs für die Adapterverbindung.