Einrichtung Backup SharePoint 2013 mit NetWorker 18.2

Da ich kürzlich einmal wieder das ‘Vergnügen’ hatte, Backup für eine SharePoint 2013 Farm einzurichten, habe ich dieses Mal ein paar Notizen entsprechend aufbereitet, um sie veröffentlichen zu können.
Der NetWorker Module for Microsoft Guide für SharePoint verschweigt leider die Hälfte der Einrichtung… Und auch der Einrichtungs-Wizard in der NMC könnte durchaus einen besseren Job machen.
Die NetWorker & NMM Installation ist recht einfach. Möchte man Single Item Restores haben, muss man bei der NMM Installation natürlich noch SharePoint GLR aktivieren. Dann wird das Tool ItemPoint mit installiert.
Vor oder nach der NMM Installation sollte man jedoch noch die SetupACTS.exe Datei aus dem NMM Bundle starten und installieren. Vom Prinzip her kann man darauf zwar verzichten, jedoch führt ACTS zu komfortableren Restores.
Der “ItemPoint Agent for Content Transfer Service for SharePoint Server granular level recover” (ACTS) bildet die Schnittstelle zwischen dem NetWorker User for Microsoft und ItemPoint. Installiert man ACTS nicht, kann man im NetWorker User zwar auf “Mount Backup & Run ItemPoint” klicken, wird dann aber mit der Fehlermeldung “object reference not set to an instance of an object” abgespeist. Zu der Fehlermeldung findet man leider keinerlei Hinweise in der Dokumentation, sodass man anhand dessen nicht weiß, dass man ACTS vergessen hat. Das Backup wird zwar trotzdem gemountet, ItemPoint muss jedoch manuell geöffnet werden und auch die gemountete Datenbank + Logs muss man selbst auswählen. Mit ACTS wird ItemPoint direkt gestartet und die Datenbank+Logs auch direkt ausgewählt.
Daher die klare Empfehlung: ACTS auf allen Servern installieren, die man für Single Item Restores nutzen möchte!

Bei früheren NetWorker Versionen (NetWorker 8) funktionierte das SharePoint-Backup noch anders. Damals hat man jeden SharePoint-Server einzeln ins Backup aufgenommen. Das war einerseits natürlich unkomfortabler, andererseits aber auch unkomplizierter und Failover-fähig. Seit NetWorker 9 sucht man sich einen WFE aus, über welchen dann die Backups aller anderen Server und Komponenten durchgeführt werden. Hat man zwei WFEs und der WFE, den man eingerichtet hat, fällt aus, steht man leider dumm da, außer man hat den anderen WFE auch komplett fürs Backup eingerichtet und schaltet dann das Backup für diesen scharf. Da man bei NetWorker 8 jede Komponente einzeln gesichert hat, ist da nur das Backup für den ausgefallenen WFE fehlgeschlagen, aber alle anderen Komponenten wurden gesichert.
In der NetWorker Dokumentation wird zudem immer geschrieben, dass man einen WFE nutzen KANN. Ich habe dort nicht gelesen, dass man einen WFE nutzen MUSS. Allerdings beziehen sich sämtliche Erklärungen ausschließlich darauf, das Backup über einen WFE geschehen zu lassen. Vielleicht geht es auch noch wie früher, aber beschrieben wird es nicht mehr und ist daher auch nicht mehr wirklich so gewünscht.

Die Dokumentation sollte man dennoch genauestens lesen und befolgen. Daher werde ich hier nicht auf die Dinge tiefer eingehen, die bereits in der Dokumentation beschrieben sind.

So, genug der einleitenden Worte.
Hier eine kurze Beschreibung meiner Umgebung. Ich nenne die Namen der Server & Benutzerkonten nur nach ihrer Funktion.
Diese besteht auf fünf Servern und ich habe drei verschiedene Benutzerkonten.
Server:
WFE
Application (APP)
SharePoint Search (SEARCH)
Datenbank (MSSQL)
Office (für das SharePoint Backup nicht relevant, daher muss hier auch nichts installiert oder konfiguriert werden)

Und folgende drei Benutzerkonten, bei denen es sich um Domänen-Accounts handelt:
admin
backup
search

Im ersten Schritt installiert man den NetWorker Client und das NMM auf allen Servern außer dem Office-Server.
Auf den Servern, auf denen man Single Item Restores durchführen möchte, wählt man noch das jeweilige Granular Level Recovery (GLR) Feature. Also z.B. auf dem WFE GLR für SharePoint und auf dem MSSQL-Server GLR für MSSQL.
Durch die GLR-Features ist aber auf jeden Fall ein Reboot des Servers fällig. Nach der NMM-Installation wird man darauf hingewiesen. Den kann man jetzt durchführen, aber da die Server eh noch für eine andere Sache einen Reboot brauchen, kann man den Reboot auch später durchführen. Ansonsten muss man 2x rebooten.

In der NMM Dokumentation werden nun eine ganze Menge Berechtigungen beschrieben, die die entsprechenden User benötigen. Dort wird ebenfalls beschrieben, dass man den SharePoint VSS Writer anpassen muss, sodass dieser nicht mit dem SYSTEM-Account laufen.
Ebenfalls steht dort, dass der SharePoint VSS Writer für das Backup laufen muss.
Als Tipp dazu: Den Start von Manual auf Automatic stellen. Ansonsten müsste man die nach jedem Reboot wieder manuell starten.

