Wenn man jetzt die Infos über die nicht mehr vorhandenen Sicherungen löschen will, um eine saubere “Statistik” zu haben, kann man sich eines PowerShell-Cmdlets bedienen: Remove-WBBackupSet.

Der Aufruf dazu sieht so aus:

Remove-WBBackupSet –MachineName SERVERNAME -KeepVersions 4

Der Parameter –KeepVersions gibg dabei an, wieviele der letzten Sicherungen man behalten möchte. Alternativ kann man mit –DeleteOldest die X ältesten Sicherungen entfernen.

Bei dem Aufruf wird es aber sehr wahrscheinlich zu vielen Fehlern kommen, wie man im Screenshot sieht. Da die Sicherungen nicht mehr erreichbar sind, das Cmdlet aber eigentlich die Files dazu löschen würde, muss man sich hier zusätzlich des –Force Parameters bedienen:

Dabei wird die Tatsache, dass die Sicherungen auf der ausgefallenen Platte nicht mehr erreichbar sind, ignoriert und nur der Verweis auf diese Sicherungen entfernt.

Mit dem Aufruf Get-WBBackupSet kann man sich nochmal ausgeben lassen, wieviele Sicherungen Windows Server Backup “kennt”:

“Replikat inkonsistent” bzw. “Replica is inconsistent”

Das schaut dann in etwa so aus:

Was kann man nun also dagegen tun?

Zunächst einmal muss sichergestellt sein, dass die Dateien “ese.dll” und “eseutil.exe” vom Exchange Server auf den DPM Server kopiert wurden – und zwar immer in der auf dem Exchange aktuell verwendeten Version – also nach größeren Updates neu kopieren!

Die Dateien befinden sich im Exchange-Verzeichnis unter “Bin”, also z.B. unter “D:\Program files\Microsoft\Exchange Server\V15\Bin” und müssen in den Bin-Pfad vom DPM, also z.B. nach “D:\Program files\Microsoft System Center 2012 R2\DPM\DPM\bin” kopiert werden.

Nach Updates sollte unbedingt die Version bzw. das Dateidatum kontrolliert werden!

Weiterhin muss eine aktuelle Version des “Visual C++ Redistributable for 2012” auf dem Exchange Server installiert sein! Dieses lässt sich z.B. hier herunterladen: https://www.microsoft.com/de-de/download/details.aspx?id=30679 

Zur Sicherheit lässt sich auch eine Reparatur-Installation ausführen. Anschließend ist ein Reboot nötig.

Wenn diese Voraussetzungen geschaffen worden, dann kann entweder nur eine Konsistenzprüfung durchgeführt oder direkt die Sicherung fortgesetzt werden (was dann auch zunächst zu einer Konsistenzprüfung führt).

Wenn diese Abgeschlossen ist (was eine Weile dauern kann), sollte die Schutzgruppe wieder den Zustand “OK” (grün) annehmen.

(Leider hab ich vom Fehler selbst in der Produktiv-Umgebung keinen Screenshot gemacht und ich wollte ihn nicht nochmal nachträglich provozieren – daher ein Shot aus einer englischen Umgebung)

Dieses Problem ist scheinbar bei Microsoft bekannt und auch im TechNet dokumentiert:

https://technet.microsoft.com/de-de/library/dn281948.aspx

Die Lösung ist auch recht einfach, da der Grund ebenso einfach ist: Der Schutz-Agent hat keine SA-Rechte auf der Datenbank, also müssen diese noch vergeben werden!

Dazu startet man auf dem zu sichernden Zielserver einfach das “SQL Server Management Studio”:

Dort kann man dann in dem Bereich “Sicherheit”, unter “Anmeldungen” das Konto von “NT-AUTORITÄT\SYSTEM” mit einem Rechtklick und der Auswahl von “Eigenschaften” öffnen. Hier muss dann die Rolle “sysadmin” zusätzlich mit ausgewählt werden.

Danach sollte sich die Sicherung via DPM auch problemlos einrichten und durchführen lassen:

Bei einem Exchange Server 2007 mit LCR trat seit längerem das Problem auf, dass sich dieser nicht sauber (auf Anwendungsebene) sichern ließ. Die Windows Server Sicherung meldete immer

“Abgeschlossen mit Warnungen – Die Anwendung kann aus dieser Sicherung nicht wiederhergestellt werden […]”

Kurz nach Start der Sicherung findet sich im Ereignisprotokoll folgender Eintrag:

Anwendungsprotokoll / Ereignis 565 / Quelle Backup / “Fehler bei der Konsistenzprüfung für die Komponente […]”

Eine Überprüfung der Postfachdatenbank sowie der Datenbank für die öffentlichen Ordner und aller Logs mit Hilfe von ESEUtil brachte keinerlei Fehler oder sonstige Probleme.

Als Lösung des Problemes habe ich den Exchange VSS-Writer per Registry deaktiviert.

Dazu ist unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Replay\Parameters ein neuer DWORD-Schlüssel anzulegen, der den Namen “EnableVSSWriter” und den Wert 0 bekommt.

Danach funktioniert das nächtliche Backup wieder ohne Probleme: