Um eigene Assemblies (z.B. Webparts, Web Controls oder User Controls) im SharePoint verwenden zu können, müssen diese als sogenanntes “SafeControl” registriert werden. Die Registrierung des SafeControl muss in der web.config Datei der Webapplikation erfolgen, in welcher die Assembly verwendet werden soll.

Der Eintrag in der web.config setzt sich mindestens wie folgt zusammen:

<configuration>
   <SharePoint>
     <SafeControls>
       <SafeControl Assembly="[Assembly Name]" Namespace="[Namespace]" TypeName="*" Safe="True" />
     </SafeControls>
   </SharePoint>
</configuration>

Assembly: Name der Assembly, in welcher die eigentliche Funktionalität implementiert ist. Es wird empfohlen, an dieser Stelle den “$SharePoint.Project.AssemblyFullName$”-Parameter zu verwenden. Dies ist ein ersetzbarer Parameter, welcher den “strong Name” der Assemby darstellt. Mehr Informationen zu ersetzbaren Parametern können der MSDN entnommen werden: http://msdn.microsoft.com/de-de/library/ee231545.aspx.

Namespace: Der Namespace, in welchem sich die Controls oder der Webpart befindet. Sollten sich die eigenen Controls in mehreren Namespaces befinden, so muss pro Namespace ein SafeControl Eintrag erstellt werden.

TypeName: Der Name des Controls, welchem es erlaubt werden soll im SharePoint ausgeführt zu werden. Sollten in einem Namespace mehrere Controls vorhanden sein, so muss nicht für jedes Control ein SafeControl registriert werden. Stattdessen kann als TypeName ein Sternchen (*) verwendet werden, um die gesamte DLL zu registrieren.

Safe: Boolean-Wert, welcher angibt, ob das Control sicher (true) oder nicht sicher (false) ist.

Um ein SafeControl zu registrieren gibt es verschiedene Möglichkeiten:

• Manuelles Hinzufügen des SafeControls zur web.config Datei (schlecht, dieses Vorgehen sollte nur zu Entwicklungs- und Testzwecken verwendet werden und niemals in einem Produktivsystem zum Einsatz kommen)
• Hinzufügen des SafeControls via Code (besser)
• Veröffentlichen einer Assembly als Solution Package (.wsp Datei) (empfohlen)

Manuelles Hinzufügen des SafeControls

Das manuelle Hinzufügen eines SafeControls zur web.config Datei erscheint auf den ersten Blick als einfachster und schnellster Weg. Es ist jedoch ausdrücklich nicht zu empfehlen, die web.config Datei selbst anzupassen.

Warum ist dieses Vorgehen nicht empfehlenswert? Was zu Beginn als einfach und schnell umzusetzen erscheint verursacht schnell einen enormen Pflege- und Administrationsaufwand. Solange man sich auf einem einzelnen SharePoint Server bewegt muss man den SafeControl Eintrag nur in die web.config Datei der gewünschten Applikation eintragen. Befindet man sich nun jedoch in einer kleinen Server Farm mit zwei Servern und möchte seine Assembly für fünf verschiedene Applikationen zur Verfügung stellen, so muss man bereits zehn web.config Dateien anpassen. Wenn nun noch ein weiterer Server zur Farm hinzugefügt wird, dann muss daran gedacht werden, die Änderung der web.config auch auf dem neuen Server durchzuführen.

Unterm Strich ist dies die aufwändigste und vor allem fehleranfälligste Variante. Sie eignet sich nur zu Entwicklungs- und Testzwecken.

Hinzufügen des SafeControls via Code

Das SharePoint Objekt Modell stellt die Klasse “SPWebConfigModification” zur Verfügung. Mit Hilfe dieser Klasse können aus dem Code heraus Änderungen an der web.config Datei einer Applikation vorgenommen werden.

Die so vorgenommenen Änderungen werden auf allen Servern der Farm ausgeführt und wirken sich auch auf neu hinzugefügte Server aus.

Um den Code zu verwenden kann z.B. die Methode “FeatureActivated” überschrieben werden. Dazu ist es jedoch erforderlich, dass die eigene Assembly über ein Feature deployed wird.

Folgender Code kann zur Anpassung der web.config Datei verwendet werden:

SPWebApplication webApp = site.WebApplication;

// Erweiterung der web.config definieren
SPWebConfigModification configMod = new SPWebConfigModification(
  "SafeControl[@Assembly=\"MyAssembly\"][@Namespace=\"My.Namespace\"]"
  + "[@TypeName=\"*\"][@Safe=\"True\"], "/configuration/SharePoint/SafeControls"
); 

// Die Aenderung der ModificationCollection hinzufuegen
webApp.WebConfigModifications.Add(configMod); 

// Die Aenderung anwenden
webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

Veröffentlichen einer Assembly als Solution Package

Die empfohlene Vorgehensweise, um eigene Webparts, Features, Assemblies etc. zu veröffentlichen ist die Erstellung eines Solution Packages (.wsp Datei). Gerade mit SharePoint 2010 sollte dies der einzigste noch verwendete Weg sein, da nun auch SharePoint selbst alle Features als wsp zur Verfügung stellt. Selbst über die Oberfläche gespeicherte List- oder Sitetemplates werden nun als .wsp Datei zur Verfügung gestellt.

