DPM 2012R2 Update Rollup 7 bringt Support für Windows 10

Heute erscheint das neue Client Betriebssystem Windows 10. Die Unterstützung dafür in DPM 2012R2 ist eines der wichtigen Neuigkeiten des Update Rollup 7. Auch neu ist die Unterstützung eines Restores aus der Azure Cloud auf einen anderen DPM Server.
Bisher konnte man einen Restore nur mit dem DPM Server machen, mit dem man auch das Backup in die Cloud gemacht hatte. Jetzt geht es auch mit einem anderen, solange dieser ebenfalls am gleichen Repository in der Cloud hängt.
Wer also mit mehreren DPMs in die Cloud sichert, braucht sich beim Restore jetzt keine Gedanken mehr machen von welchem der DPMs er jetzt einen Restore machen muss.

Einige der Probleme die mit dem Update Rollup 7 gefixt werden:

1. Backup von Hyper-V verbessert wenn eine Replica vorliegt. Bisher hatte man keinen Einfluss welche VM der DPM sichert, wenn man auch eine Replica hat und beide VMs vom gleichen VMM verwaltet werden. Das führte gelegentlich dazu, dass das Backup fehlschlug. Dies ändert sich mit diesem Update Rollup 7. Fortan wird immer die VM gesichert, die beim Anlegen der Protection Group ausgewählt wurde.

2. Gelegentliche Refreshprobleme beim Ändern von Protectionsgroup die einen Fileserver sichern sind behoben.

3. Im Recovery Tab zeigt DPM jetzt auch Cloud Restore Points an wenn man Show all Recovery Points anklickt.

4. End User Recovery Probleme mit gespiegelten Datenbanken wurden behoben.

5. Update Rollup konnte nicht installiert werden haben einige beim letzten UR als Meldung bekommen. Dies ist jetzt behoben.

6. Das Azure Portal hat einige Nomenklaturaeinschränkungen die bisher von DPM nicht validiert wurden. Das führte gelegentlich zu Fehlern. Jetzt werden diese von DPM validiert und aufgezeigt.

7. Jetzt kann man auch Datenbanken mit gleichem Namen sichern aus verschiedenen SQL Availability Groups.

8. DPM Alert Syncing funktioniert wieder einwandfrei.

9. System.TimeoutException Fehler wurde behoben. Dieser trat auf wenn man eine große Anzahl VMs in einer Protection Group gesichert hat und den VMM Helper Service aktiviert hat.

Wie immer empfehlen wir das Update Rollup erst mal zu testen, bevor man das auf eine größere Umgebung loslässt.

Den Download KB3065246 gibt es hier:
https://support.microsoft.com/en-us/kb/3065246

Update Rollup 4 für DPM 2012R2

Servus miteinand,

etwas über 3 Monate nach dem letzten Update Rollup ist das neue Update Rollup Nr. 4 für DPM 2012 R2 von Microsoft freigegeben worden.

Es fixt einige der Konsolenabstürze die ich in letzter Zeit immer mal wieder gesehen habe.

Zusätzlich führt es die Unterstützung für 2 wichtige SQL Upgrades ein. SQL Server 2012 SP2 wird jetzt unterstützt. Sowohl für die Sicherung als auch für die Nutzung als DPM Datenbankhost. Ebenso lässt sich jetzt auch SQL Server 2014 als Workload sichern. Aber Vorsicht: Bitte kein SQL 2014 als Datenbankhost für DPM benutzen.

Das Update Rollup kann via WSUS oder direkt hier heruntergeladen werden:
https://support.microsoft.com/kb/3009516

System Protection Backup schlägt fehl und im Eventviewer findet sich ein CAPI2 Fehler – Eventid 513

Manchmal muss man tief in den Eingeweiden von Windows wühlen um einen Backupfehler zu finden und zu lösen. Ein physikalischer Server ließ sich plötzlich nicht mehr sichern nach diversen Windows Updates. In den DPM Logs ließ sich kein Fehler finden. Allerdings loggte der Server bei jedem Backupversuch das Event 513 für CAPI2:

event513_CAPI2

