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.

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.

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

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

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.

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

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