Dinge, welche den Alltag eines Sysadmins vereinfachen, sind immer willkommen. Insbesondere, wenn sie dazu noch gratis sind:

Lange erwartet ist es seit diesem Herbst verfügbar: das aktualisierte Backup Exec 2010 Management Pack für Microsoft System Center Operations Manager 2010 (SCOM). Anders als der Name vermuten lässt, können damit auch ältere Backup Exec Versionen (ab Version 11.0) pro-aktiv überwacht werden.

Das frei verfügbare Management Pack hat nicht den Umfang eines typischen Microsoft Management Packs mit den teilweise sehr detailierten Überwachungsparametern, macht aber anonsten genau was benötigt wird:

• Überwachung der Sicherungs-Server und -Aufträge
• Überwachung der Sicherungs-Agenten

Und dies gewohnt komfortabel und nahtlos integriert in der SCOM-Konsole:

Selbstverständlich bietet Symantec mit der Central Administration Server Option (CASO) eine eigenständige, umfangreichere (und kostenpflichtige) Erweiterung zur Verwaltung von Backup Exec Installationen.

Für bestehende SCOM-Installationen stellt das Backup Exec Management Pack jedoch eine willkommene Erweiterung - ohne dass der Sysadmin eine zusätzliche Management-Konsole im Auge behalten muss.

BackupExec 2010 meldet beim FullBackup eines Hyper-V-Hosts folgenden Fehler:

Sichern- \\SERVER.contoso.local\System?StateVSS-Snapshotwarnung. Datei c:\windows\system32\slanaccel.exe ist im Snapshot nicht vorhanden.

Die Datei gehört zum Hyper-V-Dienst "SAN/LAN Transfer Virtualization Accelerator" und ist in diesem Fall nicht mehr vorhanden. Der Dienst ist deaktiviert.

Um den Fehler zu beheben, muss der Dienst gelöscht werden. Dies wird mit folgendem Befehl ausgelöst:

SC delete slanaccel

Damit wird der Dienst als gelöscht markiert, was spätestens beim nächsten Neustart ausgeführt wird. Die Fehlermeldung in BackupExec verschwindet bereits vor dem Neustart.

Wenn Symantec Backup Exec ein Backup to Disk mit GRT-Technologie macht, können die alten Backup To Disk-Medien nicht gelöscht werden, es bleibt immer die Datei "ese.dll" übrig. Diese Datei wird durch den Prozess "WMIPRVSE.EXE" blockiert. Gemäss Symantec Document ID: 317211 muss der Dienst "Windows Management Instrumentation / Windows-Verwaltungsinstrumentation" beendet werden, damit die Dateien gelöscht werden können.

Um dies zu automatisieren, starte ich nun jeweils vor dem Backup folgende Befehle:

net stop MSExchangeMGMT
net stop winmgmt
net start winmgmt
net start MSExchangeMGMT

Nachdem diese Befehle verarbeitet sind, kann Backup Exec die alten Backup To Disk-Medien problemlos löschen.

Symantec Backup Exec kann die *.cch.*-Dateien des .NET-Frameworks nicht sichern. Diese Dateien müssen gemäss KB815168 nicht gesichert werden.

Diese Dateien heissen z.B. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\enterprisesec.config.cch.[zahlenkombination].[zahlenkombination]

Um diese Dateien möglichst effizient auszuschliessen, sind Platzhalter nötig, denn die Zahlenkombination ändert ständig. Untenstehend sind die notwendigen Ausschlüsse aufgelistet, meine Erfahrung zeigte, dass dies pro BackupExec-Version anders ist.

Symptom: Symantec BackupExec 12.5 führt von einem Tag zum anderen keine Utility Jobs, also Inventarisierung, Löschen von Medien etc aus. Die Aufträge bleiben ewig in der Warteschlange mit Status 'Queued'. Sicherungs- und Wiederherstellungsaufträge werden normal ausgeführt. Alle Patches von Symantec sind installiert. Dienste, Server und Bandgerät, ein HP LTO4 Bandwechselgerät, wurden im Laufe des Troubleshooting mehrfach neu gestartet.

Das Durcharbeiten der Symantec Knowledge Base führte schlussendlich durch einen Hinweis 'im Kleingedruckten' des Artikels 308627 zur Lösung:

"The above mentioned problem can occur if for some reason the Backup Exec database has the ServerStatus flag set to indicate that the server is "Paused" but the Backup Exec console is unable to display that status in the Backup Exec User Interface"

Offensichtlich kann die BE Datenbank "for some reasen" inkonsistent gegenüber der Anzeige im GUI sein - mit dem Wissen, dass der Server 'angehalten' ist, ohne dass der Status GUI entsprechend angezeigt wird, ist das Problem nun schnell gelöst: Server anhalten und gleich wieder starten - und die Aufträge werden wieder ausgeführt!

Bleibt zu hoffen, dass Symantec uns zukünftig mit weniger versteckten Ostereiern beglückt...