Wer mit SharePoint täglich arbeitet, benötigt auch ein gewisses Verständnis von den Strukturen des Systems. Wichtig ist dabei zunächst einmal das Wissen um die hierarchische Struktur, die vorgibt, wer mit welcher Rolle auf welche Ressourcen zugreifen kann. Der folgende Beitrag, der den Auftakt zu einer längeren Serie über SharePoint-Grundlagen bildet, erläutert die Besonderheiten rund um Site- und Farm-Strukturen. Leider können SharePoint-Benutzer die Hierarchie der strukturellen Inhaltselemente seit der Version 2013 nicht mehr auf Anhieb erkennen. Eine kleine Hilfe dafür bot bis 2010 der Navigationsweg (oder auch Brotkrümelspur / Breadcrumbs) auf den Seiten. Um zunächst ein Basisverständnis für den Gesamtaufbaus von SharePoint zu bekommen, kann man ihn als eine verästelte Sammlung von Websites beschreiben. Diese können abhängig von Server- und Berechtigungsstrukturen direkt oder indirekt verbunden, oder aber aber auch völlig voneinander abgeschottet sein.
Start mit der Websitesammlung (Site Collection)
Beginnen wir daher bei der Erörterung der Problematik bei den initialen Aufgaben, die ein SharePoint-Administrator bei Aufsetzten des Servers vornimmt. Werden dabei mehrere Server aufgesetzt, spricht man von einer Server-Farm. Auf dem Server legt der SharePoint-Administrator zunächst eine Websitesammlung (Site Collection) an, zum Beispiel für Zusammenarbeit und Dokumentenmanagement.
Für jede Websitesammlung kann der SharePoint-Administrator einen Websitesammlungs-Administrator benennen, einen so genannten ‚Site Collection-Admin‘. Er selbst hat dann keinen Zugriff mehr auf den Inhalt der Websitesammlung, nur noch der Websitesammlungs-Administrator. (Direkt zum Video: Sprungmarke 1:05)
Teamsite oder Websitesammlung?
Aus der Sicht des Benutzers sieht eine Websitesammlung aus wie eine Teamsite. Falls er dabei die gleiche Vorlage verwendet, ist kein Unterschied mehr erkennbar. Der Websitesammlungs-Administrator kann darin dann Listen & Bibliotheken, aber auch eine neue Teamsite anlegen. Man spricht dann von einer Subsite.
Für die Subsite kann der Websitesammlungsadministrator einen Siteowner benennen. Auch wenn er einen anderen als sich selbst als Siteowner benennt, so hat der Websitesammlungsadministrator immer vollen Zugriff auf die gesamte Websitesammlung, zum Beispiel für Dokumentenmanagement. Innerhalb dieser Teamsite können wieder Funktionen, also Apps, angelegt werden und ebenfalls eine neue Subsite. (Video-Sprungmarke 1:40)
Solchen Verschachtelungen von Sites sind aber enge Grenzen gesetzt, die sich aus der maximalen Pfadlänge im System ergeben. Es darf nicht tiefer gebaut werden als maximal 255 Zeichen. Oft sorgen firmeninterne Governance-Richtlinien sogar noch für weitere Einschränkung, um tiefe Verschachtelungen zu unterbinden. (Video-Sprungmarke 2:35)
Die Struktur wirkt sich auf den Datenzugriff aus
Für den normalen Nutzer ist die hierarchische Struktur oft verwirrend, da er das dahinterliegende Gesamtbild nicht erkennt. Erschwerend kommt hinzu, dass viele Administratoren die generischen Begriffe des Systems verwenden, also Bibliothek oder Liste anstatt beispielsweise Inventarliste oder Projektbibliothek.
Dabei ist das Wissen um die Struktur enorm wichtig bei der produktiven Arbeit. Für den Datenzugriff etwa spielt es eine große Rolle, ob Daten innerhalb einer Teamsite, innerhalb einer Websitesammlung, oder vielleicht sogar in zwei getrennten Websitesammlungen liegen. Oder bei der Zusammenarbeit und beim Dokumentenmanagement noch einmal mal zusätzlich in einem Extranet. (Video-Sprungmarke 3:30)
D
rei Ebenen
Die Berechtigungssteuerung kann sich zusätzlich verkomplizieren, wenn die Struktur ungeschickt aufgebaut wurde. Dabei spielen drei Ebenen einen Rolle, die zu berücksichtigen sind: Die Serverebene, die Ebene der Websitesammlung (Site Collections), und die Inhaltsebene einer Websitesammlung.
SharePoint-Aufbau am Pfad ablesen
Wie erkennt man nun die Struktur in seiner SharePoint-Umgebung? Relativ einfach war das noch in SharePoint 2010 mit dem Navigationsbutton oben, der aber in der Version 2013 fehlt. Doch kann man hier auf eine alternative Methode zurückgreifen, indem man sich am Pfad in der URL-Eingabezeile des Browsers orientieren. (Video-Sprungmarke 4:25)
Der Pfad lässt sich nach folgendem Schema entziffern:
Der erste Teil stellt immer den Server dar- der zweite Teil gibt die Websitesammlung an
- der dritte Teil die Teamsite
Je nach Verschachtelungstiefe kann darauf nochmal eine Teamsite folgen, oder auch direkt eine Funktion. Danach folgt wieder eine Teamsite oder eine Funktion, hier zum Beispiel eine Funktion, und darin dann ein Element. Bei der Funktion handelt es sich um Apps in SharePoint 2013. Beim Element können natürlich auch Dateien, wie hier im Beispiel vorkommen.
Haben Sie Fragen oder Anregungen zu diesen Tipps? Ich freue mich auf Ihr Feedback und Ihre Kommentare! Servus und bis bald!
Hallo,
ja, dies ist ein Problem von SharePoint, was den Benutzer verwirrt.
Aus technischer Sicht finde ich Ihre Erörterung nicht präzise genug:
Eine Websitesammlung hat immer eine Webseite (Root-Web), daher „sieht“ der Benutzer auch eine Websitesammlung nicht, sondern immer eine Webseite (in Ihrem Beispiel eine Teamsite). Genau genommen sieht er auch die Webseite (SPWeb) nicht, sondern die Startseite der Website. Somit sind für mich Websitesammlung und Website „virtuelle“ Begriffe, die der Benutzer nicht anfassen kann.
Auch die Hilfestellung mit der URL hat Lücken, da z.B. eine Websitesammlung, welche die Root-Websitesammlung ist, keinen zweiten Teil in der URL hat.
Hallo Herr Sander,
herzlichen Dank für Ihren Kommentar! 🙂
Sie haben die Problematik auf den Punkt gebracht. Ich werde schauen ob ich den Beitrag dahingehend nochmal überarbeite.
Ich wollte es auf der einen Seite, so einfach wie möglich halten, aber die Informationen natürlich korrekt rüberbringen!
Danke für den Input!
Thomas Maier
Wenn man es genau nimmt, braucht es den Anwender auch gar nicht zu interessieren. Statt SiteCollection hätte man auch HeadSite oder MainSite wählen können. Es ändert nichts an der Tatsache, dass dieser Knoten der oberste für diesen Teil meines SharePoints ist.
Der Endanwender sieht immer nur Seiten, ganz gleich ob diese in einer Wiki-Bibliothek oder einer „einfachen“ Dokumentenbibliothek liegen. Es sind Vorlagen mit entsprechender Funtkionalität, mehr braucht der Anwender nicht zu wissen und meist interessiert es ihn auch nicht. Solange ich eine saubere und gut strukturierte Navigation habe, kann es meinen Usern egal sein, wie die SharePoint-interne Struktur ist. Für ihn sieht alles wie aus einem Guss aus. Und das sollte immer das Ziel sein. Die technische Basis ist ein Thema, womit sich Spezialisten rumplagen dürfen.
Hat man erst einmal verinnerlicht (oder vielmehr gelernt mit den einzelnen Begriffen etwas anfangen zu können), ist der Aufbau und die Bezeichnung auch logisch. Oder hat schon einmal jemand hinterfragt, warum der oberste Knoten in einem Unix-System „root“ heißt, wo er doch ganz oben steht, eine Wurzel aber in der Erde (also unten) sein sollte?
Hallo Herr Adler,
vielen Dank für Ihre Bemerkung.
für viele Anwender ist SharePoint „undurchsichtig“ – ich denke, hierbei helfen Hintergrundinfos um zu wissen, warum manche Dinge so sind, wie sie sind. Viele Anwender fühlen sich dann ein Stück weit „wohler“, wenn sie einen größeren Einblick haben.
In Schulungen erleben wir auch häufig, dass aus Anwender mehr oder weniger „über Nacht“ SiteOwner werden, oder sogar Websitesammlungsadministratoren. Oder dass Anwender diese Position bereits haben und an´s Werk gehen – ohne großes Hintergrundwissen. Es wird manchmal dann eine Struktur gebaut, ohne die Auswirkungen und Konsequenzen zu kennen.
Freundliche Grüße, heute aus Nürnberg,
Thomas Maier