Für die Excel Services auf den SharePoint Server 2010 werden Enterprise CAL’s benötigt.
Leider bietet der SharePoint Server 2010 aktuell nur die Möglichkeit, Enterprise Features FARM weit zu aktivieren. Aus technologischer Sicht ist es für den SharePoint Server 2010 irrelevant, ob für alle Benutzer Enterprise CAL’s zur Verfügung stehen da jeder User bspw. Excel Services nutzen kann.

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.

Wenn man einen neuen SharePoint Server Installieren möchte, ist in der Regel der erste Schritt, dass man sich das passende Installationsmedium besorgt.

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.

(continue reading…)

Ein Horror für jeden Admin der seinen Server liebt, da kommt ein externer Consultant und soll einen SharePoint 2010 installieren, wenn das für den Admin nicht schon schlimm genug ist, benötigt dieser auch noch vom Server aus Zugriff aufs Internet um die Installation durchzuführen.

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.

Das Szenario kennt jeder Admin, irgendwann reichen die Kapazitäten eines Server nicht mehr aus und z.B. die SQL Datenbanken des SharePoint Servers sollen auf einen neuen oder anderen bestehenden Server umgezogen werden.

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.

Das erste Servicepack für den SharePoint 2010 wurde am 8. Juli von Microsoft veröffentlicht.

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

Das Servicepack 1 für den SQL Server 2008 R2 steht bei Microsoft zum Download bereit.
http://www.microsoft.com/download/en/details.aspx?id=26727

Das Servicepack hat die Versionsnummer 10.50.2500.0.

Zu den Neuerungen gehören:

• Dynamic Management Views for increased supportability
• ForceSeek for improved querying performance
• Data-tier Application Component Framework (DAC Fx) for improved database upgrade
• Disk space control for PowerPivot

Weitere Info befinden sich auf der Download Seite von Microsoft.

Am 29.09.2010 hat Microsoft das Servicepack 2 für den SQL Server 2008 veröffentlicht.
Der SQL Server hat nach dem Einspielen des SP die Version 10.00.4000.00.

Auf dieser Webseite kann das Servicepack heruntergeladen werden:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8fbfc1de-d25e-4790-88b5-7dda1f1d4e17&displaylang=en

Dieses SP ist für folgende Versionen geeignet:

• Microsoft SQL Server 2008 Standard
• Microsoft SQL Server 2008 Standard Edition for Small Business
• Microsoft SQL Server 2008 Developer
• Microsoft SQL Server 2008 Enterprise
• Microsoft SQL Server 2008 Express
• Microsoft SQL Server 2008 Express with Advanced Services
• Microsoft SQL Server 2008 Web
• Microsoft SQL Server 2008 Workgroup
• Microsoft SQL Server 2008 Analysis Services
• Microsoft SQL Server 2008 Reporting Services

Die Release Notes finden Sie hier:
http://social.technet.microsoft.com/wiki/contents/articles/microsoft-sql-server-2008-sp2-release-notes.aspx

Bereits bei der Erstellung eines DWH sollte man sich auch Gedanken über die richtige Backup Strategie machen, da diese sonst auch schnell vergessen werden kann.

Ein falsches bzw. nicht konfiguriertes Backup kann dazu führen, dass das Transaction Log die Festplatte vollständig  beschreibt und die betroffene Datenbank nicht mehr verfügbar ist. 
Aus diesem Grund werde ich hier den Zusammenhang zwischen den Transaction Log und dem Recovery Model der Datenbank beschreiben.

Funktion des Transaktion Log

Das Transaktion Log dient zur Ausfallsicherheit. Abhängig vom Recovery Model verhält sich das Transaction Log unterschiedlich.
Zuerst werde ich die allgemeine Funktion des Transaktion Log beschreiben, später im Abschnitt Recovery Model werde ich dann auf die Besonderheiten eingehen.