Während früher für die Registrierung des SafeControls noch die Manifest Datei des Solution Packages angepasst werden musste, bietet Visual Studio 2010 heute eine einfache Oberfläche für diese Aufgabe. In den meisten Fällen wird diese Aufgabe sogar automatisch von Visual Studio 2010 durchgeführt (z.B. wenn ein Webpart zu einem SharePoint Projekt hinzugefügt wird).

Sollte Visual Studio die Einstellung nicht automatisch vorgenommen haben (dies passiert z.B. beim Erstellen einer Custom Action, welche zusammen mit einem User Control verwendet wird), so kann diese mit wenigen Klicks nachgeholt werden:

1. Im Visual Studio die gewünschte Datei (z.B. das Modul, in welchem die eigene Assembly liegt) markieren und im Properties Fenster den Eintrag “Safe Controls Entries” öffnen.

   

2. Es wird ein neues Fenster geöffnet, in welchem die erforderlichen SafeControl Einträge gesetzt werden können. Visual Studio 2010 füllt diese Maske bereits mit Standardwerten und verweist dabei auf die Assembly des aktuellen Projektes. Wenn diese Maske wieder geschlossen wird, werden die vorgenommenen Änderungen automatisch in das Solution Manifest eingetragen, mehr muss nicht getan werden.

   

Die auf diese Weise registrierten SafeControls werden beim Deployment des Solution Packages automatisch allen Servern hinzugefügt und gelten auch für alle zukünftig hinzugefügten Server.

Sobald eine Service Application für den Excel Service angelegt wurde, versucht der SharePoint 2010 alle Excel Dateien (ab Excel 2007 aufwärts) im Browser zu öffnen. Für den SharePoint 2010 ist es irrelevant, ob die Enterprise Features für eine SiteCollention aktiviert oder deaktiviert sind. Falls die Features jedoch nicht aktiviert sind, bekommt der Benutzer eine Fehlermeldung.

Dieses Verhalten ist in einigen Szenarien hinderlich, wenn z.B. der SharePoint als Fileserver genutzt wird und es jedoch nur eine begrenze Anzahl an Enterprise Lizenzen für ausgewählte Benutzer gibt.

In diesem Fall muss der SharePoint Server 2010 daran gehindert werden, die „normalen“ Excel Dateien im Browser zu öffnen, indem die Websitesammlungs-Feature „Dokumente standardmäßig in Clientanwendungen öffnen“, aktiviert wird.

Sobald diese aktiv ist, werden alle Dokumente nur noch mit den lokal installieren Anwendungen geöffnet, z.B. Excel 2010 oder Word 2010.

Um dem ausgewählten Benutzer-Kreis dennoch das Öffnen von Excel Dateien über Excel Service im Browser zu ermöglichen, muss eine Dokumenten Bibliothek angelegt werden. In dieser Bibliothek werden nun die „speziellen“ Excel Dateien gespeichert. Die Berechtigung für diese Dokumenten Bibliothek sollte so eingestellt werden, dass nur Benutzer mit einer Enterprise CAL Zugriff haben.
Letztendlich muss in den erweiterten Einstellungen dieser Dokumenten Bibliothek noch die Funktion „Dokumente im Browser öffnen“ aktiviert werden.

Nachfolgend die detaillierte Beschreibung für beide Einstellungen:

Webseiten Einstellungen

1. Klickt in der SharePoint-Zentraladministration auf Websiteaktionen und anschließend auf Websiteeinstellungen.

2. Klickt auf der Seite Websiteeinstellungen im Abschnitt Websitesammlungsverwaltung auf Websitesammlungs-Features.

3. Klickt auf der Seite Features für das Feature Dokumente standardmäßig in Clientanwendungen öffnen auf Aktivieren (OpenInClient-Feature ist aktiviert), um Dokumente in der Clientanwendung zu öffnen. Klickt auf Deaktivieren (OpenInClient-Feature ist deaktiviert), um Dokumente im Browser zu öffnen.

Dokumenten Bibliothek

1. Klickt auf der Bibliothekssymbolleiste auf Bibliothekseinstellungen.

2. Klickt auf der Seite Dokumentbibliothekseinstellungen auf Erweiterte Einstellungen.

3. Wählt nun auf der Seite Erweiterte Einstellungen unter Öffnen von Dokumenten im Browser eine der folgenden Optionen aus:

In der Clientanwendung öffnen: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument in der entsprechenden Clientanwendung geöffnet (sofern verfügbar).

Im Browser öffnen: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument in der Webbrowserwebanwendung für diesen Dokumenttyp geöffnet. Wenn das Dokument in der Webanwendung geöffnet wird, kann der Benutzer auswählen, ob das das Dokument in der Clientanwendung geöffnet werden soll.

