vSphere erzeugt beim Snapshots-Erstellen NTFS-Fehler auf Windows-Servern (Event 50/57/137 …)

Veröffentlicht am von — 4 Kommentare ↓

Problem

ntfs-fehler-event-55Das Erstellen eines oder mehrere Snapshots, zum Beispiel durch Backupsoftware (Veeam, R2Data, Tivoli …) erzeugt Fehler und Warnungen im Eventlog des Windows-Servers:

  • ID 50 NTFS Warning, delayed write failed / delayed write lost
  • ID 55 NTFS Fehler, In der Dateisystemstruktur wurde eine Fehler erkannt
  • ID 57 NTFS Warning, failed to flush data to the transaction log. Courruption may occur.
  • ID 137, NTFS Error, The default transaction resource manager on volume [] encountered a non-retryable error
  • ID 140, NTFS Warning, failed to flush data to the transaction log. Courruption may occur in VolumeID:
  • ID 12289 VSS Error, Volume Shadow Copy Service error: Unexpected error DeviceIOControl

Je nach Umstand können sogar echte Daten verloren gehen (unter Umständen sogar eine korrupte Datenbank). Die vmware-Version (vSphere 4/5/6, vRealize …) ist dabei irrelevant.

Lösung

Der Fehler liegt eigentlich am Windows Server und ist Microsoft bekannt (http://kb.vmware.com/kb/20068499). Eine Hotfix-Lösung gibt es leider (noch) nicht, aber bevor man mit defekten Daten hantiert und diese am Ende noch kaputt sichert, sollte man bei den betroffenen Systemen auf die quiescence verzichten:

  • Config-Datei für die vmware Tools bearbeiten (oder erstellen, wenn nicht vorhanden) 
    C:\ProgramData\VMware\VMware Tools\Tools.conf
  • Diese Zeilen einfügen: 
    [vmbackup]
vss.disableAppQuiescing = true
  • Dann den vmware Tools-Dienst neu starten

Und schon laufen externe Snapshots ohne Quiescence auf diesem System. Hoffentlich wird das bald gefixt …

CUPS meldet „Bad Request“ bei SSL auf IP/FQDN

Veröffentlicht am von — Keine Kommentare ↓

Problem

Bei der Installation von CUPS (hier: 1.5.3) auf Debian gibt es ein unangenehmes Phänomen bei der Verwendung von ganzen Host- oder Domainnamen. Das CUPS-Webfrontend setzt standartmäßig bei einigen Operationen (Drucker ändern, Drucker löschen und so weiter) voraus, das die Seite via SSL geöffnet wird. Dazu wird auch ein Redirect-Link angezeigt. Klick man diesen, erscheint:

Bad Request

Passiert der Aufruf nicht über den im Zertifikat angegebenen CN, werfen erstens die großen Browser alle eine ’sec_error_untrusted_issuer‘ Meldung und zweitens das CUPS einen „Bad Request„. Dieser HTTP-Fehler 400 verwirrt, denn in der CUPS config ist der port korrekt eingetragen. Die Standardmäßige Wahl der Konfigurationsparameter ist hier etwas ungeschickt.

Lösung

Über die IP-Adresse (192.168.x.y:631) geht das Webfrontend auf, es sei denn das Zertifikat ist falsch. Der schnelle Admin erlaubt einfach alle eingehenden Anfragen.

  1. Korrektes, passendes Zertifikat für CUPS hinterlegen 
    openssl req -new -x509 -keyout /etc/cups/ssl/server.key -out /etc/cups/ssl/server.crt -days 3650 -nodes

    (Hier dann dem Assistenten folgen, wichtig ist wie immer der „Common Name“ (CN))

  2. Konfigurationsdatei /etc/cups/cupsd.conf anpassen: 
    ServerAlias *
  3. Neustart der CUPS-Dienste 
    /etc/init.d/cups restart

Langes Passwort

Veröffentlicht am von — Keine Kommentare ↓

Anruf von einem IT-Lieferanten (Zeiterfassung) eines Kunden:

Sicherheit ist ja sicher sehr wichtig, aber DAS HIER ist total übertrieben. So können wir nicht arbeiten, sorgen Sie SOFORT für einen EINFACHEN Zugang.

wtf? Was haben wir falsch gemacht?

pem-public-key-fileStellt sich raus: Der zuständige Techniker des Lieferanten hat die Anleitung zum VPN nicht wirklich gelesen. Er hatte zwar die VPN-Verbindung (soweit korrekt) eingerichtet, aber anstatt des Kennwortes (das per Telefon übermittelt wurde), verwendete er das Zertifikat.

Den kompletten Text zwischen „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ aus der E-Mail gesendeten PEM-File. Er hat das ofenbar abgetippt. MEHRFACH. Nunja, bei einem x509-Zertifikat kommen da schon ein paar Zeichen zusammen … *kopfschüttel*

Liste autorisierter DHCP-Server aufräumen geht nicht „Ein solches Objekt ist auf dem Server nicht vorhanden“

Veröffentlicht am von — Keine Kommentare ↓

Problem

dhcp-server-autorisation-aufhebenIn der Liste autorisierter DHCP-Server einer Windows-Domäne finden sich Altsysteme oder umbenannte Server die nun entfernt werden sollen. Der Klick in der DHCP-Verwaltungskonsole auf dne Server und dann „aufheben“ erzeugt aber nur die Fehlermeldung „Ein solches Objekt ist auf dem Server nicht vorhanden„.

Der gleiche Fehler tritt auch – je nach Sprache mit etwas anderer Fehlermeldung – auch an der NetSH und an der Powershell auf:

C:\> netsh delete server xxx.xxx.xxx y.y.y.y
Ein solches Objekt ist auf dem Server nicht vorhanden

Lösung

 

    1. Das Snap-In Active Directory-Standorte und-Dienste öffnen
    2. Klicken auf Dienste, und dann auf den Knoten NetServices (Wenn „Dienste“ in der Baumstruktur noch nicht angezeigt werden, muss man im Menü „Ansicht“ auf Dienstknoten anzeigen klicken)
    3. In der rechten Hälfte sind hier die meisten autorisierten DHCP-Serveraufgeführt. Den betroffenen Server hier einfach entfernen.
    4. Wenn der betroffene Servername nicht aufgeführt ist, mit der Rechten Maustaste auf den Eintrag „DhcpRoot“ klicken und die Eigenschaften öffnen (nicht entfernen!)

dhcp-server-aus-ad-entfernen

  1. Auf dem Tab „Attribut-Editor“ den Eintrag „dhcpservers“ auswählen und bearbeiten
  2. Die falschen Einträge entfernen
  3. DHCP-Dienst(e) neu starten, fertig.

 

Wo kann ich das HPONCFG herunterladen?

Veröffentlicht am von — Keine Kommentare ↓

HPONCFG für Windows x64 (7 bis 10, auch Server) kann man direkt hier herunterladen: hponcfg_x64.msi

Da HP solche wichtigen Downloads gerne versteckt oder hinter eine Paywall versteckt, gibt es hier einen lokalen Mirror. Mit HPONCFG kann man die IP-Adresse des laufenden ILO-System herausfinden, das Passwort zurücksetzen und die ganze Konfiguration bearbeiten.