Dokumentenmanagement und SharePoint 2010
avatar

In die nächsten Tagen und Wochen möchten wir mit einer Serie von Blog-Beiträgen einen kleinen Einblick in die nun deutlich erweiterten Möglichkeiten von SharePoint 2010 in Hinblick auf Dokumentenmanagement geben.

Seit der Version Microsoft Office SharePoint Server 2003 hat Microsoft die Funktionalitäten und technischen Grundlagen in Richtung eines Dokumenten Management System kontinuierlich erweitert, so dass es mittlerweile im Magic Quadrant von Gartner für ECM Systeme an der Spitze steht (siehe Gartner Report vom 16.11.2010 – Link) .

Auch aus Unternehmenssicht entsteht häufig der Wunsch, nachdem die Erzeugung von Inhalt und Dokumenten bereits durch SharePoint 2010 unterstützt wurde, dass die Aufbewahrung bzw. Ablage der Dokumenten nicht in einem separaten System mit anderer Benutzeroberfläche etc. erfolgt. Ein zusätzliches System bedeutet meistens auch zusätzlichen Aufwand hinsichtlich, Betrieb, Update, Schulung oder Schnittstellen. Dieses soll mit einem ganzheitlichen Ansatz vermieden werden.

In der Serie wollen wir unter anderem folgende Themen beleuchten:

  • Neue Software Begrenzungen von Microsoft in Hinblick auf Dokumenten Management (in diesem Beitrag weiter unten)
  • Die Document-ID
  • Dokumenten-Routing
  • In Place Records Management
  • Document Center vs. Records Center

Wir halten die Liste erst einmal bewusst kurz, werden sie aber bei Bedarf oder entsprechenden Anregungen erweitern, natürlich werden wir die neuen Blog-Einträge hier verlinken, also Zwischendurch einfach mal wieder vorbeischauen.

Der Erste Beitrag befasst sich mit den Software Begrenzungen im SharePoint bezogen auf das Dokumenten-Management:

Software Grenzen im SharePoint DMS Umfeld

Betrachtet man SharePoint als eine mögliche Plattform für ein Dokumenten-Management-System oder Archiv, so hat man es leicht mit sehr großen Dokumentenmengen und unter Umständen auch mit sehr großen Datenmengen zu tun. Hier wurden in der Vergangenheit von Microsoft Empfehlungen und technische Grenzen ausgegeben die einen sinnvollen Betrieb in Frage gestellt haben. Nach einer Aktualisierung des Dokuments „SharePoint Server 2010 capacity management: Software boundaries and limits“ sieht das nun etwas anders aus.

Die Grenz von 200 GB für eine Content DB wurde zum Teil etwas aufgehoben. Es wird zwar immer noch empfohlen eine maximale Größe von 200 GB nicht zu überschreiten, hierbei ist es nicht relevant, ob die BLOBS durch eine RBS-Lösung bereits aus der Datenbank extrahiert worden sind.

Dieses zielt jedoch weniger auf eine technische Grenze hin ab, sondern eher auf die Wartbarkeit und das Desaster Recovery. Grundsätzlich wird nun gesagt, dass eine maximale Inhaltsdatenbankgröße von 4 TB supported ist. Der Betreiber der SharePoint Farm sollte sich jedoch hier sehr genaue Vorstelllungen über das Datensicherungskonzept und den Betrieb des SQL Servers machen und entsprechende Tests durchführen. Des Weiteren sollte auch das darunterliegend Platten-Sub-System über ausreichende Leistungsreserven verfügen, um die Anforderungen so großer Inhaltsdatenbanken verarbeiten zu können. Microsoft gibt hierfür einen Richtwert von 0,25 IOPs pro GB bzw. 2 IOPs pro GB für den optimalen Betrieb an.

Für Archiv-Umgebungen wurde diese Grenze nochmals aufgeweicht. Hier gibt es seitens Microsoft keine Größenbeschränkungen der Inhaltsdatenbank. Hier gibt Microsoft jedoch an, das neben den Voraussetzungen hinsichtlich Datenbanksicherung und Platten-Subsystem, der Anteil der Dokumente die pro Monat aufgerufen werden sollte nicht größer als 5% der Gesamtmenge sein sollte. Weiterhin sollte der Anteil der Dokumente die bearbeitet werden nicht größer als 1% sein und keine Workflows, Benachrichtigungen, Link Fix-Ups oder Element-Berechtigungen auf den Dokumenten vorhanden sein dürfen.

Unabhängig von der Größe der Inhaltsdatenbank gibt es aber nach wie vor die Beschränkung, dass die maximale Anzahl an Datenbankeinträgen bei 60 Millionen liegt. Inhaltsdatenbanken mit mehr als 60 Millionen Einträgen wurden von Microsoft nicht getestet.

Da Archive meist viel Speicherplatz beanspruchen und diese Daten am besten auf „günstigerem“ Speicher vorgehalten werden sollten gibt hier Microsoft jedoch bei der Auslagerung der Dateien über ein RBS-Provider auf ein NAS die Zeitspanne von der Anfrage nach dem BLOB und dem Empfang des ersten Byte mit 20 Millisekunden an.

Bisher in der Serie erschienene Themen:

2 Gedanken zu “Dokumentenmanagement und SharePoint 2010
avatar

  1. Pingback: Der Scanner Shop - Beste Preise und alle Infos rund um Scanner

  2. Danke für diese Beiträge!

    Ich habe mich jetzt gefragt, wer die Datensatzdeklaration über die Konformitätsdetails der Dokumente wieder aufheben darf? Dürfen das nur Websitesammlungs-Admins?

Schreibe einen Kommentar