Serverstandardeinstellung verwenden: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument gemäß dem Standardöffnungsverhalten geöffnet, welches für den Server vorgesehen ist, auf dem die SharePoint 2010-Produkte installiert sind.

Early this year I stumbled across a very interesting Windows desktop gadget, that is capable of showing an Excel Services element on the Windows desktop. Here, element can be a certain named region, a pivot table or a chart in an Excel Services document. The technology for showing this element is the Excel Services REST API (REST stands for Representational State Transfer).

You can find the article about the desktop gadget as well as the download link for the gadget itself here. Installation and configuration of the gadget is pretty well explained on the linked site, so I can keep this short here.

After adding the gadget to your desktop, the gadget still needs to be configured.

By clicking on the gadget configuration icon, the configuration dialog is displayed:

So the simple idea is to create a nice pivot table and to use this as the basis for the gadget. For my example I created a simple pivot table based on the Finance perspective of the Adventure Works OLAP cube. For the pivot table I have the year on the filter, the sales amount and the operating profit KPI as the data and the departments on the rows.

If we use this large table in our gadget, the thumbnail view gets pretty much “microscopic”:

So, for the thumbnail (default) view you should choose a much smaller area. The flyout (detail view) is much better, but the KPI indicators and the filters are not shown:

So, here are a few tips and tricks you can use to make the gadget look nicer.

1. Use time filters for current year, current month etc.

Of course we want our gadget to always show the latest values. Because of the auto refresh interval, we don’t have to care about this. But usually we will also use a time filter to restrict the data to a specific week, month etc. Since we don’t see the filter, the idea is to have this set automatically to the current time.

This can be easily done in the Excel Pivot Table by using date filters. Unfortunately, these filters don’t work in the filter area, so we have to place the time hierarchy on the rows or columns. Then we can apply a filter (for example current year) as shown here:

For Adventure Works this would not result in any data since the sample date is only available for the years shown in the screenshot. However, in real life scenarios, this would be a good choice for the filter.

2. For thumbnail view, convert the pivot table to formulas

Formulas are much easier to handle and to format, compared to a pivot table. Remembering the very narrow available space for the thumbnail view, having full control of the layout is important. You may even want to hard-code the thumbnail view. Let me explain what I mean. In order to have the connection name at a single place, we start in a blank sheet by putting the connection name in a named cell called “OLAPConnection” (feel free to choose a different name):

As the next step, let’s construct the current date member. From Management Studio, we can see that the MDX name of the time members looks like this (may be different in your cube, this example is taken from the Adventure Works sample database):

• [Date].[Calendar].[Calendar Year].&[2001]
• [Date].[Calendar].[Month].&[2001]&[1]
• [Date].[Calendar].[Date].&[20010101]

Here we have January 1, 2001. This is easily constructed using Excel’s time functions. So we simply add these fields to our Excel sheet

Of course you could also add fields for the previous month, the week etc., just depending on the needs of your scorecard. I named the cells B4 as MDXYear, B5 as MDXMonth, B6 as MDXDay. This is how the result looks like:

I had to fake the current date in order to see some values. Therefore I replaced the formula for today with this one:

=Date(2004, Month(Now()), Day(Now()))

Of course, you won’t want to do this in a real life scenario but since the sample dataset contains no data for 2011 I had to use this “time machine formula”.

Before you start wondering what all this is good for, let’s query some data. For example, let’s assume that we want to see the operating profit (which is on the account ‘Operating Profit’) for the current year. So this would by our Excel formula:

=CUBEVALUE(OLAPConnection,"[Measures].[Amount]","[Account].[Accounts].[Operating Profit]",MDXYear)

In order to show this value in our gadget, I placed it on a new sheet and adjusted the column width and height a little bit.

In order to get a nice flyout, I also created a simple pivot chart in the Excel sheet, showing the operational profit during the year. After saving the Excel file, our gadget now looks like this:

And here is the flyout:

3. (Conditional) background colors and fonts are preserved in the REST API

In order to include a kind of traffic light approach, we already found out that Excel indicators are not yet supported in the REST API. However, conditional formatting is supported, so you can easily create a scorecard like the follow:

Also KPI indicators can be created using special characters, for example from the WingDings font as shown in the following example:

For this example, I used a separate table of banding ranges and an Excel VLookup to find the appropriate color for the indictor. Here, 1=green, 2=yellow, 3=red. In the Excel cell I used conditional formatting to choose the text color appropriately. But as we always want to display a certain element (here, the diamond from the WingDings font), I used a custom format for each of the cells, so the number (1, 2 or 3) is not shown but only one character. The corresponding character for the diamond is “u”, so the custom format looks like this:

And of course, there is a lot more you can do with all these formatting, cube functions etc.

3. Make changes to the source code of the gadget

You can extract the gadget or modify the source code of the gadget yourself. After installing the gadget, the extracted sources can be found here:

%LOCALAPPDATA%\Microsoft\Windows Sidebar\Gadgets

After modifying the sources, the gadgets need to be switched off and on in order for the changes to apply. The main file is the gadget.html here. For example you could change the link “By Excel Services” to point on your SharePoint server. To do so, a simple change in the source is needed:

