Nach dem July Patchday 2021 gab es bei SharePoint das Problem, dass Listen in der Listenasicht nicht mehr dargestellt wurden. Es wurde nur eine leere weiße Seite angezeigt. In der Quellcodeansicht sah man aber, dass der Server doch Content ausliefert, der aber nicht gerendert wird.
Nach einigem Suchen und Testen konnte die „Modern View / Moderne Erfahrung von SharePoint 2019 als Fehlerursache ausgemacht werden. Wenn man bei einer Liste die „Moderne Erfahrung“ deaktiviert, wird die Seite wieder richtig gerendert.
Die „Moderne Ansicht/ Moderne Erfahrung / modern experiences / modern View“ lässt sich per Powershell auch auf Websitesammlungsebene deaktivieren.
Add-PSSnapin microsoft.sharepoint.powershell -ea 0
$site = Get-SPSite http://siteurl
#Disable modern Lists and libraries for Site Collection
$featureguid = new-object System.Guid "E3540C7D-6BEA-403C-A224-1A12EAFEE4C4"
$site.Features.Add($featureguid, $true)
Nach einem Versions-Update einer SharePoint Umgebung treten beim Erstellen einer SharePoint Webseite mit einem Websitetemplate ein Fehler auf: „Problem beim Anwenden der Webvorlage: Für diese Webvorlage müssen bestimmte Features installiert und aktiviert sein.“
Problem: Nach der Aktivierung der SharePoint 2013 Funktionalität „E-Mail aktivierte Listen“ bleiben die an SharePoint gesendeten E-Mails in dem Drop Folder (Standard: C:\inetpub\mailroot\Drop) des lokalen SMTP-Servers liegen und werden von dem SharePoint Timerjob „Eingehende E-Mails von Microsoft SharePoint Foundation“ nicht in die entsprechenden E-Mail aktivierten Listen einsortiert.
Mögliche Lösungen: Dem Konto, unter dem der Dienst „SharePoint Timer Service“ läuft, fehlen die Berechtigungen, um Dateien aus dem Mail-Drop Folder „C:\inetpub\mailroot\Drop“ zu verschieben. Hier kann man die NTFS-Berechtigungen so anpassen, dass dem Dienstkonto Änderrechte zugewiesen werden. Quelle: Incoming e-mail stop in „drop“ folder
Weitere Lösungsmöglichkeit: Liegt eine E-Mail aktivierte SharePoint-Liste in einer Websitesammlung, für die eine Websitequota konfiguriert ist und liegt dabei der Wert für „Sandkastenlösungen“ bei null, werden die E-Mail ebenfalls nicht einsortiert/zugestellt. Lösung: Man muss bei der entsprechenden Websitequota bei dem Wert „Ressourcenkontingent für Sandkastenlösungen“ einen von null abweichenden Wert konfigurieren. Quelle: Incoming Email in SharePoint 2013 Stuck in Maildrop Folder
Ein SharePoint-Website-Newsfeed ist keine App im eigentlichen Sinne. Ein Newsfeed kann nicht über den „App hinzufügen“-Menüeintrag des Konfigurationsmenüs hinzugefügt werden. Der Newsfeed muss als Webpart einer Seite hinzugefügt werden. Damit das Newsfeed-Webpart zur Verfügung steht, muss zuerst das Websitefeature „Websitefeed“ aktiviert werden.
Hier das genaue Vorgehen:
Aufrufen der Websiteeinstellungen
Aufrufen der Websitefeatures
Aktivieren des Websitefeed-Features
Bearbeiten der Seite, auf der der Newsfeed eingefügt werden soll
Neben dem in einem vorherigen Blogartikel vorgestellten Windows Live Writer kann man auch Microsoft Word 2013 als Editor für seine SharePoint-Blogeinträge verwenden.
Um jetzt Word 2013 mit seinem SharePoint-Blog zu verbinden, klickt man in seinem Blog in dem Blogtools-Menü auf den Eintrag Blogging-App starten.
Danach öffnet sich Word 2013 und man muss noch das Anlegen eines neuen Blogkontos bestätigen.
Nach dem Anlegen des Blogkontos für den SharePoint-Blog kann man Word für die Erstellung und die Bearbeitung von Blogeinträgen verwenden.
Wie auch beim Windows Live Writer kann man Word 2013 dazu verwenden, Beiträge für mehrere Blogs gleichzeitig zu veröffentlichen. Dazu kann man z. B. einen WordPress-Blog über die Option Konten Verwalten / Neu als Zielplattform hinzufügen.
Bei der Konfiguration für einen WordPress-Blog muss man nur die Blog-URL, den Benutzernamen und das Kennwort angeben. Alle weiteren Einstellungen werden von Word 2013 automatisch konfiguriert.
SharePoint 2013 bietet eine Website-Vorlage, mit der sich ein einfacher Blog realisieren lässt. Die Funktionalitäten eines SharePoint-Blogs bleiben aber weit hinter denen von z. B. WordPress zurück. Um wenigstens das Editieren von Blogbeiträgen etwas komfortabler zu gestalten, kann man den Windows Live Writer Editor von Microsoft als Editor für die Erstellung seiner Blogbeiträge verwenden.
Der Windows Live Writer ist Bestandteil der kostenlosen Windows Essentials von Microsoft.
Mit dem Windows Live Writer ist es unter anderem auch möglich, einen Blogbeitrag gleich für mehrere unterschiedliche Blogs zu erstellen. Beispielsweise kann man einen Blogbeitrag gleichzeitig für SharePoint und für einen WordPress-Blog zur Verfügung stellen.
Hier ein Screenshot von dem Windows Live Writer, mit dem dieser Artikel erstellt wurde:
Eine der wichtigsten Erleichterungen beim Erstellen von SharePoint-Blogbeiträgen durch den Windows Live Writer ist die Funktionalität, Bilder direkt aus der Zwischenablage in den Blog einfügen zu können, ohne das Bild vorher hochzuladen.
SharePoint 2013 bietet eine Funktion, die es Benutzern ohne ausreichende Zugriffrechte auf eine SharePoint-Webseite erlaubt, eine Anfrage zu senden, um Zugriff für diese Website zu beantragen.
Zugriffsanforderung auf eine SharePoint-Website durch einen Benutzer
Wenn diese Funktion aktiviert ist, dann ist als Standard eine Platzhalter-E-Mail-Adresse someone@example.com als Ziel für die Anfrage konfiguriert. Ändert man diese E-Mail-Adresse nicht auf einen gültigen Wert, bekommen die Anfragenden eine Fehlermeldung, dass die Mail nicht zugestellt werden kann.
Um diese Funktion zu konfigurieren, muss der Besitzer der SharePoint-Website-Sammlung die Einstellungen für die Website-Berechtigungen aufrufen.
Aufrufen des Konfigurationsmenüs
Aufrufen der Websiteeinstellungen
Aufrufen des „Websiteberechtigungen“-Dialogs
Aufrufen der Einstellungen für Zugriffsanforderungen
Konfiguration der E-Mail-Adresse für die Zugriffsanforderungen auf eine SharePoint 2013-Website
In den Einstellungen für die Zugriffsanforderungen auf eine SharePoint 2013-Website kann man nun die gewünschte E-Mail-Adresse des Empfängers der Zugriffsanforderungen konfigurieren. Hier lässt sich aber auch das Feature „Zugriffsanforderungen“ deaktivieren, in dem man die Option „Zugriffsanforderungen zulassen“ deaktiviert.
Dann bekommt ein Benutzer ohne Zugriffsrechte auf eine SharePoint-Website nur einen Hinweis. Eine Zugriffsanforderungsanfrage kann er dann nicht stellen.
Fehlermeldung bei nicht ausreichenden Zugriffsrechten auf eine SharePoint 2013-Website
Das Erstellen einer Community-Website in SharePoint schlägt wegen eines fehlenden Features ‚Ratings‘ mit folgender Meldung fehl:
Das Abhängigkeitsfeature ‚Ratings‘ (ID: 915c240e-a6cc-49b8-8b2c-0bff8b553ed3) für das Feature ‚CommunitySite‘ (ID: 961d6a9c-4388-4cf2-9733-38ee8c89afd4) ist in diesem Bereich nicht aktiviert.
Lösung:
Aktivierung des Features ‚Ratings‘ mit der Powershell.
Beim Aufrufen einer Sharepoint-Seite mit Webparts, von denen der aktuelle Benutzer keine Rechte besitzt, wird folgender Fehler angezeigt:
Webpartfehler: Zugriff verweigert. Sie haben keine Berechtigung, diesen Vorgang auszuführen oder auf diese Ressource zuzugreifen.
SharePoint 2010: Webpartfehler Zugriff verweigert (Access Denied Web Part Error)
Die Sharepoint-Webseite soll Uploads von verschiedenen Benutzern zentral sammeln. Damit ein Benutzer nur Zugriff auf seine eigenen Uploads haben soll, wurde für jeden User eine eigene Dokumentenbibliothek angelegt. Bei dieser Dokumentenbibliothek wurde die Berechtigungsvererbung entfernt und nur dem User selbst und den administrativen Usern Rechte explizit gewährt. Um den Komfort zu erhöhen, wurde für jede Dokumentenbibliothek ein Webpart in die Standardseite eingefügt. Als ich mich mit einem Testuser, der nur Rechte auf eine Dokumentenbibliothek hatte, bei der Sharepoint-Webseite anmeldete, musste ich feststellen, dass die Webparts, auf die der User keine Berechtigungen hatte, nicht automatisch ausgeblendet wurden. Für jeden Webpart ohne Berechtigungen wurde der oben stehende Fehler angezeigt. Im Blogeintrag „SharePoint 2010 Access Denied Web Part Error“ musste ich lesen, dass man diesen Umstand nicht mit Sharepoint-Bordmitteln beheben kann („I am still waiting on Microsoft for that as well“). Die Lösung, die der Blogeintrag empfiehlt, ist eine „Quick and Dirty“-Lösung mit jQuery, die die Fehlermeldungen einfach clientseitig ausblendet. Dazu soll ein Inhaltswebpart mit einem jQuery Javascript Snippet am Seitenende eingefügt werden.
Dabei bin ich auf ein neues Problem gestoßen. Ich fand beim Inhaltswebpart von Sharepoint 2010 – im Unterschied zu Sharepoint 2007 – keine Option, um HTML-Quellcode einzugeben. Folgender Blogeintrag brachte eine einfache Lösung: „Insert JavaScript into a Content Editor Web Part„. Man muss den Code in eine Datei auslagern und diese dann dem Inhaltswebpart von Sharepoint 2010 zuweisen.
Einbinden von Code in das Inhaltswebpart
Nachdem dieses Problem gelöst worden war, musste ich feststellen, dass die Lösung, die Fehler mit jQuery auszublenden, noch nicht zufriedenstellend war. Die eigentlichen Fehler sind zwar ausgeblendet, die umgebenden Container aber nicht.
Ausgeblendete Webpartfehler Version 1
Leider waren immer noch Linien der umgebenden Containern zu sehen, ebenso störte der große Abstand zum Seitentitel. Nach etwas Experimentieren mit Firebug habe ich das Script wie folgt abgeändert:
Mit diesem Script wurden die Webpartfehler und die umgebenden Container vollständig ausgeblendet. Was jedoch bei dieser Lösung beachtet werden muss, ist, dass in der Ausgabe der Webparts, die angezeigt werden sollen, nicht das Wort ‚Fehler‘ vorkommt, da sonst auch dieses Webpart ausgeblendet werden würde.
Die Aufgabenstellung war, ein Formularcenter mithilfe von SharePoint zu erstellen. Es sollten über 400 Formulare hierarchisch gegliedert zum Download angeboten werden. Nach längerem Testen der standardmäßigen Gruppierungfunktionalitäten für Sharepoint-Listen, was nicht das gewünschte Ergebnis brachte, stieß ich auf folgenden englischen Blogeintrag: Adding a Treeview to a Document Library using SPTreeView and SPHierarchicalDataSource
Hier wurde gezeigt, wie man mittels SharePoint-Designer eine Ansicht erstellen kann, die die Ordnerstruktur einer SharePoint-Dokumentenbibliothek mittels eines TreeView-Steuerelementes abbildet – und dies ganz ohne Hilfe eines Webparts.
Folgende Schritte sind für eine TreeView-Ansicht einer SharePoint-Dokumentenbibliothek notwendig:
1. Aktivieren der Dateiansicht im SharePoint-Designer, um „Alle Dateien“ anzuzeigen. Dies muss unter den Website-Einstellungen der entsprechenden Websitesammlung gemacht werden. Hier ist unter der Rubrik „Websitesammlungsverwaltung“ der Link „SharePoint Designer-Einstellungen“ auszuwählen. Danach muss die Checkbox „Verwaltung der URL-Struktur der Website aktivieren“ aktiv gesetzt werden.
2. Danach ist die entsprechende View, die mit dem TreeView-Steuerelement versehen werden soll, im SharePoint-Designer im erweiterten Modus zu bearbeiten.
3. Danach wird der komplette Inhalt des ContentPlaceHolder-Tags mit der ID „PlaceHolderMain“ ausgeschnitten und über die Zwischenablage in einem externen Editor temporär abgelegt.
4. Erstellen einer HTML-Tabelle in dem leeren ContentPlaceHolder-Tag, um das Treeview-Steuerelement und die ursprüngliche Liste der Dokumentenbibliothek zu platzieren.
<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
<-- Tabelle als Layouthilfe für die Treeviev und die Liste der Dokumentenbibliothek -->
<table style="width: 100%">
<tr valign="top">
<td width="20%">
<-- Spalte für die Treeview -->
</td>
<td>
<-- Spalte für die Listendarstellung der Dokumentenbibliothek -->
</td>
</tr>
</table>
</asp:Content>
5. Ermitteln der notwendigen Informationen für das Treeview-Steuerelement mithilfe der Powershell und dem SharePoint-Designer. Benötigt werden die ListID der Dokumentenbibliothek und die ID der Webseite, in der sich die Dokumentenbibliothek befindet.
Die ListID der Dokumentenbibliothek wird mit dem SharePoint-Designer ermittelt:
Die ID der Website kann mit der PowerShell ermittelt werden:
6. Vorbereiten und Anpassen des Codes für das Treeview-Steuerelement:
<SharePoint:SPHierarchyDataSourceControl id="doclibDataSource" runat="server" RootListId="XXXXXXXXXXXXXXX" RootWebId="YYYYYYYYYYYYY" ShowFolderChildren="true" EnableViewState="false"></SharePoint:SPHierarchyDataSourceControl>
<SharePoint:SPTreeView ID="doclibtreeview" runat="server" DataSourceID="doclibDataSource" EnableViewState="false" ExpandDepth="2" SelectedNodeStyle-CssClass="ms-tvselected"></SharePoint:SPTreeView>
<-- XXXXXXXXXXXXXX = ID der Dokumentenbibliothek, ermittelt mit dem SharePoint Designer -->
<-- YYYYYYYYYYYYYY = ID der Website, ermittelt mit der Powershell -->
7. Einfügen des Treeview-Codes in die oben erstellte Tabelle.
8. Einfügen des zwischengespeicherten Codes für die eigentliche Listendarstellung der Dokumentenbibliothek, ebenfalls in die oben erstellte Tabelle.