Im Rahmen eines Projektes an dem ich mitarbeite, tauchten, bezüglich Sharepoint, diverse technologische Fragen, auf. Eine davon war, ob es mit Sharepoint Server die klassischen Fileserver überhaupt noch braucht.

Das Ende des klassischen Fileservers ist in diesem Zusammenhang auf den ersten Blick offensichtlich. Team- oder persönliche Shares auf klassischen Fileshares die für Office Dokumente oder andere kollaborative Dateien verwendet werden sind im Gegensatz zu modernen Lösungen wie etwa MOSS ineffizient. Sie sind schlecht zu durchsuchen, erlauben keinen einfachen Weg um über Extranet Zugänge darauf zuzugreifen und können meist auch schlecht in einen kollaborativen Kontext gesetzt werden. Wie etwa Dateien mit Präsenzinformationen des Besitzers. Eigentlich wäre es klar: Weg mit dem Fileservern. Aus Sicht des CWP WS Collaboration Teams ist der Fileserver aber noch nicht ganz aus der Mode.
Es gibt viele extrem nützliche Szenarien für intelligente Dateispeicherung auf Fileshares. Um diese Szenarien zu benennen müssen wir aber zwischen Dateispeicher und Filesharing unterscheiden. Das vom Enduser angewendete Filesharing über einen Fileshare kann gut durch Sharepoint Dokument Bibliotheken abgelöst werden. Um hier technisch eine Grundlage zu haben lohnt es sich diese beiden Methoden gegenüber zu stellen:

Tabelle 1: Vergleich zwischen File Server Datei und einer Sharepoint Server Datei

Sharepoint Technologie mit Transaction Level Loging und Speicher in relationalen Datenbanken erzeugt zusätzliche Daten. Dadurch ist es in den meisten Fällen billiger Dateien auf einem Fileshare zu speichern als in einem Sharepoint Portal. Das musst nicht heissen, dass damit der Benutzer besser bedient ist. Im Zusammenhang mit Sharepoint liegt meistens die Gewichtung auf dem kollaborativen Kontext des Speicherortes.

Nicht vergessen darf man bei dieser Betrachtung auch wie die Disks aufgebaut sind. Sharepoint Daten Drives werden in der Regel mit RAID 5 betrieben, während 0+1 für die Transaction Logs verwendet werden. Sharepoint speichert seine Daten in einem SQL Server Storage. Der Disk I/O für die Inhaltsdatenbank ist, verglichen mit einem Exchange Store, sehr klein. Mit Ausnahme der Search Database. Ebenso müssen bei der Berechnung der Kosten die unterschiedlichen Arten der Backupmethoden einberechnet werden. So hat doch das Backup von einem SQL Server gegenüber einem Fileserver Implikationen auf die Kosten des Backupprozesses.
Es gibt aber abgesehen von Office Dateien welche in den meisten Fällen in einem kollaborativen Kontext benutzt werden auch Dateien und Speicherszenarien welche auf jeden Fall mit einem klassischen Fileserver besser bedient sind. Dies sind unter anderem:

Software Distributionspakete wie etwa Office MSI Pakete. Sharepoint hat einen guten Mechanismus um grosse Dateien zu verschieben. Sharepoint arbeiten am Besten mit Dateien unter 50MB. Trotzdem kann man theoretisch Dateien bis 2GB in einer Sharepoint Bibliothek speichern.
Meine Dokumente Redirection. Viele Firmen speichern die Dateien welche die Benutzer hier ablegen auf einen Fileshare um sich das Backup der Clients zu sparen. Ob diese Redirection auf eine Sharepoint Bibliothek überhaupt geht können wir zum heutigen Zeitpunkt noch nicht sagen.
Datenbank Storages. Dateien wie etwa .mdb, .ldf, .ndf, .pst, .ost, usw. können nicht auf einem Sharepoint gespeichert werden. Sharepoint kann zwar Dateien aus Datenbanken via dem Business Data Catalog anzeigen und indexieren. Er kann aber keine Dateien selber hosten. Das heisst für die Migration von solchen bestehenden Dateien müssen wir auf jeden Fall Fileshares zur Verfügung stellen. In diesem Zusammenhang ist es wichtig zu wissen, das mit Access 2007 grundsätzlich die Möglichkeit besteht Dateien auf und von einem Sharepoint Server zu beziehen.
Grosse Audio und Video Dateien, CD und DVD Images. Diese Dateien können zwar prinzipiell (wenn nicht grösser als 2GB) auf einem Sharepoint gespeichert werden. Wenn diese als Dateien gebraucht werden könnte zwar einen gewissen kollaborativen Kontext geltend gemacht werden. Wenn sie aber nur zum Darstellen der effektiven Mediainhalten gedacht sind, gibt es bessere Wege wie etwa Windows Media Server, oder über Einbinden von Youtube usw..
Batch- Command Scripts und Executables. Standardmässig werden die meisten Executables und Scripts von Sharepoint blockiert. Basierend wie diese Dateien gestartet werden (Web UI oder WebDAV) funktionieren sie nicht.
Archive und Dumps. Da Fileshare Speicher billiger ist als Sharepoint Speicher ist die Frage nach dem Speicherort von solchen Dump-Dateien fast schon hinfällig.

Zusammenfassend lässt sich sagen: Der Speicherort für Dateien welche in einem kollaborativen Kontext stehen müssen werden am besten durch Sharepoint ersetzt. Alle anderen Dateien, speziell Datenbankdateien oder Programme und Skripte, verbleiben auf Fileservern.