Hat man die Berechtigungen vergeben, kann man nun auch schon das Backup im NetWorker einzurichten.
Im NetWorker empfiehlt sich dazu der “New Client Wizard”. Der ist zwar nicht perfekt, aber legt zumindest schonmal einen soliden Grundstein an. In der Dokomentation von Dell EMC wird dieser Teil beschrieben, daher gehe ich hier nicht darauf ein.
In der NMC sollte man nun den “Diagnostic Mode” im Menü View anschalten, da man ansonsten ggf. einige Optionen nicht sieht.
In der Client Ressource des gerade angelegten WFE wechselt man nun nach “Globals (2 of 2)”. Im Punkt “Remote Access” dürften bereits einige Einträge mit “SYSTEM@…” stehen.
Bei mir haben dort jedoch noch die Einträge für den Backup-User gefehlt, da wir diesen ja für Backups verwenden. Warum der Wizard das nicht auch direkt mitmacht, ist mir schleierhaft…
D.h. folgende drei Zeilen musste ich noch hinzufügen:
backup-user@Application-Server (APP)
backup-user@SharePoint Search-Server (SEARCH)
backup-user@Datenbank-Server (MSSQL)

Nun muss man noch in der NMC in den Server-Tab wechseln und dort zu “User Groups”.
Hier findet man die “Application Administrators”-Gruppe. Dort muss man bei Users “backup-user@Datenbank-Server (MSSQL)” hinzufügen. Leider wird auch dieser Schritt weder vom Wizard gemacht, noch in der Dokumentation erwähnt… Dieser Schritt ist jedoch nur nötig, wenn man GLR nutzen möchte, was aber wohl die meisten haben möchten.
Wenn man dies nicht macht, funktioniert das Backup zwar, aber auf dem SQL-Server sieht man im nsrnmmsv Log “unable to add offset”-Fehlermeldungen, welche zur Folge haben, dass er wohl benötigte Informationen für GLR nicht setzen kann und daher GLR auch nicht funktioniert.

Nun kann man mal ein Backup starten und schauen, ob es funktioniert. Ist das der Fall, sollte man trotzdem einmal die Application Event Logs auf den einzelnen Servern sowie die nsrnmmsv Logs durchforsten und nach Fehlermeldungen schauen.
Sieht man dort nichts, muss man die Server noch einmal rebooten (haben wir ja vorher nicht gemacht) und ist an dieser Stelle fertig.
In meinem Fall war das leider nicht so.
Das Backup hat nicht funktioniert und im Event Log waren diverse Fehlermeldungen sichtbar.
Sehr beliebt ist der Fehler 513 mit Quelle CAPI2.
Zu diesem Fehler gibt es bereits zwei ältere Blog-Beiträge bei uns: Hier & Hier

Dann hatte ich noch den Fehler, dass der VSS System Writer (Administrator-Kommandozeile -> vssadmin list writers) nicht sichtbar war. Der wird auch für Backup verwendet.
Das Problem war, dass auf dem SharePoint WFE auch Microsoft Visual Studio installiert war. Visual Studio installiert Microsoft .net und .net legt ein Verzeichnis mit mehr als 1000 Unterverzeichnissen an. Das hat zur Folge, dass der VSS System Writer nicht startet.
Lösung ist ein Windows-Bugfix von Microsoft. Auch das Thema haben wir in einem älteren Blog-Eintrag behandelt.
Zudem waren von der Quelle VSS noch die Fehler 8213 und 8194 sichtbar.

Für 8213 muss man den Registrierungseditor (regedit) öffnen und in folgenden Eintrag wechseln: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl

Dort musste ich den Backup-User hinzufügen. Format: Domäne\User
Im Ereignis im Windows Event Log wird der genaue User angezeigt, wenn man in die Detail-Ansicht wechselt und sich durch das ganze Event scrollt.
Nachdem man den Eintrag angelegt hat, gibt man ihm den Wert 1.
Dieser Thread war hier sehr hilfreich bei der Entstörung.

Für 8194 muss man die Windows Komponentendienste-Ansicht (Component Services) öffnen. Start -> Ausführungen -> comexp.msc
Dort wechselt man zu Komponentendienste -> Computer -> Arbeitsplatz (Englisch: Component Services -> Computers -> My Computer)
Rechtsklick auf Arbeitsplatz/My Computer -> Eigenschaften/Properties
Dort wechselt man in den Reiter COM-Sicherheit/COM Security
Im oberen Teil (Zugriffsberechtigungen/Access Permissions) klickt man auf Standard Bearbeiten/Edit Default.
Dort habe ich den Benutzer “NETWORK SERVICE” mit Berechtigung Lokaler Zugriff / Local Access hinzugefügt.
Und an der gleichen Stelle wie beim Fehler 8213 habe ich den NT AUTHORITY\NETWORK SERVICE hinzufügt.
Auch hier war das Internet sehr hilfreich, vor allem diese beiden Webseiten: Hier und Hier

Die Änderungen an den Komponentendiensten benötigen einen Reboot. Damit sollten jetzt alle nötigen Schritte unternommen worden sein. Ein letzter Reboot und nun sollten Backup & Restore funktionieren.