Logo faq-o-matic.net
Logo faq-o-matic.net

Störrischer FSRM

von veröffentlicht am19. Januar 2008, 15:28 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: Dateisystem, Dokumentation, Tools, Troubleshooting, Windows Server 2003   Translate with Google Translate Translate EN   Die angezeigte Seite drucken
Zuletzt aktualisiert: 12. Mai 2011

Seit der Einführung von Windows Server 2003 R2 hat der Administrator endlich ein Werkzeug in der Hand, mit dem er sehr schnell und effektiv den Speicherplatzbedarf seiner Netzwerkbenutzer auf den Dateiservern analysieren kann. Durch das Erstellen von Speicherberichten kann der Administrator auf einen Blick erkennen, wie viel Speicherplatz ein Benutzer auf einem bestimmten Laufwerk in Anspruch nimmt. Zusätzlich können die Berichte auch noch eingeschränkt werden. Das heißt, man kann beispielsweise nach Duplikaten suchen oder auch nach Dateien die schon eine längere Zeit nicht mehr benutzt wurden.


Der Ressourcen-Manager für Dateiserver ist also ein rundum nützliches Werkzeug, das in die Werkzeugsammlung eines jeden Administrators gehört. Ein weiterer Vorteil ist die sehr einfache Einrichtung und Konfiguration des Ressourcen-Manager für Dateiserver.

Neulich bei einem Kunden kam das Problem auf, dass der Platz für die Datensicherung nicht mehr ausreichte. Leider kann man bei diesem Kunden nicht mit Kontingenten auf den Laufwerken arbeiten. Die Mitarbeiter nutzen hier sehr große Videodateien und andere Binärdaten, die auch recht schnell auf ein Gigabyte und mehr anwachsen können. Die einzelnen Laufwerke der Server sind mit mehreren Terabyte an Daten gefüllt. Was liegt also näher, als einfach mal einen Speicherreport zu erstellen. Ziel des Speicherberichtes war es, Duplikate dieser Video- und Binärdateien aufzuspüren und dann entsprechend zu löschen. Nach einer kurzen Diskussion hatte ich die Freigabe des dort angestellten Administrators und konnte den Ressourcen-Manager für Dateiserver installieren. Nach der Installation und einem anschließenden Neustart machte ich mich an die Erstellung des Berichtes, und von da an nahm das Unheil seinen Lauf.

Nachdem ich das Laufwerk mit dem größten Datenvolumen identifiziert hatte, wollte ich für dieses Laufwerk einen Speicherbericht erstellen. Nach dem Einrichten und dem Klicken auf „OK“ ereilte mich diese Fehlermeldung:
Fehler im FSRM

Für mich kam diese Fehlermeldung genauso unerwartet wie für den Server. OK, was also tun? Der erste Blick ging also in das Ereignisprotokoll, denn das wurde mir ja in der sehr ausführlichen Fehlermeldung vorgeschlagen. Das offenbarte mir dann Folgendes:

Ereignistyp: Fehler
Ereignisquelle: FSRM
Ereigniskategorie: Keine
Ereigniskennung: 0
Datum:  19.01.2008
Zeit:  11:03:27
Benutzer:  Nicht zutreffend
Computer: W2K3-SRV1
Beschreibung:
Unerwarteter Fehler beim MMC-Snap-In Ressourcen-Manager für Dateiserver
bei Microsoft.Storage.SrmMmc.ReportTask.SaveChanges(ISrmReportManager reportManager)
bei Microsoft.Storage.SrmMmc.StorageReportTaskPropertySheet.SaveChanges()
bei Microsoft.Storage.SrmMmc.PropertySheet.OnOkButtonClicked(Object sender, EventArgs eventArgs)
Ungültiges Argument: NamespaceRoots[0] = ‚E:\‘
bei Microsoft.Storage.SrmMmc.ISrmReport.put_NamespaceRoots(Object[] namespaceRoots)
bei Microsoft.Storage.SrmMmc.ReportTask.SaveChanges(ISrmReportManager reportManager)
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter
http://go.microsoft.com/fwlink/events.asp.

Super! Das Laufwerk „E:\“ ist also ein ungültiges Argument. Warum es ein „ungültiges Argument“ ist, bleibt aber offen. Der Eintrag im Ereignisprotokoll brachte mich also auch keinen Schritt weiter.

Da ging mir kurzzeitig folgendes durch den Kopf: Da steh ich nun, ich armer Tor!
Und bin so klug als wie zuvor. (J.W.v.Goethe / Faust I)

Also hieß es wieder „selbst ist der Administrator“. Im nächsten Schritt habe ich mir gedacht, wenn das System mir nicht das Problem verraten will, dann muss ich selbst suchen. Eine andere Alternative blieb mir auch nicht übrig. Für alle Phänomene, die mit dem Dateisystem auftreten, bietet sich als Werkzeug „Filemon“ an. Mit Filemon kann man alle Zugriffe auf das Dateisystem in Echtzeit verfolgen. Also habe ich die Zugriffe des Ressourcen-Manager für Dateiserver protokolliert. Das Ergebnis sah so aus:

Filemon

Aha, siehe da, ein „ACCESS DENIED“ für den Prozess „srmhost.exe“. Dieser Prozess ist der Dienst, unter dem der Ressourcen-Manager für Dateiserver läuft. Der Dienst selbst läuft unter dem Benutzerkonto „SYSTEM“. Warum kommt aber hier diese Fehlermeldung? Als Nächstes habe ich mir also die NTFS Berechtigung des Laufwerks angesehen und hier lag auch des Rätsels Lösung:

ntfs_geaendert.jpg
(Berechtigungen des Laufwerks)

ntfs_standard.jpg
(Standardberechtigungen eines NTFS Laufwerks nach der Formatierung)

Der Administrator vor Ort hatte die NTFS Berechtigungen des Laufwerks verändert und dem Benutzerkonto „SYSTEM“ die Zugriffsrechte auf das Laufwerk entzogen. Dadurch hat der Ressourcen-Manager für Dateiserver natürlich keinen Zugriff auf das Laufwerk.

Was mich an diesem Sachverhalt sehr ärgert, ist nicht das fehlende Benutzerkonto bzw. die fehlenden Berechtigungen, sondern die miserable Fehlerbehandlung innerhalb des Ressourcen-Manager für Dateiserver. Mit einer Fehlermeldung à la „Kein Zugriff auf das Laufwerk E:\“ hätte ich ca. vier Stunden eher im Feierabend sein können. Schade, dass an der Fehlermeldung nicht dieser Button existierte:

http://www.youtube.com/watch?v=1Q_EPUXlyME

Ich hätte nur zu gern davon Gebrauch gemacht …

© 2005-2019 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!