Before:
<tr><td id="dockedTitle" width="100%">
<a id="leftDockedTitleLink" href="http://blogs.msdn.com/cumgranosalis/pages/excel-services-windows-7-gadget.aspx">By Excel Services</a>
</td><td>

After:
<tr><td id="dockedTitle" width="100%">
<a id="leftDockedTitleLink" href="http://srv1/PowerPivot/Forms/AllItems.aspx">All reports</a>
</td><td>

I also changed the background color here, so this is how the result looks like:

As you can see, you can do a lot of interesting things with this simple but very powerful desktop gadget.

4. Use parameters

If you want to use the same Excel Services file for more than one user you may want to pass parameters from each individual instance of the desktop gadget to the Excel Services file. This is also possible, however there are some things to take care of.

The syntax for passing a parameter is

Ranges(‘cellname’)=value

Here, cellname is a named cell in Excel that we want to pass the value to. This is how it is entered in the desktop gadget, if our named cell is named ‘value1’ and we want to pass ‘xyz’:

Multiple parameters may be passed by separating them with an ampersand, for example

Ranges(‘value1′)=xyz&Ranges(‘value2′)=42&Ranges(‘value3′)=01

This could be our corresponding view in the desktop gadget:

I just added a field that concatenates all three parameters to show that the Excel Services sheet is recomputed based on the passed values.

As you can see, all parameters are passed to the gadget. However, numeric parameters are considered as numbers in Excel, so 01 was changed to 1. If you want to prevent this, add a ‘ in front of each text.

This is how the parameters should look like when you want to make sure, text is passed as text (and not converted to a number or date) in Excel:

Ranges(‘value1′)=‘xyz&Ranges(‘value2′)=42&Ranges(‘value3′)=‘01

You should also be aware, that this string is passed to the URL “as it is”. So you have to encode all characters that are not allowed in a URL.

For example, if you want to pass the year 2006 from AdventureWorks, the unique name of the date member would be:

[Date].[Calendar].[Calendar Year].&[2006]

In order to pass this to the gadget, you have to encode blanks, the square brackets and the ampersand. So the result would look like this:

Ranges(‘parDate’)=%5BDate%5D.%5BCalendar%5D.%5BCalendar%20Year%5D.%26%5B2006%5D

This is very difficult to read. Therefore I recommend just to pass the key (2006 in this case) as the parameter and to construct the unique name in Excel using a formula like

="[Date].[Calendar].[Calendar Year].&[" & parDate & "]"

Of course, there are a lot more things you can do with this simple, yet powerful Windows desktop gadget. Like with most other gadget you may also place more than one instance of the gadget on your desktop, so you can have different scorecards. You can also add links to your Excel sheet, so that you can jump directly to a dashboard for a specific key performance indicator. Just start playing with the gadget and see how powerful und useful it is.

Leider musste ich dann feststellen das Microsoft für den SharePoint 2010 die Installationsmedien nicht zeitnah aktualisiert bereitstellt.
Zum heutigem Stand z.B. ist für den SharePoint 2010 das Servicepack 1 und ein Cummulative Update Juni verfügbar.
In den bereitstehenden Downloads bei Microsoft sind diese Aktualisierungen leider noch nicht enthalten.

Um nun bei der Installation des SharePoint Servers Zeit zu sparen und nach der Installation noch die ganzen Updates manuell einspielen zu müssen, kann auch eine Silpstream Installation erstellt werden.
Diese kann man auch schon vor einem Kundentermin erstellen und dann eine vollständige Installation inklusiver der Updates mit zum Kunden bringen.

Hier für erstelle ich ein Verzeichnis in dem ich die gesamte Installationsdateien von der CD kopiere, bzw. in den ich Installation entpacke.

In meinem Beispiel lege ich einen Ordner \SP2010 direkt im Root meines Laufwerks C an, also c:\SP2010.
Nach dem die Installationsdateien dort abgelegt wurden, muss manuell noch ein Ordner Namens \Updates angelegt werden.

Nun können die Updates bei Microsoft heruntergeladen werden. Eine Übersicht welche Updates für den SharePoint gerade aktuell sind findet man hier http://technet.microsoft.com/de-DE/office/ee748587.aspx.

Meine Empfehlung wäre die Updates in einem Temporären Ordner zu speichern, weil diese noch entpackt werden müssen.
In meinem Beispiel werde ich nur das ServicePack 1 in die Installation einbinden, alle weiteren Cummulativen Updates würden dann im Anschluss ähnlich behandelt.

Ich habe den Download auf C:\Temp abgelegt.
Dort erstelle ich ein Unterverzeichnis \SP1, in welches ich die Updatedateien exportieren.

Um die Daten zu exportieren, muss nur der Befehl
officeserver2010sp1-kb2460045-x64-fullfile-en-us.exe /extract:sp1
ausgeführt werden, wobei der Dateiname sich bei jedem Update ändert.
Der Schalter /extract gibt an das die Pakete entpackt werden sollen und “:SP1" gibt das Zielverzeichnis an, hier könnte auch der vollständige Pfad angegeben werden z.B. C:\TEMP\SP1.

