Am 26.08.2015 hat Microsoft die SharePoint 2016 Preview Guide veröffentlicht

Das rund 20 Seiten große PDF-Dokument fasst die wichtigsten Informationen zu der neuen SharePoint-Version zusammen. Ich haben das Dokument angeschaut und die wichtigsten Punkte aufgelistet

Quelle: SharePoint Server 2016 Preview Reviewer’s Guide

  • SharePoint 2016 bietet eine neue Rollenverteilung an, was für einen sparsameren Umgang mit den System-Ressourcen (CPU, RAM, Festplatte) sorgen soll.
  • Während der Konfiguration der Farm oder des Einbindens eines neuen Servers in die Farm besteht nun die Möglichkeit, die Rolle wie z.B. Web Front End der Maschine festzulegen – das wurde auch mal Zeit 🙂
  • Im SharePoint können in einer Suchanwendung bis zu 500 Millionen Items indexiert werden.
  • Eine Datenbank kann bis zu 100 000 Site Collections speichern und verwalten
  • Die Upload-Größe ist auf 10GB begrenzt worden.
  • Das neue Responsive Design kann ohne Anpassungen auf mobilen Geräten über die Touch-Oberfläche bedient gesteuert und bedient werden.

 

 

SharePoint – Benutzergruppen ($Web.CreateDefaultAssociatedGroups)

Mal wieder etwas zum Thema „SharePoint-HowTo“ für alle, die das Problem vielleicht noch nicht kennen…

Wenn man eine SiteCollection über die CA anlegt, werden eine Hand voll SharePoint-Benutzergruppen automatisch erzeugt…dazu gehören unter anderem die Gruppen „Site Owner“, „SiteMember“ und „SiteVisitors“, die dann auch in den Web-Properties (z.B. „SPWeb.AssociatedOwnerGroup“) verewigt sind. Wenn man nun eine SiteCollection aus derselben Vorlage mit dem zugehörigen PowerShell-Befehl erzeugt („New-SPSite“), werden genau diese drei Standard-Gruppen nicht mit erzeugt und die entsprechenden SPWeb-Properties sind null.

Dies muss dann manuell erfolgen, bzw. mit einer Zeile entsprechenden PowerShell-Codes:

$Web.CreateDefaultAssociatedGroups($primaryOwner, $secondaryOwner, $title);

Erst dann klappt’s auch “mit dem Nachbarn” und man kann innerhalb eines derartigen Skripts auch das UI-Feature für die Standard-UI-Gruppen und –Berechtigungsstufen automatisiert aktivieren. Genau das läuft sonst nämlich auf einen Fehler, da es die o.g. Standard-Benutzergruppen erwartet.

Auf diese Art und Weise lässt sich auf der Entwicklungsumgebung eine spezifische SiteCollection per Skript beliebig oft löschen und neu erzeugen, inkl. Aktivierung aller notwenigen Features (echte Hilfe im Entwicklungsprozess, man erspart sich ein Haufen ständiger Klickerei).

Ein entsprechendes Beispiel findet ihr in der OptiBRP-Solution im Rollout-Ordner.

VisualWebparts – Properties

Im VisualStudio lassen sich wunderbar VisualWebparts entwickeln. Dabei kann man diese Teile mit einigen nützlichen Properties versehen (Title, Description, Group usw.). Soweit so gut…
Was nicht so wirklich nachvollziehbar ist, dass man das an zwei Stellen tun kann… einerseits in der „Element.xml“ und andererseits im „xxx.webpart“-File. Was einen aber wirklich Nerven kosten kann…
(
mal abgesehen von der Tatsache, dass die XML-Schemata voneinander abweichen und Copy/Paste hier keine gute Idee ist:
also „<Property Name=“Title“ Type=“string“ Value=“Titel“ />“ [Elements.xml]
vs. „<property name=“Title“ type=“string“>Titel</property>“ [xxx.webpart]
)
… ist, das die Properties abhängig davon, wo man sie definiert, unterschiedlich behandelt werden. Die Definition von „Title“ und „Description“ funktioniert z.B. an beiden Stellen, wobei die „Elements.xml“ gewinnt und die Angaben aus dem „xxx.webpart“-File überschreibt. Interessanter wird’s mit dem Property „Group“… das wird nämlich nur in der „Elements.xml“ berücksichtigt. Noch schöner ist das Property „CatalogIconImageUrl“, was wiederum nur berücksichtigt wird, wenn‘s denn im „xxx.webpart“-File definiert wurde.

