Frisch zurück von der Microsoft SharePoint Conference 2012 in Las Vegas ( ein Review dazu findet Ihr hier ) gibt es natürlich viele Eindrücke und Neuerungen der SharePoint 2013 Plattform, über die zu berichten es sich lohnt. Für mich eine der besten Neuerungen ist, wie das Benutzerprofil, die Social Features und die Suche verbunden wurden, um Collaboration und Document Management zu verbessern.
Bisher Stand man bei dem Design einer Collaboration und Document Management Lösung auf Basis von SharePoint immer vor einem Kompromiss, den man abwägen musste. Zum einem möchte man dem Anwender ein einheitliches Cockpit an die Hand geben, in dem er seine relevanten Dokumente und relevanten Aufgaben finden kann, ohne dass er sich durch Seitenverzeichnisse klicken oder die richtigen Suchanfragen ausführen muss. Der Gedanke an ein großes Dokumentenarchiv und eine einheitliche Aufgabenliste widerspricht allerdings mit benötigten Skalierbarkeit auf einzelne Webseiten, die das Berechtigungskonzept oder der Projektmanager bisher gefordert haben. Also wurde entweder ein Kompromiss gefunden oder ein Cockpit in Form von Eigenentwicklung umgesetzt. In SharePoint 2013 werden die einzelnen Features zu einer nennenswerten Lösung "Out of the Box" zusammengefügt und erfüllen verschiedene Anforderungen, die im Collaboration- und Document Management Umfeld immer wieder gestellt werden.
Dokumentenverwaltung über Bibliotheksgrenzen hinweg wird durch die Social Features "Share" und "Follow" verbessert. Oftmals möchte der Anwender sich aus den verschiedenen Dokumentenablagen die für Ihn wichtigsten Dokumente als Favorit markieren oder mit anderen teilen.
Alle Dokumente, denen man folgt, werden an einer zentralen Stelle im Profil angezeigt und können so schnell wiedergefunden und zugegriffen werden. Diese Dokumente findet man übrigens in der "Skydrive" genannten Dokumentenablage, die jedem Benutzer zur Verfügung steht.
Wie man sieht, bekommt der Anwender unter "Suggested documents to follow" Vorschläge für weitere interessante Dokumente. Dieses Feature kann durch die erfolgreiche Integration der FAST Search in die SharePoint Plattform bereit gestellt werden.
Neben dieser zentralen Ansicht auf alle für den Anwender relevanten Dokumente und den Vorschlägen wurde auch eine zentrale Aufgabenliste eingeführt.
Diese Aufgabenliste steht jedem Anwender auf seinem Profil zur Verfügung und stellt übersichtlich alle Aufgaben aus SharePoint dar, egal aus welcher Seite die Aufgaben stammen. Die Liste wird seitenübergreifend erstellt und gibt so dem Anwender die beste Möglichkeit, sich einen Überblick über alle ToDo`s zu verschaffen.
Damit der Anwender die Aufgaben an gewohnter Stelle findet und auch offline zur Verfügung hat, kann die gesamte Aufgabenliste aus dem Profil nach Exchange 2013 und somit nach Outlook synchronisiert werden. Hier ist ebenfalls die Ansicht aller Aufgaben möglich oder getrennt nach der SharePoint- Seite, von der die Aufgabe stammt.
Auch wenn diese Neuerungen auf den ersten Blick simpel erscheinen, sollte man ihren Nutzen nicht unterschätzen. Schon immer wurden genau diese Feature von Anwendern für die SharePoint Plattform gewünscht und entsprechend viel wird die Effizient steigen, mit der man Collaboration und Document Management Lösungen auf Basis von SharePoint 2013 umsetzen kann.
Beste Grüße,
Andreas
Sonntag, 18. November 2012
Mittwoch, 14. November 2012
Mirosoft SharePoint Conference 2012 - share more do more
Unter dem Motto "share more do more" findet vom 12. bis 15. November 2012 die Microsoft SharePoint Conference in Las Vegas statt. Der bevorstehende Release von SharePoint 2013 lässt auf spannende Neuigkeiten hoffen. Ich darf bei diesem Event in diesem Jahr dabei sein und schreibe meine Erfahrungsberichte auf dem Sharebär365 Blog:
http://sharebaer365.blogspot.com/search/label/SPC12
http://sharebaer365.blogspot.com/search/label/SPC12
Mittwoch, 15. August 2012
SharePoint Pages - Best Practices
SharePoint Server in der Standard Edition wird durch die Veröffentlichungsinfrastruktur ( engl.: "Publishing Infrastructure" ) zu einem ausgewachsenem Redaktionssystem und eignen sich ideal zur Abbildung von Intranet, Extranet und Internet. Ein Redaktionssystem zeichnet sich unter anderem durch die Trennung von Layout und Inhalt aus. Oftmals existiert bereits ein Style Catalog, der Bildgrößen, Tabellenformat, Schritfart, Schriftgröße und alle anderen Designvorgaben des Unternehmens beschreibt und der für das SharePoint System implementiert werden muss.
In SharePoint werden Webinhalte als "Pages" angelegt, der Aufbau und der Style einer solchen Page wird im so genannten "Page Layout" festgelegt. Beim Implementieren eines Redaktionssystems ist die Konfiguration der verschiedenen Page Layouts Bestandteil des Brandings. Das Erstellen neuer Page Layouts wird bereits in vielen Artikeln behandelt und soll an dieser Stelle nicht noch einmal aufgegriffen werden. Wer sich zum ersten Mal mit dem Thema beschäftigt wird feststellen, dass es sicherlich viele Details gibt, die es im Page Layout zu beachten und umzusetzen gilt. Einige dieser Details habe ich in den vergangenen Projekten kennenlernen dürfen und möchte sie mit euch teilen.
Der Inhaltsbereich einer SharePoint Seite wird durch das Page Layout formatiert. Das Branding der Webseite mit Navigationsleisten, Logo, Ribbon und Kopfbereich wird in der Masterpage umgesetzt.
Der Inhalte einer Page ist in den meisten Fällen ein Rich Text Feld mit einem Editor zum Formatieren des Textes. Der Editor bietet auch Format- und Markup-Vorlagen für Überschriften, Titel und Standardtexte.
Diese Formatvorlagen und auch die Markupformatvorlagen müssen dem Style Katalog entsprechend eingerichtet werden. Wie das funktioniert ist hier Custom Styles for SharePoint 2010 Rich Html Field sehr gut beschrieben worden.
Unser Firmenname "Data One" soll natürlich nicht als Rechtschreibfehler markiert werden. Durch das Erweitern des Wörterbuchs kann man das verhindern. Das ganze ist zwar etwas umständlich, aber wie es möglich wird kann man hier sehr Adding Custom Spellings in SharePoint gut nachvollziehen.
Die einzelnen Funktionen des Rich Text Feld können jedoch deaktiviert werden. Was man alles deaktivieren kann, ist bei MSDN dokumentiert, wie es geht kann man hier nachlesen ( der Artikel ist zwar für SharePoint 2007, funktioniert aber auch in SharePoint 2010 ).
Solltet Ihr noch weitere Tipps und Tricks zum Thema SharePoint Pages haben, freue ich mich über jeden Kommentar.
Good luck,
Andreas
In SharePoint werden Webinhalte als "Pages" angelegt, der Aufbau und der Style einer solchen Page wird im so genannten "Page Layout" festgelegt. Beim Implementieren eines Redaktionssystems ist die Konfiguration der verschiedenen Page Layouts Bestandteil des Brandings. Das Erstellen neuer Page Layouts wird bereits in vielen Artikeln behandelt und soll an dieser Stelle nicht noch einmal aufgegriffen werden. Wer sich zum ersten Mal mit dem Thema beschäftigt wird feststellen, dass es sicherlich viele Details gibt, die es im Page Layout zu beachten und umzusetzen gilt. Einige dieser Details habe ich in den vergangenen Projekten kennenlernen dürfen und möchte sie mit euch teilen.
Layout
Um die Layoutvorgaben umzusetzen muss man zuerst verstehen, welchen Teil des Layouts in welche Komponente von SharePoint umgesetzt wird.Der Inhaltsbereich einer SharePoint Seite wird durch das Page Layout formatiert. Das Branding der Webseite mit Navigationsleisten, Logo, Ribbon und Kopfbereich wird in der Masterpage umgesetzt.
Markup und Style Vorlagen
Der Inhalte einer Page ist in den meisten Fällen ein Rich Text Feld mit einem Editor zum Formatieren des Textes. Der Editor bietet auch Format- und Markup-Vorlagen für Überschriften, Titel und Standardtexte. Diese Formatvorlagen und auch die Markupformatvorlagen müssen dem Style Katalog entsprechend eingerichtet werden. Wie das funktioniert ist hier Custom Styles for SharePoint 2010 Rich Html Field sehr gut beschrieben worden.
Wörterbuch der Rechtschreibkorrektur
Das Farm Feature "Spell Checking" ist in jeder SharePoint Umgebung automatisch aktiviert. Nun gibt es in jedem Unternehmen Wörter wie der Unternehmensname oder Produktnamen, die nicht aus dem Duden stammen, aber von der Rechtschreibkorrektur nicht als falsch markiert werden sollen.Unser Firmenname "Data One" soll natürlich nicht als Rechtschreibfehler markiert werden. Durch das Erweitern des Wörterbuchs kann man das verhindern. Das ganze ist zwar etwas umständlich, aber wie es möglich wird kann man hier sehr Adding Custom Spellings in SharePoint gut nachvollziehen.
Deaktivieren von Richtext Funktionen
Hat man die Formatvorlagen für ein Rich Text Feld einmal definiert, möchte man oftmal verhindern, dass Autoren trotzdem Ihre eigene Schriftart oder Schriftgröße auswählen können. Im Editor des Rich Text Feld ist das Bearbeiten von Texten jedoch möglich.Die einzelnen Funktionen des Rich Text Feld können jedoch deaktiviert werden. Was man alles deaktivieren kann, ist bei MSDN dokumentiert, wie es geht kann man hier nachlesen ( der Artikel ist zwar für SharePoint 2007, funktioniert aber auch in SharePoint 2010 ).
Variations
Mehrsprachigkeit ist eine Häufige Anforderung an Redaktionssysteme. Um die Mehrsprachigkeit von Inhalten zu ermöglichen bietet SharePoint die Funktionalität "Variations" an. Sobald Variations eingesetzt werden, müssen die Auswirkungen auf das Arbeiten mit Pages klar sein. Diese sind hier Variations in SharePoint 2010 – Connecting People with Content sehr gut beschrieben, insbesondere das automatische Veröffentlichen von Inhalten auf andere Sprachen, die Auswirkung auf die Versionierung und die Möglichkeit, nicht Übersetzte Pages mit der Quelle zu vergleichen.Solltet Ihr noch weitere Tipps und Tricks zum Thema SharePoint Pages haben, freue ich mich über jeden Kommentar.
Good luck,
Andreas
Montag, 9. Juli 2012
Nintex Forms and Nintex Live - Use Case
Am 15. Juni 2012 fand im Expomedia LIGHT-CUBE auf den Saarterassen in Saarbrücken die erste Data One Hausmesse statt. Unter dem Motto "Informieren - Kontakte pflegen - IT erleben" hat Data One Geschäftspartnern und Interessenten das Leistungsspektrum des Unternehmens präsentiert. Ein Review der Veranstaltung kann hier auf der Homepage von Data One nachgelesen werden.
Natürlich möchte Data One die Veranstaltung im nächsten Jahr verbessern und hat daher ein Feedback- Formular für die Besucher angeboten. Die Anforderungen an das Feedback- Formular sind klar:
- Kein Papier!
- Der Zugriff soll auch von mobilen Geräten erfolgen können.
- Jeder Besucher soll mit seinem eigenen Gerät das Feedback- Formular ausfüllen können und nicht auf ein Gerät von Data One zurück greifen müssen.
Die Umsetzung eines solchen Feedback Formulars ist der perfekte Anwendungsfall für Nintex Forms und Nintex Live. Nintex Forms ist ein webbasierter Formular Designer für SharePoint, Nintex Live eine von Nintex bereitgestellte Cloud. Nintex Forms grenzt sich ganz klar von benutzerdefinierte Eingabemasken durch SharePoint Designer oder Infopath Forms Services durch die Bereitstellung mobiler Ansichten für alle gängigen Mobile Devices ab.
Um ein Formular auch für mobile Geräte umzusetzen ist Nintex Forms daher das perfekte Tool. Im ersten Schritt wurde also eine SharePoint Liste angelegt mit Spalten für die einzelnen Bewertungen. Die Eingabemaske dieser SharePoint Liste wurde dann durch ein Nintex Forms Formular ersetzt. Das geschieht einfach und schnell über den Formular Designer ( siehe Abbildung oberhalb ) im Browser in den Einstellungen der SharePoint Liste. Alle mobilen Ansichten wurden im gleichen Arbeitsschritt ebenfalls angepasst und bereitgestellt. Die folgende Abbildung zeigt beispielhaft eine fertige Ansicht für Windows Phone 7, erstellt mit Nintex Forms.
Nachdem eine SharePoint Liste und die Eingabeformulare für alle Endgeräte fertig gestellt wurden, konnten die Forms in die Nintex Live - der Cloud - bereit gestellt werden. Die Bereitstellung ist lediglich ein weiterer Klick im Nintex Forms Designer, durch den man eine URL erhält, über die man das veröffentlichte Nintex Form in Nintex Live erreicht.
Es gibt nur eine URL für alle Endgeräte, die Unterscheidung zwischen Windows Phone, Android, Notebook oder Apple iPhone nimmt Nintex Forms eigenständig vor. Es ist nicht notwendig, dass die SharePoint Umgebung mit der zugrunde liegende SharePoint Liste veröffentlicht ist - die Eingaben der Veranstaltungsbesucher gelangen über eine verschlüsselte Verbindung von Nintex Live an die SharePoint Liste, ohne dass man hierfür die komplette SharePoint Umgebung veröffentlichen müsste.
Die Daten gelangen also über alle Endgeräte der Besucher in die SharePoint Liste. Der Aufruf des Formulars wurde durch einen QR Code auf Veranstaltungsplakaten dem Besucher noch erleichtert. Alle gängigen Smartphones verfügen über einen QR Code Scanner, der den eingelesenen Code automatisch in die zugrundeliegende URL umsetzt.
Als Besucher muss ich lediglich den QR Code auf den Plakaten einlesen und konnte über ein beliebiges Endgerät mein Feedback zu Veranstaltung abgeben. Durch den Einsatz von SharePoint, Nintex Live und Nintex Forms haben sich die Herausforderungen "mobile Endgeräte" und "Formularveröffentlichung" garnicht erst gestellt - da freut sich nicht nur die IT, die so ein Formular ohne großen Aufwand bereit stellen konnte, sondern auch die Marketing- Abteilung, die ohne Gemurre von der IT nun Daten zum Auswerten der Veranstaltung erhalten hat!
Wer mehr über Nintex Live oder Nintex Forms erfahren möchte, ist mit diesem Video und dieser Präsentation gut aufgehoben oder ist natürlich auch eingeladen, mich zu kontaktieren. Falls Ihr doch eher Lust habt, das Feedback Formular oder die Data One Hausmesse in Aktion zu sehen, sollte Fan von Data One auf Facebook werden und sich die Fotos von der Hausmesse anschauen. Vielleicht findet Ihr ja jemanden, der gerade das Feddback- Formular ausfüllt.
Good Luck,
Andreas
Montag, 2. Juli 2012
Central Email Management mit SharePoint - Better Collaboration
Exchange ist eine tolle Groupware und Email noch immer das beliebste Kommunikationsmittel. Mit Internetzugang kann ich "Email", ob mobil oder im Büro - ich weiß wies geht und es geht einfach. Von schnellen und kurzen Mitteilungen bis zu ausgefeilten Konzepten kann alles mit Emails an die selbst zusammengestellte Zielgruppe geschickt werden. Das Ganze ist dezentral und Jeder hat sein eigenes Emailsystem, man muss keinen Partner, Kunden oder Kollegen erst Zugriff auf die interne Infrastruktur geben. Sobald allerdings wichtige Informationen per Email verschickt werden, die besser zentral aufgehoben sind, wird die dezentrale Emaillösung zum Problem. Bei großen Projekten und Aufträgen mit Beteiligung interner Kollegen, Lieferanten, Partnern und Kunden möchte man auch die Informationen aus Emails zentral bereit stellen - und das möglichst zuverlässig, einfach und immer für das aktuelle Projektteam. Informationen in Postfächern genügen diesem Anspruch nicht.
In verschiedenen Kundenprojekten wurde ich mit dieser Anforderung konfrontiert und ein Interesse an einer Lösung ist fast bei jedem SharePoint Anwender vorhanden. Daher möchte ich diesen Artikel nutzen um meine Erfahrungen mit zentraler Emailverwaltung in SharePoint zu teilen.
Zuerst eine kleine Analyse der Möglichkeiten, Emails in SharePoint zu verwenden. Die folgende Abbildung zeigt verschiedene, vorstellbare Kommunikationswege, auf denen Emails geschickt werden oder geschickt werden sollen. Der Partner ( Kunde, Lieferant ... ) kommt aus der Wolke, die Infrastruktur des Kunden kennen wir nicht und wollen wir auch nicht kennenlernen - er kann Emails senden, das genügt uns. Seine Emails gehen entweder den orangnen Weg, den blauen Weg oder den grünen Weg.
Der Klassiker des Kommunikationswegs ist hier sicher der orangne Weg. Orange wird die Email direkt vom Partner aus der Wolke an den internen "A" geschickt. Die eingegangene Email liegt genau so lokal bei "A" wie die Antwort von "A" an den Partner. Natürlich kann die Email von "A" weiter gesendet werden, sie gehört aber alleine "A".
Wenn "A" einen SharePoint Server zur Verfügung hat, kann er seine Email dort auch ablegen. Oder der SharePoint hat "eingehende" Emails konfiguriert, so dass eine Dokumentenbibliothek selbst Emails empfangen kann. So kann die Email den blauen Weg gehen. Der blaue Weg hat den Vorteil, dass die Emails im SharePoint zentral liegen und ein Projektteam die Inhalte lesen kann. Das betrifft den Text der Emails und auch deren Anhänge. Der Partner aus der Wolke schickt seine Email dann am besten nicht mehr an einen einzelnen Ansprechpartner sondern an eine "Projektemailadresse", die an der Dokumentenbibliothek hinterlegt ist. Zumutbar ist dieses vorgehen allemal, Email-Verteiler sind ja keine Besonderheit, ob die Email bei einzelnen Personen landet oder auf dem SharePoit kann dem Anwender ja egal sein.
Das Problem mit dem blauen Weg ist allerdings die Antwort. Auch wenn der Eingang im SharePoint zentral abgelegt ist, wir die Antwort über einen lokalen Client - meistens Outlook - verschickt und liegt dann nicht mehr im SharePoint, sondern in den "Gesendeten Objekten" lokal bei "A" oder "B" und wäre somit nicht mehr im Zugriff des Projektteams.. Die Antworten und der Kommunikationsverlauf gehen verloren. Beim grünen Weg ist diese Problemstellung behoben, hier kann SharePoint nämlich selbst Antworten schicken. Eine Email liegt in SharePoint, der Benutzer öffnet die Email, drückt auf "Antworten", schreibt seine Antwort und sendet die Email weg - und die Antwort liegt automatisch im SharePoint. Dieser grüne Weg ist oftmals die Anforderung, jedoch ist er mit den gegeben Funktionalitäten nicht zu erreichen.
Ein Gruppenpostfach, an dem jeder Projektmitglied berechtigt wird, ist nicht die Lösung der Anforderung. SharePoint bietet für Zusammenarbeit viele Möglichkeiten und Funktionalitäten, die auch auf die Email- Kommunikation angewendet werden sollen. Solche Funktionalitäten sind:
Es empfiehlt sich der Einsatz einer zusätzlichen Komponente wie Apose email for .net. Wenn der Eingang und Ausgang einer Email aus SharePoint umgesetzt ist, wurde die Grundlage für den grünen Weg geschaffen. Der Erweiterung des grünen Wegs durch individuelle Anforderungen wie regelbasierte Inhaltsorganisation kann nach belieben erweitert werden.
Natürlich liegt auch bei einer Lösung für den grünen Weg der Teufel im Detail - man merkt erst, was Outlook alles leistet, wenn man einen gewissen Teil der Funktionalität im SharePoint abbilden möchte. Falls jemand also Projekterfahrung in diesem Bereich sammeln konnte, freue ich mich genau so über einen Austausch wie mit einem Interessenten, der eine solche Lösung anstrebt!
Goof luck,
Andreas
In verschiedenen Kundenprojekten wurde ich mit dieser Anforderung konfrontiert und ein Interesse an einer Lösung ist fast bei jedem SharePoint Anwender vorhanden. Daher möchte ich diesen Artikel nutzen um meine Erfahrungen mit zentraler Emailverwaltung in SharePoint zu teilen.
Die Anforderung
Zuerst eine kleine Analyse der Möglichkeiten, Emails in SharePoint zu verwenden. Die folgende Abbildung zeigt verschiedene, vorstellbare Kommunikationswege, auf denen Emails geschickt werden oder geschickt werden sollen. Der Partner ( Kunde, Lieferant ... ) kommt aus der Wolke, die Infrastruktur des Kunden kennen wir nicht und wollen wir auch nicht kennenlernen - er kann Emails senden, das genügt uns. Seine Emails gehen entweder den orangnen Weg, den blauen Weg oder den grünen Weg.
Der Klassiker des Kommunikationswegs ist hier sicher der orangne Weg. Orange wird die Email direkt vom Partner aus der Wolke an den internen "A" geschickt. Die eingegangene Email liegt genau so lokal bei "A" wie die Antwort von "A" an den Partner. Natürlich kann die Email von "A" weiter gesendet werden, sie gehört aber alleine "A".
Wenn "A" einen SharePoint Server zur Verfügung hat, kann er seine Email dort auch ablegen. Oder der SharePoint hat "eingehende" Emails konfiguriert, so dass eine Dokumentenbibliothek selbst Emails empfangen kann. So kann die Email den blauen Weg gehen. Der blaue Weg hat den Vorteil, dass die Emails im SharePoint zentral liegen und ein Projektteam die Inhalte lesen kann. Das betrifft den Text der Emails und auch deren Anhänge. Der Partner aus der Wolke schickt seine Email dann am besten nicht mehr an einen einzelnen Ansprechpartner sondern an eine "Projektemailadresse", die an der Dokumentenbibliothek hinterlegt ist. Zumutbar ist dieses vorgehen allemal, Email-Verteiler sind ja keine Besonderheit, ob die Email bei einzelnen Personen landet oder auf dem SharePoit kann dem Anwender ja egal sein.
Das Problem mit dem blauen Weg ist allerdings die Antwort. Auch wenn der Eingang im SharePoint zentral abgelegt ist, wir die Antwort über einen lokalen Client - meistens Outlook - verschickt und liegt dann nicht mehr im SharePoint, sondern in den "Gesendeten Objekten" lokal bei "A" oder "B" und wäre somit nicht mehr im Zugriff des Projektteams.. Die Antworten und der Kommunikationsverlauf gehen verloren. Beim grünen Weg ist diese Problemstellung behoben, hier kann SharePoint nämlich selbst Antworten schicken. Eine Email liegt in SharePoint, der Benutzer öffnet die Email, drückt auf "Antworten", schreibt seine Antwort und sendet die Email weg - und die Antwort liegt automatisch im SharePoint. Dieser grüne Weg ist oftmals die Anforderung, jedoch ist er mit den gegeben Funktionalitäten nicht zu erreichen.
Die Lösung
Ein Gruppenpostfach, an dem jeder Projektmitglied berechtigt wird, ist nicht die Lösung der Anforderung. SharePoint bietet für Zusammenarbeit viele Möglichkeiten und Funktionalitäten, die auch auf die Email- Kommunikation angewendet werden sollen. Solche Funktionalitäten sind:
- Zusätzliche Metadaten wie "Anmerkung", "Erläuterung" oder "Wiedervorlagedatum" an einer Email.
- Genehmigungs- und Freigabeprozesse für eine Email durch Projektleiter und andere Verantwortliche.
- Definierte Betreffzeilen durch berechnete Felder.
- Erweiterte Kommunikationspartnerverwaltung.
- Versionierung.
- Berechtigungskonzepte auf Emailbasis.
- Inhaltsorganisation, um Emails nach bestimmten Regeln einzusortieren.
- Und vieles mehr...
Es empfiehlt sich der Einsatz einer zusätzlichen Komponente wie Apose email for .net. Wenn der Eingang und Ausgang einer Email aus SharePoint umgesetzt ist, wurde die Grundlage für den grünen Weg geschaffen. Der Erweiterung des grünen Wegs durch individuelle Anforderungen wie regelbasierte Inhaltsorganisation kann nach belieben erweitert werden.
Natürlich liegt auch bei einer Lösung für den grünen Weg der Teufel im Detail - man merkt erst, was Outlook alles leistet, wenn man einen gewissen Teil der Funktionalität im SharePoint abbilden möchte. Falls jemand also Projekterfahrung in diesem Bereich sammeln konnte, freue ich mich genau so über einen Austausch wie mit einem Interessenten, der eine solche Lösung anstrebt!
Goof luck,
Andreas
Samstag, 3. März 2012
SharePoint und Remote Blob Storage - Sinn und Unsinn.
Wer Heute eine SharePoint Plattform betreibt, muss sich früher oder später mit dem Thema Remote Blob Storage ( RBS ) auseinandersetzen. RBS meint die Auslagerung der großen Datentypen "Blob" aus der SQL Datenbank auf ein Filesystem. Diese kurze Beschreibung lässt vermuten, dass es sich dabei um ein Thema dreht, mit dem sich ausschließlich Administratoren und IT PROs auseinandersetzen. Als Entscheidungsgrundlage werden oftmals von Microsoft veröffentlichte TechNet Artikel zu Rate gezogen.
Die Vorteile durch den Einsatz von RBS lassen sich wie folgt zusammenfassen:
"Remote Blob Storage wird in den meisten Fällen wegen Geschäftsanforderungen eingesetzt!"
Betrachten wir den essentiellen Kern der SharePoint Plattform - den Endanwender und dessen Interessenvertretung, den Website Administrator - ist die Problemstellung, die es zu lösen gilt, schnell gefunden. Es ist die Größe der Inhaltsdatenbank.
Die Inhaltsdatenbank ist in ihrer Größe beschränkt. Natürlich ist der Einsatz von mehreren dieser Inhaltsdatenbanken im SharePoint möglich, doch ist das kleinste Objekt, welches sich einer Inhaltsdatenbank zuweisen lässt, eine Websitesammlung. Eine Websitesammlung ist eine hieraschische Struktur von Webseiten, Bibliotheken und Dokumenten und hat das Potenzial, viele Inhalte zu beinhalten. Eine Websitesammlung kann jedoch nicht über mehrere Inhaltsdatenbanken verteilt werden. Hat eine Websitesammlung - zum Beispiel das Intranet eines Unternehmens oder die Projektseiten - eine gewachsene Struktur, können die 200 GB an Inhalt schnell überschritten werden. Die folgende Abbildung veranschaulicht eine solche Websitesammlung mit einer breiten Struktur.
Eine Inhaltsdatenbank enthält die gesamte Breite der Struktur. Um die Inhalte auf verschiedene Datenbanken zu verteilen, wird diese Struktur aufgebrochen.
Durch entsprechende Richtlinien im IT-Konzept und Quotierung lassen sich solche verteilte Website-Strukturen erreichen, jedoch zum Preis der Websitesammlungskonfiguration. Viele Einstellungen sind auf den Bereich einer Websitesammlung begrenzt. Diese Einstellungen sind zum Beispiel Inhaltstypen, SharePoint Benutzergruppen, Sucheinstellungen und viele mehr.
Um eben diese einfache und einheitliche Konfiguration den Websitesammlungsadministratoren zu ermöglichen und dennoch den sicheren Betrieb der SharePoint Plattform zu gewährleisten wird RBS eingesetzt. RBS ermöglicht einen Entwurf der SharePoint Plattform, der den Geschäftsanforderungen entgegen kommt.
Good luck,
Andreas
Die Vorteile durch den Einsatz von RBS lassen sich wie folgt zusammenfassen:
- Bei einer Filegröße von einem MB oder größer erhöht sich die Performance des I/O und der des Prozessors des Datenbanksystems.
- Operationen zum Betrieb der Datenbank wie dbcc checks oder Indexdefragmentierung sind wesentlich beschleunigt.
- Die Speicherkosten der Datenmengen können durch die Auslagerung auf einen Storage minimiert werden.
- Es sind Inhaltsdatenbankgrößen von mehr als 200 GB möglich.
- Es sind mehr Sicherungs- und Wiederherstellungsszenarien zur Einhaltung von SLAs möglich.
- Die Sicherungs- und Wiederherstellungsszenarien müssen betrachtet werden ( die Sicherungs- und Widerherstellungsszenarien müssen betrachtet werden - ein Nachteil, hat man keine Probleme beim Einhalten der SLAs ).
- Ein einmaliger Einrichtungsaufwand entsteht, bei dem nicht nur das reine "aktivieren" des RBS zu betrachten ist, sondern auch viele benötigte Szenarien wie Inhaltsveröffentlichung oder Qualitätssicherungsprozesse.
- Der Betrieb der Plattform wird durch den zusätzlichen Betriebsaufwand durch RBS teurer.
"Remote Blob Storage wird in den meisten Fällen wegen Geschäftsanforderungen eingesetzt!"
Betrachten wir den essentiellen Kern der SharePoint Plattform - den Endanwender und dessen Interessenvertretung, den Website Administrator - ist die Problemstellung, die es zu lösen gilt, schnell gefunden. Es ist die Größe der Inhaltsdatenbank.
Die Inhaltsdatenbank ist in ihrer Größe beschränkt. Natürlich ist der Einsatz von mehreren dieser Inhaltsdatenbanken im SharePoint möglich, doch ist das kleinste Objekt, welches sich einer Inhaltsdatenbank zuweisen lässt, eine Websitesammlung. Eine Websitesammlung ist eine hieraschische Struktur von Webseiten, Bibliotheken und Dokumenten und hat das Potenzial, viele Inhalte zu beinhalten. Eine Websitesammlung kann jedoch nicht über mehrere Inhaltsdatenbanken verteilt werden. Hat eine Websitesammlung - zum Beispiel das Intranet eines Unternehmens oder die Projektseiten - eine gewachsene Struktur, können die 200 GB an Inhalt schnell überschritten werden. Die folgende Abbildung veranschaulicht eine solche Websitesammlung mit einer breiten Struktur.
Um eben diese einfache und einheitliche Konfiguration den Websitesammlungsadministratoren zu ermöglichen und dennoch den sicheren Betrieb der SharePoint Plattform zu gewährleisten wird RBS eingesetzt. RBS ermöglicht einen Entwurf der SharePoint Plattform, der den Geschäftsanforderungen entgegen kommt.
Good luck,
Andreas
Share One 2012 - SharePoint Event
Die Share One wird seit 2010 veranstaltet und mach nach Köln und Zürich dieses Jahr in Frankfurt Station. Die Share One 2012 bleibt Ihrem Format treu und ist ein eintägiges Event rund um SharePoint. Interessante Vorträge von den Sponsoren AvePoint und Materna werden durch Erfahrungsberichte und Vorträge von namenhaften Speakern abgerundet.
Save the date!
Was: www.shareone.de
Wo: Lindner Hotel & Sports Academy Frankfurt
Wann: 09. Mai 2012
Beste Grüße,
Andreas
Save the date!
Was: www.shareone.de
Wo: Lindner Hotel & Sports Academy Frankfurt
Wann: 09. Mai 2012
Beste Grüße,
Andreas
Abonnieren
Posts (Atom)