Wenn das Entpacken gestartet wurde, muss man noch den Lizenzbestimmungen zustimmen.

Wenn das Entpacken erfolgreich abgeschlossen ist sollten sich einige MSP-Dateien in dem Verzeichnis befinden. Es gibt dort noch andere Dateien, es werden aber nur die .msp Dateien benötigt.

Als letzten Schritt müssen jetzt nur die .msp Dateien in das Updates Verzeichnis kopiert werden.

Wenn jetzt weitere Updates vorliegen, können diese auf dem selben Weg in das Updates Verzeichnis abgelegt werden. Es kann dann vorkommen das einige Dateien in dem Verzeichnis bereits vorhanden sind, diese müssen dann durch die aktuellste Version ersetzt werden.

Das Setup des SharePoint 2010 überprüft am Ende ob es .msp Dateien im Updates Verzeichnis gibt und wenn ja dann werden diese noch installiert.

Während in SharePoint 2007 Dokumente lediglich über Ordner strukturiert werden konnten, bietet SharePoint 2010 ein neues Feature, mit welchem Dokumente und zugehörige Metadaten einfach strukturiert und verwaltet werden können – das Document Set.

Das Document Set bietet die folgenden neuen Kernfunktionen:

• Definition der in einem Document Set erlauben Content Types
• Definition von Dateien, welche in jedem Dokument Set vorhanden sein sollen
• Alle Dokumente innerhalb eines Document Sets teilen die selben Metadaten
• Eine Welcome Page, welche eine Zusammenfassung der wichtigsten Metadaten liefert
• Das gesamte Set kann versioniert werden
• Einfache Verwaltung über die SharePoint Oberfläche
• Document Sets basieren auf den SharePoint Content Types, es können also beliebig viele Document Set Content Types mit verschiedenen Inhalten vordefiniert werden

Hinweis: Document Sets sind ein Feature des SharePoint Servers 2010, sie sind also nicht in den SharePoint Foundations vorhanden.

Document Sets bieten sich immer dann an, wenn es ein oder mehr Standarddokumente gibt, die in verschiedenen Bereichen benötigt werden, oder wenn verschiedene Dokumente dieselben Eigenschaften teilen müssen.

Die einzelnen Features im Detail

Definition von erlaubten Content Types

Man kann selbst bestimmen, welche Content Types innerhalb eines Document Sets erlaubt sind, unabhängig von den erlaubten Content Types der übergeordneten Document Library.

Standarddokumente

Dokumente, welche als Default Content, zu einem Document Set hinzugefügt werden, werden automatisch in jedem neuen Document Set erstellt. Zusätzlich kann definiert werden, ob jede Datei automatisch den Namen des Document Sets als Präfix erhalten soll.

Geteilte Metadaten

Die Inhalte, der unter Shared Columns ausgewählten Spalten, werden auf alle Dokumente innerhalb des Document Sets synchronisiert.

Welcome Page

Die Welcome Page zeigt zum einen eine Zusammenfassung der wichtigsten Metadaten (Welcome Page Columns) und kann zum anderen einen eigenen View zur Verfügung stellen, mit dem die Dokumente innerhalb des Document Sets angezeigt werden sollen (Welcome Page View). Dies ermöglicht es innerhalb des Dokument Sets andere Spalten anzuzeigen, als auf Bibliotheksebene.

Man kann die Standard Welcome Page verwenden, oder diese an die eigenen Bedürfnisse anpassen. Hierzu stehen dieselben Möglichkeiten zur Verfügung, wie bei der Bearbeitung einer normalen SharePoint Seite.

Versionierung

Das Document Set bietet die Möglichkeit unabhängig von den einzelnen Dokumentenversionen eine Gesamtversion des Document Sets zu erstellen. So ist es möglich, erst verschiedene Versionen der in dem Document Set enthaltenen Dokumente zu erstellen, bevor eine gemeinsame Document Set Version erstellt wird.

Die einzelnen Dokumente werden wie gewohnt anhand der Versionierungseinstellungen der Bibliothek versioniert und verfügen alle über eine eigene Versionshistorie.

Um nun eine Version des gesamten Document Sets zu erstellen, gibt es innerhalb des Document Sets die Schaltfläche “Capture Version” in der Ribbonleiste.

Die Versionierung des Document Sets erlaubt es uns selbst, zu entscheiden, welche Versionen der einzelnen Dokumente in die Version des Document Sets gehören. So können z.B. nur die letzten Hauptversionen aller Dokumente beachtet werden.

Zusätzlich kann ein Versionskommentar gesetzt werden.

Die Versionshistorie des Document Sets zeigt sowohl die Versionen des Document Set selbst, als auch die Versionen der einzelnen Dokumente an.

Workflows

Genau wie auf einzelnen Dokumenten können auch auf Document Sets Workflows gestartet werden. Dies ermöglicht z.B. einen globalen Genehmigungsprozess für alle Dokumente innerhalb des Document Sets. Zusätzlich können natürlich auch für alle Dokumente innerhalb des Document Sets einzelne Workflows gestartet werden.