Das Transaction Log tritt nur bei Schreibvorgängen in Aktion, z.B. insert, update usw.

Nehmen wir eine Insert Transaktion.
Diese Transaktion wird vom SQL Server angenommen. Bevor er diese in die Datenbank übernimmt, wird sie in den Arbeitsspeicher (RAM) und in das Transaction Log geschrieben.
Dieser Vorgang geschieht gleichzeitig und hat das Ziel die Wartezeit für den Benutzer/Prozess zu reduzieren.

Sollte nun z.B. ein Stromausfall eintreten, bevor die Transaktion in die Datenbank übernommen wurde, wäre der Inhalt im RAM verloren und die Datenbank inkonsistent.

Das Transaction Log stellt in diesem Fall die Ausfallsicherheit für den Arbeitsspeicher da.
Solange eine Transaction nicht in die Datenbank übernommen wurde, ist diese im Log auch noch als “aktiv” gekennzeichnet.
Sollte z.B. nach dem Stromausfall der Server wieder starten, erkennt der SQL Server, dass es noch nicht abgeschlossene Transaktionen im Log gibt und überführt diese zuerst in die Datenbank bevor diese wieder erreichbar ist.

Im Normalbetrieb werden die im Arbeitsspeicher abgelegten Transaktionen sobald wie möglich in die Datenbank übernommen; je nach Auslastung des SQL Servers kann es jedoch auch einige Zeit dauern.
Eine genaue Zeitangabe kann jedoch nicht gemacht werden.

Sobald eine Transaktion in die Datenbank übernommen wurde, wird diese aus dem Arbeitsspeicher gelöscht und im Transaction Log als “übernommen” markiert.

wird der SQL Server geplant beendet, so werden zunächst alle Transaktionen in die Datenbank übernommen und anschließend der Dienst beendet.

Wie nun mit den “fertigen” Transaktionen im Log weiter verfahren wird, das ist abhängig vom Recovery Model.

Recovery Model

Der MS SQL Server kennt drei Recovery Modele Simple, Full und Bulk-logged standardmäßig ist bei allen neuen Datenbanken Full eingestellt. Diese Einstellung für neue Datenbaken kann angepasst werden indem das Recovery Model der model-Datenbank geändert wird.
Diese Datenbank dient als Vorlage für alle neuen Datenbanken.

Die Einstellung des Recovery Model kann jederzeit auch im laufenden Betrieb geändert werden, beachten Sie jedoch, dass diese Änderung auch Auswirkung auf Ihre Backup Strategie hat und pro Datenbank eingestellt wird.

Simple

Diese Model ist, wie der Name schon sagt, das einfachste. Sobald eine Transaktion in die Datenbank übernommen und im Log quittiert wurde, wird diese auch im Log gelöscht.
Das bedeutet auch, dass das Log nur einen geringen Speicherplatz Festplatten benötigt.

Wenn für eine Datenbank gar kein Backup eingerichtet werden soll, muss für diese Datenbank das Recovery Model Simple ausgewählt werden, weil ansonsten das Transaction Log die Festplatte vollschreibt und der SQL Dienst gestoppt wird.

Full

Im Gegensatz zu “Simple” werden die Transaktionen nach erfolgreicher Übernahme in die Datenbank nicht gelöscht, sondern nur quittiert.
Das Transaction Log wird nur durch ein Transaction Log Backup gelöscht.

D.h., in diesem Model sollte immer ein Datenbank- und Transaction Log Backup durchgeführt werden, damit die Festplatten nicht vollgeschrieben werden.

Dieses Model hat einen großen Vorteil: Es kann zur minutengenauen Wiederherstellung der Datenbank z.B. bei einem Festplattenausfall, Fehlfunktion sowie Falscheingabe genutzt werden.
Hierfür ist jedoch notwendig, dass die Transaction Logs häufig gesichert werden. Man kann sagen, je geringer der Datenverlust sein darf, desto häufiger muss das Transaction Log gesichert werden. Um die Wiederherstellungszeit gering zu halten, sollte jedoch mindestens einmal Täglich eine Datenbanksicherung durchgeführt werden.