SharePoint ist und bleibt eben ein „Geheimnis“ 🙂

Marktübersicht Yammer

Rob Koplowitz, Collaboration-Spezialist bei Forrester, liefert mit seinem neuen Report eine aktuelle Marktübersicht über die führenden Plattformen für Enterprise Social Collaboration. Verglichen mit den Bewertungen der letzten Jahre hat Microsoft stark aufgeholt und liegt nun fast gleichauf mit IBM, Jive und Salesforce.com. Doch für Interessenten der SharePoint-Plattform lohnt ein genauer Blick: So wurde zum Beispiel Yammer separat (ohne Office 365) bewertet und liegt hier leicht hinter den Alternativen Sitrion (früher NewsGator) und Neudesic.

Für „BigData“ ist SharePoint nicht wirklich geeignet – Critical Unknown SQL Exception 515 occurred

Folgender Fall… Eine Liste mit sehr vielen Spalten (Grenzwerte für die max. Anzahl von Spalten je Datentyp werden eingehalten; ebenso der Grenzwert für die Anzahl zulässiger Lookup-Spalten). Soweit so gut… Jetzt kommt man irgendwann auf die Idee, die Spalten-Anzahl innerhalb der Liste zu reduzieren und entfernt diverse Felder. Lesende Zugriffe funktionieren nach wie vor… ebenso auch das Update von vorhandenen Listeneinträgen. Wenn man allerdings einen neuen Listeneintrag hinzufügen will, krachts und man findet in etwa folgende Einträge im Log:

Critical Unknown SQL Exception 515 occurred. Additional error information from SQL Server is included below. Der Wert NULL kann in die tp_DocId-Spalte, dbo.AllUserData-Tabelle nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT. Die Anweisung wurde beendet.
System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80131904 at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem…

In den meisten Fällen verweist der Error-Code „0x80131904“ auf Speicherknappheit innerhalb der Content-Datenbank. Ganz so einfach ist das Ganze dann hier allerdings nicht…
Entscheidend ist der vorangegangene Fehler innerhalb des SQL-Servers („Der Wert NULL kann in die tp_DocId-Spalte, dbo.AllUserData-Tabelle nicht eingefügt werden.“).
In SharePoint werden die Inhalte aller Listen innerhalb der gleichen Tabelle in der Content-DB („AllUserData“) speichert. Bei einer Liste, die sehr viele Spalten enthält wird ein einzelner Listeneintrag allerdings auf mehrere Zeilen innerhalb dieser Content-DB-Tabelle verteilt. Welche Listenspalte dabei in welche Zeile in der Content-DB-Tabelle geschrieben wird, entscheidet der Parameter „RowOrdinal“ (standardmäßig „0“) der jeweiligen Listenspalte. Entscheidend hierbei ist, das innerhalb der Listendefinition die erste Spalte immer einen „RowOrdinal=0″ haben muss. Ist dies nicht der Fall, kommt es zu o.g. Fehlermeldung. So eine Konstellation kann leider entstehen, wenn aus einer Liste mit einer hohen Anzahl von Spalten (d.h. es sind Spalten mit RowOrdinal>0 enthalten) mehrere Spalten wieder gelöscht werden und dadurch die erste Spalte in der Listendefinition einen RowOrdinal>0 behält. Nachzuvollziehen ist das Ganze entweder über den SharePoint-Manager (dieser kann allerdings nur auf einem der Farm-Server genutzt werden), oder aber indem man die Liste als Vorlage speichert, das dadurch erzeugte „.stp“-File aus dem Listenvorlagen-Katalog herunter lädt, in „.cab“ umbenennt und sich die Manifest.xml anschaut.
Hier hilft nur, die Spaltenreihenfolge innerhalb der Listen-Konfiguration anzupassen, sodass die erste Spalte unbedingt einen RowOrdinal-Value von „0“ hat oder aber die „führenden“ Spalten mit RowOrdinal>0 zu entfernen und neu anzulegen. Was sagt uns das? Für „BigData“ ist SharePoint nicht wirklich geeignet… das gilt sowohl für die Listenbreite als auch für die Anzahl der Listeneinträge.