Der Document Set Content Type

Das Document Set ist ein normaler SharePoint Content Type. So kann das Document Set z.B. global über die Site Content Types angepasst werden, oder für jede einzelne Bibliothek, in welcher es verwendet wird. Zusätzlich können neue Content Types basierend auf dem Document Set erzeugt werden.

Verwendung von Document Sets

Der Document Set Content Type ist im SharePoint standardmäßig nicht verfügbar. Dieser muss erst mit dem “Document Sets Feature” auf Site Collection Ebene aktiviert werden.

Um Document Sets verwenden zu können, müssen die folgenden Schritte ausgeführt werden:

1. Unter Site Collection Features muss das Document Set Feature aktiviert werden

   

   Damit ist der Document Set Content Type verfügbar

2. In der Bibliothek, in welcher das Document Set verwendet werden soll, muss dieses als Content Type hinzugefügt werden. Hierzu unter Library Settings –> Advanced Settings den Punkt “Allow management of content types” aktivieren.

   

   In den Einstellungen für die Bibliothek erscheint nun ein neuer Bereich – “Content Types”

3. Unter Einstellungen einen existierenden Content Type hinzufügen und den Document Set Content Type auswählen

   

   Das Document Set kann ab jetzt in der Bibliothek verwendet werden

   

4. Alle oben genannten Einstellungen für das Document Set können über die Eigenschaften des Content Types unter “Document Set Settings” vorgenommen werden.

Für die Consultants untern den Leser sei gesagt, das in vielen Firmen das Servernetzwerk keinen Zugriff auf das Internet haben darf.

Jetzt kann der gut vorbereitet Consultant glänzen, in dem er eine DVD oder einen USB Stick aus der Tasche zieht, auf der die benötigten Dateien und das Installationsscript zu finden sind.

Benötigte Dateien

Als erstes sollten die in der folgenden Tabelle aufgelisteten Dateien bei Microsoft heruntergeladen werden.

Die angegebenen Links sind ohne Gewähr, als dieser Blog erstellt wurde, waren sie noch aktuell.

Ich habe mir für die SharePoint 2010 Installation einen Ordner angelegt, in dem ich auch die Installationsdateien von der SharePoint CD abgelegt hab.
C:\SP2010
Wenn die gesamte CD in dieses Verzeichnis kopiert wurde, dann existiert dort auch schon ein Verzeichnis Namens PrerequisiteInstallerFiles.

In diesem Verzeichnis lege ich nun die heruntergeladenen Dateien ab.

Das FilterPack wird von Microsoft direkt mit geliefert und muss nicht noch zusätzlich installiert werden.

Installationsscript

Wenn man den normalen Weg der SharePoint 2010 Installation geht, starte man hier und installiert die Prerequisite.

Bei dieser Variante wird jedoch ein Internetzugriff benötigt.

Man kann die PrerequisiteInstaller.exe aber auch mit Parametern starten und somit dazu bringen die bereits heruntergeladenen Dateien zu verwenden.

Die PrerequisiteInstaller.exe befindet sich im Root Verzeichnis der SharePoint Installationscd.

Bei meiner Verzeichnisstruktur sieht der Aufruf der PrerequisiteInstaller.exe wie folgt aus:

C:\SP2010\PrerequisiteInstaller.exe /SQLNCli:"c:\sp2010\PrerequisiteInstallerFiles\sqlncli.msi" /ChartControl:"c:\sp2010\PrerequisiteInstallerFiles\MSChart.exe" /NETFX35SP1:"c:\sp2010\PrerequisiteInstallerFiles\dotnetfx35.exe" /PowerShell:"c:\sp2010\PrerequisiteInstallerFiles\Windows6.0-KB968930-x64.msu" /KB976394:"c:\sp2010\PrerequisiteInstallerFiles\Windows6.0-KB976394-x64.msu" /KB976462:"c:\sp2010\PrerequisiteInstallerFiles\Windows6.1-KB976462-v2-x64.msu" /IDFX:"c:\sp2010\PrerequisiteInstallerFiles\Windows6.0-KB974405-x64.msu" /Sync:"c:\sp2010\PrerequisiteInstallerFiles\Synchronization.msi" /FilterPack:"c:\sp2010\PrerequisiteInstallerFiles\FilterPack\FilterPack.msi" /ADOMD:"c:\sp2010\PrerequisiteInstallerFiles\SQLSERVER2008_ASADOMD10.msi" /ReportingServices:"c:\sp2010\PrerequisiteInstallerFiles\rsSharePoint.msi" /Speech:"c:\sp2010\PrerequisiteInstallerFiles\SpeechPlatformRuntime.msi" /SpeechLPK:"c:\sp2010\PrerequisiteInstallerFiles\MSSpeech_SR_en-US_TELE.msi"

Auch wenn es jetzt hier so dargestellt wird, sind in diesem Befehl keine Zeilenumbrüche enthalten.
Zwischen den einzelnen Parametern ist immer ein Leerzeichen innerhalb des Parameters dann nicht mehr.