Bulk-logged

Das “Bulk-logged” Model ist fast identisch mit “Full”. Es unterscheidete sich nur insofern, dass Bulk Insert nur minimal protokoliert werden, so dass diese nicht einzeln wieder hergestellt werden können.

Backup Strategie

Für die richtige Backup Strategie gibt es leider keine “Out of the Box” Lösung, weil jede Datenbank andere Anforderungen hat.
Auch kein Backup zumachen kann eine Strategie sein.

Wichtig ist nur, dass das Recovery Model entsprechend an die Strategie angepasst wird.

Es kann Situationen geben da macht es Sinn einen Report aus einer anderen Anwendung heraus zu starten und dem Report die Parameter mit zu übergeben bzw. einen Report direkt über die URL aufzurufen und zu rendern.
Man sollte jedoch beachten das es für einen solchen Aufruf verschieden Parameterarten gibt.

Zum einen gibt es Parameter welche der Bericht benötigt um die richtigen Werte anzuzeigen, zum anderen gibt es Parameter die den Berichtserver “steuern”.

Eine URL könnte Beispielhaft so aussehen:
http://SERVERNAME/Reportserver?/Verzeichnis/Reportname&PARAM1=TEST&PARAM2=HALLO&
rs:Command=Render

Die beiden Parameter PARAM1 und PARAM2 werden für Selektion im Bericht benötigt, der Parameter rs:Command=Render gibt den Befehl zum Rendern des Berichtes an den Berichtserver.

Der Reportname wird ohne Dateiendung angegeben.
Es sollten unbedingt alle Parameter an den Report übergeben werden, auch wenn diese gerade nicht benötigt werden, z.B. &PARAM1=&PARAM2=Hallo…
In diesem Beispiel würde der Parameter PARAM1 ohne Inhalt übergeben.

Mitt &rs: können Parameter zur Steuerung des Berichtservers übergeben werden &rs:Command=Render  löst das Rendern des Berichts aus.

Es gibt noch weitere Parameter die mit übergeben werden können um den Berichtserver zusteuern, einer der Wichtigsten ist Format dieser gibt das Renderingformat an.

Mit &rs:Format= können folgende Renderingformate angeben werden:
HTML3.2 , HTML4.0 , MHTML , IMAGE , EXCEL , WORD , CSV , PDF , XML und NULL

Diese URL z.B. gibt den Bericht im PDF Format aus.
http://SERVERNAME/Reportserver?/Verzeichnis/Reportname&PARAM1=TEST&PARAM2=HALLO&
rs:Format=PDF&rs:Command=Render

Wenn kein Format angegeben wird, so wird der Bericht als HTML erstellt.

Eine Beschreibung alle Parameter für den URL-Zugriff finden man in der TechNet Libary von Microsoft

In einem Projekt mit sehr sensiblen Daten und einem externen Zugriff auf die Reports, kam die Anforderung auf den Session Timeout anzupassen um die Datensicherheit zu erhöhen.

Der Session Timeout im Reporting Server ist nach der Installation 600 Sec = 10 Min.

Diesen kann man jedoch ändern.

Als erstes erstellt man die Datei sessionTimeout.rss mit folgendem Inhalt

Public Sub Main()
    Dim props() as [Property]
    props = new [Property] () { new [Property]()}

    props(0).Name = "SessionTimeout"
    props(0).Value = timeout

    rs.SetSystemProperties(props)
End Sub

Als nächstes führt man folgenden Befehl aus dem Verzeichnis aus, in dem die sessionTimeout.rss gespeichert wurde.

Die Angabe des Timeoutwertes ist in Sekunden.

RS.exe ist das Scripting Tool für den Reporting Service nähere Infos HIER