COPiTOS erhält Microsoft Gold Partnerschaft

Die COPiTOS GmbH mit Sitz in Berg / Ravensburg und Büro in Frankfurt a.M. hat die Microsoft Gold Partnerschaft im Bereich SharePoint „Collaboration & Content“ erhalten.

Voraussetzung für den Erwerb der MS Gold Partnerschaft ist das Bestehen von verschiedenen Prüfungen, bei dem die Experten/innen der COPiTOS ihr technisches Fachwissen unter Beweis stellten. Die langjährige Erfahrung und fachliche Kompetenz der COPiTOS im SharePoint Umfeld, wird durch die Gold Partnerschaft bestätigt. Seit mehreren Jahren unterstützten wir unsere Kunden bei den unterschiedlichsten SharePoint Themen.

Die SharePoint Lösungen Ramses, Web Radar oder ImmoRent sind nachgefragte Anwendungen der COPiTOS GmbH. Weitere Details unter: https://www.copitos.de/unternehmen/aktuelles/201610-ms-gold-partnerschaft.aspx

„Digitale Transformation in Unternehmen“ – SharePoint Anwenderstudie 2016

Die Hochschule der Medien - Prof. Dr. Thorsten Riemke-Gurzki und Prof. Dr. Arno Hitzges haben die deutschlandweit umfangreichste Erhebung zu SharePoint durchgeführt. Ihre Studie von Juni 2016 zeigt, dass die Anwendung ein viel genutztes Werkzeug für den digitalen Austausch von Dokumenten in deutschen Unternehmen ist. 

Aufgrund der großen Marktdurchdringung wird die Anwendung stetig erweitert. Das führt dazu, dass Unternehmen SharePoint immer wieder aufs Neue an die Arbeitsbedürfnisse ihrer Mitarbeiter anpassen müssen. Deshalb stellt sich die Frage, wie SharePoint genutzt werden soll, um einen Mehrwert für den Anwender und den Business Partner zu schaffen. Die Einsatzbereiche, Funktionen, Strategien und Hindernisse der SharePoint-Anwendung haben die beiden HdM-Professoren gemeinsam mit dem Themenportal www.sharepoint360.de  hinterfragt. Dazu wurden im Zeitraum von Dezember 2015 bis Januar 2016 über 300 Anwenderunternehmen und Dienstleister online interviewt.

Quelle: https://www.hdm-stuttgart.de/view_news?ident=news20160707120018

 

Nintex Workflow 2013 kann nach Migration nicht bearbeitet werden bzw. veröffentlicht werden.

Lange gesucht, hier die Lösung 🙂

Nach einer SiteCollection Migration von SharePoint 2010 auf SharePoint 2013 mit dem Tool DocAve Version 6 gab es folgendes Problem

dass ein Nintex Workflows beim öffnen eine XML Fehlermeldung angezeigt hat.

Bei meiner Recherchen konnten ich feststellen, dass die Datei „nintex_autostartrules.xml“ einen ungültigen Inhalt aufgewiesen hat. (Die Datei kann  im Forms Ordner der Bibliothek gefunden werden.) Wenn die Datei mit dem Editor geöffnet wurde – war diese augenscheinlich leer, jedoch konnte man sehen das mit STRG+A ein Inhalt markiert wurde.

Damit der Nintex Workflow sich wieder öffnet lässt, muss die Datei korrigiert und neu gespeichert werden. Ich haben den Inhalt der nintex_autostartrules.xml aus dem Altsystem übernommen und voila die Datei lies sich wieder bearbeiten und veröffentlichen.

SharePoint Site-Template auslesen

Es kommt vor, dass man gerne wissen möchte, welches Site Template für eine vor längerer Zeit erstellten SiteCollection, Site oder Subsite verwendet wurde. Oft hat man dies nirgends dokumentiert, oder man hat es schlicht vergessen.

Sie funktioniert für 2010 und 2013.

Get-SPWeb http(s)://<URL SC, Site, Subsite> | Select-Object -Property WebTemplate, Configuration

So erhält man z.B. WebTemplate: “STS” und Configuration: “1”. Die ID des verwendeten Templates lautet somit “STS#1”. Im Internet findet man zahlreiche Websites mit den ID’s.

2010: http://social.technet.microsoft.com/wiki/contents/articles/20100.sharepoint-2010-default-site-templates.aspx

2013: http://social.technet.microsoft.com/wiki/contents/articles/20149.sharepoint-2013-default-site-templates.aspx

Alternativ besteht auch die Möglichkeit über den Quellcode die SiteTemplateID

  1. Betroffene Site aufrufen
  2. Rechte Maustaste QuellCode Anzeigen und nach dem Begriff „SiteTemplateID“ suche
  3. Auswerten der ID siehe Tabelle
Template Name Description
GLOBAL#0 Global template (1033)
STS#0 Team Site (1033)
STS#1 Blank Site (1033)
STS#2 Document Workspace (1033)
MPS#0 Basic Meeting Workspace (1033)
MPS#1 Blank Meeting Workspace (1033)
MPS#2 Decision Meeting Workspace (1033)
MPS#3 Social Meeting Workspace (1033)
MPS#4 Multipage Meeting Workspace (1033)
CENTRALADMIN#0 Central Admin Site (1033)
WIKI#0 Wiki Site (1033)
BLOG#0 Blog (1033)
BDR#0 Document Center (1033)
OFFILE#0 Records Center (1033)
OFFILE#1 Records Center (1033)
OSRV#0 Shared Services Administration Site (1033)
SPS#0 SharePoint Portal Server Site (1033)
SPSPERS#0 SharePoint Portal Server Personal Space (1033)
SPSMSITE#0 Personalization Site (1033)
SPSTOC#0 Contents area Template (1033)
SPSTOPIC#0 Topic area template (1033)
SPSNEWS#0 News Site (1033)
CMSPUBLISHING#0 Publishing Site (1033)
BLANKINTERNET#0 Publishing Site (1033)
BLANKINTERNET#1 Press Releases Site (1033)
BLANKINTERNET#2 Publishing Site with Workflow (1033)
SPSNHOME#0 News Site (1033)
SPSSITES#0 Site Directory (1033)
SPSCOMMU#0 Community area template (1033)
SPSREPORTCENTER#0 Report Center (1033)
SPSPORTAL#0 Collaboration Portal (1033)
SRCHCEN#0 Search Center with Tabs (1033)
PROFILES#0 Profiles (1033)
BLANKINTERNETCONTAINER#0 Publishing Portal (1033)
SPSMSITEHOST#0 My Site Host (1033)
SRCHCENTERLITE#0 Search Center (1033)
SRCHCENTERLITE#1 Search Center (1033)
SPSBWEB#0 SharePoint Portal Server BucketWeb Template (1033)

 

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“ 🙂

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.