In meinem Beispiel liegen die Dateien auf der lokalen Festplatte, diese könnten aber auch im Netzwerk abgelegt werden. Dann würden die Parameter z.B. so aus sehen:
/SQLNCLi:”\\SERVER\Freigabe\sqlncli.msi

Es gibt noch einen weiteren Parameter der gesetzt werden kann,  /unattended ,durch diesen wird die Installation ohne Benutzer eingriff durchgeführt.

Wenn alle notwendigen Dateien installiert wurden, kann mit der Installation des SharePoint2010 begonnen werden.

Bei der Installation des SharePoint 2010 kann auch einiges vorbereitet und automatisiert werden, dazu werde ich aber in kürze einen weiteren Blogeitrag erstellen.

Da von so einer Umstellung oft auch andere System betroffen sind geschieht eine solche Umstellung meistens nicht auf einmal, sondern schritt weise, so das dem neuen System nicht einfach der Name des bisherigen Servers gegeben werden kann.

Nun ist hier die Empfehlung von Microsoft auf dem SharePoint Server für den neuen SQL Server einen SQL Alias im SQL Server Configuration Manager einzutragen.

Ich habe das so bei uns auch umgesetzt und es funktioniert ohne Probleme. Jedoch müssen hierfür die SQL Server Management Tools auf dem SharePoint Server installiert werden, was aus Sicherheitssicht auch nicht immer gewünscht wird.

Für eine saubere und logische Dokumentation ist dieser Weg auch keine schöne Lösung.

Aus diesem Grund empfehle ich, sich bereits vor der SharePoint Installation einen Virtuellen Name für den SQL Server zu überlegen und dann für diesen im DNS Server einen CNAME Eintrag  zu erstellen bzw. erstellen zulassen der dann auf den jeweils Produktiven SQL Server verweist.

Somit kann recht einfach der SQL Server gewechselt werden ohne die Konfiguration des SharePoint Servers anzupassen und in der Dokumentation muss nur der CNAME Eintrag angepasst werden.

[Update]

Die Einrichtung über einen CNAME ist jedoch nur sinnvoll wenn der Datenbankserver in der standard Instanz betrieben wird. Wenn dies nicht der Fall ist bleibt nur der weg über den SQL Alias.

Details und Download: http://support.microsoft.com/kb/2460045

Die neue Fast Search für SharePoint bietet viele neue Funktionen, u.a. eine Vorschau von Dokumenten. Für Word Dokumente wird die erste Seite angezeigt, für PowerPoint kann sogar die gesamte Präsentation als Preview eingesehen werden.

Läuft die SharePoint Seite unter SSL wird man statt mit der Preview, jedoch mit einem JavaScript Fehler begrüßt.

Der Fehler betrifft nur die Vorschaubilder, während alle anderen Features der Fast Search anscheinend problemlos funktionieren.

Die Details des Fehlers lauten ungefähr wie folgt:

Meldung: Syntaxfehler
Zeile: 2
Zeichen: 1
Code: 0
URI: https://meinSharePoint.oraylis.de/personal/documents/_vti_bin/wacproxy.ashx?redirect=https%3A%2F%2FmeinSharePoint.oraylis.de%2Fpersonal%2Fdocuments%2F_layouts%2FWordViewer.aspx
%3Fid%3D2Fpersonal%2Fdocuments%2FShared%2520Documents%2F
Der%2520ORAYLIS%2520Test.docx%26DefaultItemOpen%3D1&spsite=https%3A%2F%2FmeinSharePoint.oraylis.de%2Fpersonal%
2Fdocuments&docType=docx&zone=undefined&callbackFunctionName=
DelegateFn_SRB_g_3897520d_8fa6_4997_88c8_5ac1f1b642a5_5

Um den Fehler zu lösen muss das Root-Zertifikat nicht nur am Server selbst und im IIS installiert werden, sondern auch noch einmal explizit in die SharePoint Trusts aufgenommen werden.

Hierzu in der SharePoint Central Administration in den Bereich Security wechseln und die Seite Manage trust aufrufen.

Hier auf New klicken und das Root Zertifikat hinzufügen.

Der JavaScript Fehler verschwindet sofort und auch die Vorschaubilder werden bei der nächsten Suche angezeigt. Sollte der JavaScript Fehler behoben sein, die Vorschaubilder jedoch nicht angezeigt werden, heißt es ein wenig Geduld haben. Die Dokumente müssen erst gecached werden.

Wurden die Standardeinstellungen des Object Caches übernommen und das Publishing Feature in einer Applikation aktiviert, so wird in regelmäßigen Abständen die folgende Warnung ins Windows Event Log geschrieben:

Event ID: 7362

Log Name:          Application
Source:               Microsoft-SharePoint Products-Web Content Management
Date:                  11.10.2010 12:03:30
Event ID:           7362
Task Category: Publishing Cache
Level:                 Warning
Keywords:
User:                  <SharePoint System Account>
Computer:          <SharePoint Server>
Description:
Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.
To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.
Additional Data:
Current default super user account: SHAREPOINT\system

Ursache

