Baremetal Backup schlägt hin und wieder fehl bei früherem Printserver

Bei einem Kunden konnte ich folgendes beobachten in einem DPM Server 2012R2 Umfeld:

Bei einigen Servern liessen sich nach einiger Zeit keine Baremetal Recovery Points mehr erstellen. Logfiles zeigen dass RAPreBackup mit einem Error aussteigt und das ohne ersichtlichen Grund, der auf DPM zurück zu führen ist:
0x80990ED0

Wenn die Server rebooted werden, dann lassen sich wieder Recovery Points mit DPM erstellen. Einige Tage später ist der Fehler wieder da, ohne dass es irgendwelche Änderungen gab. Nach einigem hin und her stellte sich heraus, dass alle Server entweder Printserver oder ehemalige Printserver waren.

Also warteten wir bis der Fehler wieder da war. Dann stoppten wir den Print Spooler und versuchten erneut einen Recovery Point zu erstellen. Dieser funktionierte einwandfrei.

Es stellte sich heraus, dass auf den ehemaligen Printservern noch einige HP Dienste zurückgeblieben sind, obwohl die Druckertreiber deinstalliert wurden. Es handelt sich hierbei um den Dienst PML Driver HPZ12 und Net Driver HPZ12.

Wenn man statt des Print Spoolers diese zwei Dienste anhält, dann funktioniert das Baremetal Backup ebenfalls. Also deaktivierten wir die Dienste auf den ehemaligen Printservern.

Auf dem Server der nach wie vor als Printserver agiert, konnte wir diesen Workaround natürlich nicht durchführen. Stattdessen halten wir via PreBackup Skript den Print Spooler an und starten ihn wieder wenn Windows Server Backup fertig ist.

SystemState & BMR Recovery Points lassen sich nicht mehr erstellen nach Installation von KB2919355 auf einem Domaincontroller mit Windows Server 2012R2

Ich hatte die Tage zu kämpfen mit der Installation bei einem Kunden.

Eingesetzt wird DPM 2012 R2 UR2. Gesichert werden damit diverse physikalische Server und diverse Hyper-V VMs. Nach einem Patch-Day und der Installation von KB2919355 konnten von zwei Server das System nicht mehr gesichert werden – System State & Baremetal. Der eine, ein physikalischer Windows Server 2012R2 und der andere, eine Hyper-V VM unter Windows Server 2012R2. Alle anderen Server (gemischt physik und hyper-v) auch mit Windows Server 2012R2 liessen sich einwandfrei sichern. Der einzige Unterschied war hier die Rolle Domain-Controller.

DPM steigt beim Erstellen eines Recovery Points mit dem Fehler 0x80990ED0 aus. Ein lokales Backup hingegen mit Windows Server Backup funktionierte einwandfrei.

Diverse Anläufe mit den gängigen Lösungsansätzen schlugen leider fehl.

Erst eine Deinstallation von KB2919355 löste das Problem.
Nachdem UR2 ja von Microsoft zurückgezogen wurde, kann ich nicht ausschließen dass es an UR2 in Kombination mit KB2919355 liegt.

Falls also jemand da draussen von euch über das gleiche Problem stolpert, schaut mal nach den installierten Updates auf dem protected server.

Ich werde den Blogeintrag aktualisieren wenn ich mehr über die eigentlichen Ursachen in Erfahrung gebracht habe.

Error 0x800423f3 – VSS Event ID 8204 bei der Bare Metal Sicherung eines (DPM) Servers

Lange Zeit hatten wir unsere beiden DPM Server bei einem Kunden mit dem Windows Server Backup per Scheduled Task auf ein Netzwerkpfad täglich gesichert.

Später sind wir dann zur „Microsoft-Supporteten“ Variante übergegangen und haben einen dedizierten Secondary DPM Server für alle DPM Server im Unternehmen aufgebaut.

Doch auch hier verwendet ja DPM Selbst das Windows Server Backup zum Sichern des Servers.

Leider ist nun seit einiger Zeit der Error: Error 0x800423f3 -mit der VSS Event ID 8204 aufgetaucht bei dem Versuch den Server zu sichern. Weder per Scheduled Task noch per DPM oder per Kommandozeile ist eine Bare Metal Sicherung mehr möglich.

Der VSS Writer gibt den folgenden Fehler aus:
Volume Shadow Copy Service error: An invalid XML document was returned from writer {27d4ecb3-4359-4305-8e44-7d1b7bc83780}.

Nach langer Suche bin ich auf ein KB von Microsoft gestossen was den Fehler sehr gut beschreibt.
http://support.microsoft.com/kb/983425
Es geht darum, dass der VSS Reader/Writer ein Limit an Mountpoints verarbeiten kann. Da jedoch der DPM Server selbst für jede Protection Group bzw. Protected Server (und natürlich bei einer Disk Reallocation) einen neuen Mount Point erstellt, es sehr schnell zu vielen Mount Points kommt, tritt dieser Fehler früher oder Später bei „großen“ DPM Servern auf. In unserem Falle haben die beiden DPM Server jeweils 50 – 80 Client Server in der Sicherung mit einem Storage von jeweils 60TB.

Leider ist hier die Aussage von Microsoft sehr klar:
Eine Lösung für Windows Server 2008 gibt es im oben genannten KB doch leider keinen „direkten“ fix von MS für >2008R2 Servern. Ein DCR (Design Change Request) wurde von der Produktgruppe bei MS abgelehnt. Der einzige Workaround hier ist ein Scalae-Out –> Aufsetzen eines weitern DPM Server und Protected Clients/Server übertragen…

An dieser Stelle hinterlässt das Produkt leider keinen guten Eindruck für eine Enterprise Lösung. . .