Damit ließ sich schon mehr anfangen. CAPI2 ist die Crypto API die vom Cryptographic Services Dienst benutzt wird. Offensichtlich ein Permission Problem, dass durch ein Windows Update verursacht wurde. Der NETWORK_SERVICE darf hier nicht zugreifen. Das ist der Account mit dem der VSS System Writer versucht ein Backup zu machen.

Um das gerade zu biegen benötigen schauen wir uns mit Hilfe von sc sdshow MSLLDP die Permissions des Microsoft Link-Layer Discovery Protocols an. Parallel schauen wir uns mit sc sdshow MUP die funktionierenden Permissions an. Daraus kopieren wir den String für den NETWORK_Service und setzen ihn dann mit Hilfe sc sdset. Dabei kopieren wir aus dem vorhergehenden sdshow von MSLLDP alle Security Informationen und fügen den Code für den NETWORK_SERVICE hinzu (A;;CCLCSWLOCRRC;;;SU) und setzen ihn vor S: in dem String von MSLLDP.

Zusammengefasst sieht das dann so aus:

sc_sdshow_mslldp

Jetzt noch den Dienst neustarten mit net stop cryptsvc und net start cryptsvc und schon ist der Fehler behoben und es gibt keine CAPI2 Error Events mehr im Eventlog.

Lässt man nun einen Recovery Point in DPM erstellen, dann läuft dieser ohne Probleme durch.

Ich gehe davon aus, dass das ein Bug in einem der Windows Updates für Server 2012R2 ist, denn ein ungepatchter 2012R2 läuft nicht in dieses Problem. Auf der anderen Seite laufen auch nicht alle gepatchten 2012R2 in dieses Problem hinein. Ist vermutlich eine magische Kombination aus mehreren Faktoren die hier die Permissions durcheinander bringt.

 

DPM beschwert sich über fehlenden Speicherplatz beim Baremetal Backup – Shadow Copy

DPM beschwert sich immer mal wieder über fehlenden Speicherplatz. Sei es im Replica Volume, dem Recovery Point Volume oder auch mal direkt auf C: wenn man ein Baremetal Backup machen möchte.

Eine neue Fehlermeldung ist mir die letzten Wochen häufiger über den Weg gelaufen. DPM meldet:
There is not enough disk space to create the volume shadow copy

Wenn man sich C: anschaut ist meist mehr als genug Platz vorhanden. Diese Fehlermeldung kommt woanders her. Das merkt man ziemlich schnell, wenn man anstelle eines Baremetal Backups nur einen Recovery Point für System State in DPM erstellt. Dieser wird erfolgreich gemacht.

Im Baremetal Backup ist zusätzlich zum System State auch ein Backup der Recovery Partition. Wenn in dieser weniger als 50MB frei sind, dann schlägt das Backup fehl. Die Ursache ist dabei nicht beim DPM zu suchen, sondern beim VSS.

VSS benötigt bei Partitionen die kleiner sind als 500MB ein Minimum von 50MB frei um einen Snapshot (shadow copy) zu erstellen. Bei Partitionen die größer sind als 500MB liegt das Minimum bei 320MB.

Jetzt kann man natürlich hergehen und einfach die Partition vergrößern. In einem sehr kleinen Umfeld kann man das machen. Wenn man aber einige hundert Server hat möchte man die Konfiguration eher einheitlich belassen. Daher gibt es einen einfach Workaround. Man sagt dem VSS Writer, dass er für die Recovery Partition einfach das C: Laufwerk als Storage für die Shadow copy verwenden soll anstelle der direkten Partition.

Um das zu tun, benötigen wir die Laufwerks ID der Recovery Partition. Diese erhalten wir, wenn wir mountvol aufrufen:

mountvol

Die ID ohne Mount Point ist unsere Recovery Partition. Mit vssadmin können wir dem VSS Writer mitteilen, dass er C: benutzen soll für die Shadowcopy:

vssadmin add shadowstorage /for=VOLUMENAME /on=C: /MaxSize=500MB

vssadmin add shadowstorageDer nächste Recovery Point in DPM wird dann erfolgreich erstellt.

 

 

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.