Standardmäßig wird der SharePoint Systemaccount als Cache Super User Account eingetragen. Allerdings sollte dieser für jede Webapplikation, welche das Publishing Feature verwendet, auf zwei Domänenbenutzer aufgeteilt werden.

Warum zwei Benutzer?

Der Object Cache führt seine Abfragen als einer von zwei Benutzern aus, entweder als “Super User”, welcher vollen Zugriff auf alle Objekte im SharePoint hat (so z.B. auch auf Dokumente, welche noch den Status “Entwurf” haben), oder als “Super Reader”, welcher nur Zugriff auf veröffentlichte Objekte hat. Führt ein Benutzer nun z.B. eine Suche aus, so werden die Ergebnisse aus dem Cache angezeigt. Je nach dem, über welche Berechtigungen der Benutzer selbst verfügt, werden ihm entweder die Ergebnisse des “Super Users” oder des “Super Readers” angezeigt.

Lösung

Im Active Directory müssen zwei neue Benutzeraccounts angelegt werden. Diese Accounts benötigen keine besonderen Rechte oder Gruppenzugehörigkeiten. Die beiden Accounts sollten ausschließlich als Cache Accounts verwendet werden und niemals dafür die SharePoint Seite über den Browser aufzurufen.

Um die Benutzer nun richtig zu konfigurieren gibt es verschiedene Möglichkeiten. Diese Schritte müssen für alle Webapplikationen durchgeführt werden müssen, welche das Publishing Feature verwenden.

Variante 1: Central Administration und Power Shell

1. In der SharePoint 2010 Central Administration im Bereich Application Management die Seite Manage web applications öffnen.
2. Den Namen der Webapplikation auswählen, für welche die Konfiguration vorgenommen werden soll.
3. Aus dem Web Applications Tab die Option User Policy auswählen.
4. Im “Policy for Web Application” Fenster auf “Add Users” klicken.
5. Als Zone “All zones” auswählen und auf “Next” klicken.
6. Den Namen des Super User Accounts eintragen und als Berechtigung “Full Control – Has full control” auswählen.
7. Auf “Finish” klicken und auf die selbe Art und Weise den Super Reader Account hinzufügen. Als Zone wieder “All zones” wählen und als Berechtigung “Full Read – Has full read-only access” einstellen.
8. Eine Power Shell/SharePoint 2010 Management Konsole öffnen die folgenden Befehle ausführen:

   $wa = Get-SPWebApplication -Identity "<Name oder URL der WebApplication>"
   $wa.Properties["portalsuperuseraccount"] = "<SuperUser>"
   $wa.Properties["portalsuperreaderaccount"] = "<SuperReader>"
   $wa.Update()

   Hierbei ist wichtig, dass die Namen der beiden Benutzer Accounts in der selben Schreibweise angegeben werden, wie sie im Fenster “Policy for Web Application” angezeigt werden.

Tipp: Die oben gezeigten Befehle können auch als Power Shell Skript (.ps1 Datei) gespeichert werden.

Variante 2: Power Shell

Muss die Einstellung für mehrere Applikationen vorgenommen werden, lohnt sich die Automatisierung über ein Power Shell Script.

$webapp = Get-SPWebApplication –Identity http://webapp

# Reader Account registrieren und berechtigen
$rdrcred = New-SPManagedAccount –Credential (Get-Credential)
$rdrpol = $webapp.Policies.Add($rdrcred.Username, $rdrcred.Username)
$rdrpol.PolicyRoleBindings.Add($webapp.PolicyRoles.GetSpecialRole(“FullRead”)) 

# Writer Account registrieren und berechtigen
$wrtcred = New-SPManagedAccount –Credential (Get-Credential)
$wrtpol = $webapp.Policies.Add($wrtcred.Username, $wrtcred.Username)
$wrtpol.PolicyRoleBindings.Add($webapp.PolicyRoles.GetSpecialRole(“FullControl”)) 

# Accounts zuweisen
$webapp.Properties["portalsuperuseraccount"] = $wrtcred.Username
$webapp.Properties["portalsuperreaderaccount"] = $rdrcred.Username 

$webapp.Update()

Variante 3: Central Administration und STSADM

Für alle, die sich noch nicht mit der PowerShell auseinander gesetzt haben, gibt es die Möglichkeit die Benutzer auch über stsadm zu konfigurieren. Ich lege allerdings jedem SharePoint 2010 Administrator ans Herz sich schnellstmöglich mit der Power Shell vertraut zu machen, da stsadm in Zukunft von dieser abgelöst wird.

1. Die Schritte 1 bis 7 aus dem Abschnitt “Variante 1: Central Administration und Power Shell” ausführen, um die Benutzer der Web Applikation zuzuordnen.
2. Die nachfolgenden stsadm Befehle für jede Webapplikation ausführen:

   stsadm -o setproperty -propertyname portalsuperuseraccount
                         -propertyvalue "<SuperUser>" -url "<http://webapp>"
   stsadm -o setproperty -propertyname portalsuperreaderaccount
                         -propertyvalue "<SuperReader>" -url "<http://webapp>"