Suche

Sonntag, 28. August 2011

SharePoint 2010 - Installation Service Pack 1

Ich möchte hier noch einmal kurz auf die Installation des SharePoint 2010 Service Pack 1 eingehen. Das Thema wurde zwar schon in einigen Posts diskutiert, jedoch gibt es immer noch Verständnis-Probleme mit der Installation.
Nach dem anfänglichen Durcheinander nach der Veröffentlichung  des Service Packs 1 und dem CU June 2011 gab es diverse Post, die sich mit der Installation des Service Packs 1 befasst haben. In den meisten Artikeln wurde empfohlen das CU June 2011 nach dem Service Pack 1 unverzüglich einzuspielen. Dieser Empfehlung sollte man allerdings nicht nachkommen.
Spencer Harbar hat hierzu einen sehr interessanten und empfehlenswerten Post (So What the Fuss?) geschrieben. Da das CU June 2011 auch in der aktualisierten Version nicht einwandfrei funktioniert (http://social.technet.microsoft.com/Forums/pl-PL/sharepoint2010setup/thread/7669d518-f7c9-4be4-9cd7-a1d5eae5ddd7) sollte man wirklich versuchen sich an diesen Guide zu halten und das CU June 2011 nicht unmittelbar nach dem Service Pack 1 einzuspielen. 
Wie bei allen anderen Updates und Service Packs empfiehlt es sich ein Test-System zur Evaluierung zu nutzen, bevor man sein Produktiv-System auf den neuesten Stand bringt.


Viele Grüße und viel Spaß,
Patrick

Mittwoch, 24. August 2011

Upgrade MOSS 2007 von SQL Server 2005 auf SQL Server 2008

Ich werde ich im folgenden Post den Vorgang beschreiben, wie man die Datenbanken eines MOSS 2007 von einem SQL Server 2005 auf einen SQL Server 2008 verschiebt.
Bevor man mit der Umsetzung beginnt, sollte man auf jeden Fall eine Sicherung der kompletten SharePoint-Farm durchführen.
Es werden die folgenden Berechtigungen auf den Systemen benötigt:


SharePoint
  • lokaler Administrator
  • Farm-Administrator
SQL-Server (2005)
  • lokaler Administrator
  • SecurityAdmin
  • DB_BackupOperator
SQL-Server (2008)
  • lokaler Administrator
  • DB_Owner
  • DB_Creator
Des Weiteren sollte man sicherstellen, dass genügend
  • Festplattenspeicherplatz für die Datenbank-Backups zur Verfügung steht und
  • der Zugriff auf alle benötigten Server erteilt wurde.

Durchführung Datenbank-Backups
Folgende Dienste müssen gestoppt werden, damit die Farm nicht mehr zu Verfügung steht:
  • Windows SharePoint Services Administration
  • Windows SharePoint Services Search
  • Windows SharePoint Services Timer
  • Windows SharePoint Services Tracing
  • Windows SharePoint Services VSS Writer
Nachdem die Dienste gestoppt sind kann der IIS gestoppt werden.
  • iisreset /stop
Nun erstmal einen Kaffee holen, da es eine kleine Zeit dauern kann bis der Windows SharePoint Services Timer alle Prozesse
beendet hat. Jetzt kann man mit dem eigentlichen Datenbank-Backup beginnen.



Möglichkeit 1: SQL Server Management Studio (GUI)
  • Rechtsklick Datenbank
  • Tasks
  • Backup
  • Einstellungen durchführen

Möglichkeit 2: SQL Server Management Studio (Skripte)
Folgendes Skript im SSMS ausführen:


BACKUP DATABASE [Datenbank-Name]
TO DISK = N'C:\BackUp\Datenbank-Name.bak'
WITH NOFORMAT,
NOINIT,
NAME = N'Datenbank-Name',
SKIP,
NOREWIND,
NOUNLOAD,
STATS = 10
GO
  • Datenbanknamen anpassen
  • Pfade anpassen
  • für alle Datenbanken ausführen
Die erstellten Backup-Dateien (Dateiname.bak) müssen nun kopiert werden und in ein Verzeichnis abgelegt werde, auf welches der neue SQL-Server Zugriff hat.

Durchführung Datenbank-Restore
Entweder die Datenbanken über die GUI des SSMS wiederherstellen oder aber über das folgende Skript.
Da es sich um mehrere Datenbanken handelt bevorzuge ich das Skript. Man muss es dann nur für jede Datenbank anpassen, lässt es dann laufen und kann sich in Ruhe einen Kaffee holen :-) (wie man bemerkt, ich trinke gerne Kaffee).
Die Pfade müssen natürlich auch dementsprechend angepasst werden, in diesem Fall wird die Instanz MSSQL2008R2 benutzt.


RESTORE DATABASE [Datenbank-Name] FROM DISK = N'C:\BackUp_2005\Datenbank-Name.bak' WITH FILE = 1,
MOVE N'Datenbank-Name' TO N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQL2008R2\MSSQL\DATA\Datenbank-Name.mdf',
MOVE N'Datenbank-Name_log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQL2008R2\MSSQL\DATA\Datenbank-Name_1.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO

Umbennung SQL-Server
Als nächstes muss nun noch der Server umbenannt werden, damit auch die korrekte Verbindung hergestellt werden kann.
Hierzu zu einfach die PowerShell-Console öffnen, in das Verzeichnis C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN wechseln und den folgenden Befehl eingeben:

.\stsadm.exe -o renameserver -oldservername "alter SQL-Server" -newservername "neuer SQL-Server"

Dieser Befehl muss auf allen Webfrontend-Servern durchgeführt werden. Nun müssen die WFE's noch durchgestartet werden.
Die Windows SharePoint-Dienste und der IIS werden nach dem Neustart automatisch hochgefahren.
Zur Kontrolle kann man nun die Zentral-Administration aufrufen und schauen, ob alles zur Verfügung steht und die Inhaltsdatenbanken das
richtige Mapping aufweisen.

Mittwoch, 10. August 2011

Moving FAST Search Server Indexfiles

Ich stand die Tage vor einem Problem mit den Indexfiles des FAST Search Server for SharePoint 2010. Standardmäßig werden die Indexfiles in dem Installationsverzeichnis (C:\FASTSEARCH) abgelegt, der Sinn hiervon sei mal dahingestellt. 
Nach einigen Recherchen bin ich dann auf den folgenden Artikel gestoßen. Die Informationsquellen für die FAST Search sind doch noch relativ dürftig. Die Nomenklatur des mklink-Aufrufes geht aus dem Artikel leider nicht eindeutig hervor und man könnte annehmen, dass man Ihn so übernehmen kann. Ein Junction Point lässt sich auch erfolgreich anlegen, jedoch funktioniert die FAST Search danach nicht mehr.
Hier dann noch einmal der komplette Vorgang mit der einzusetzenden Schreibweise:


  1. Stoppe den FAST Search for SharePoint service
  2. Stoppe den FAST Search for SharePoint Monitoring service
  3. Verschiebe den Ordner C:\FASTSEARCH\data in das neu erstellte Verzeichnis (hier D:\IndexFAST\data)
  4. Starte das folgende Skript in der Konsole: 
    • mklink /j C:\FASTSEARCH\data D:\IndexFAST\data
  5. Starte den FAST Search for SharePoint Service, der Monitoring Service wird automatisch mitgestartet
Dann viel Spaß beim Verschieben der Indexfiles.

Viele Grüße
Patrick




Dienstag, 9. August 2011

PerformancePoint Services - Dashboard Designer 2010

Leider hat es etwas gedauert, aber ich habe meinen Sommerurlaub verbracht und die Zeit zum Entspannen genutzt. 

















Kommen wir dann aber heute zum zweiten Teil über die PerformancePoint Services vom SharePoint Server 2010. Im ersten Teil habe ich einen Überblick im Allgemeinen gegeben. In diesem Teil werde ich den Dashboard Designer 2010 beschreiben und aufzeigen welche Möglichkeiten wir mit diesem Tool haben.

Was ist ein Dashboard?

Kurz und knapp gesagt: Ein Dashboard ist eine Sammlung/Übersicht von Unternehmensdaten, die mit Hilfe von Scorecards, KPI’s und Berichten dargestellt werden können. Der Benutzer greift über einen Webbrowser interaktiv auf die Daten zu und erhält die erforderlichen Informationen. Es kann eine Vielzahl an Elementen in einem Dashboard vorhanden sein. Das hängt von der Komplexität der zu darstellenden Informationen ab.

Was ist der Dashboard Designer?

PerformancePoint Dashboard-Designer ist ein in den PerformancePoint Services des Microsoft SharePoint Server 2010 enthaltenes Tool, mit dem Sie die Möglichkeit haben leistungsfähige Dashboards in Ihrem Unternehmen erstellen zu können. Die PerformancePoint Services sind Bestandteil der Enterprise Edition und müssen von Ihrem Administrator konfiguriert werden. Nachdem Sie die erforderlichen Berechtigungen zum Erstellen von Dashboards erhalten haben und den Dashboard Designer 2010 via ClickOnce Installation (Internetverbindung vorausgesetzt) installiert haben, stehen Ihnen die folgenden Funktionen zur Verfügung:
  • Erstellen von Datenverbindungen
  •  Erstellen von Berichten
  •  Erstellen von Filtern
  • Erstellen einer Dashboard-Seite
Was aber sind nun die Vorteile gegenüber den mit Microsoft Office Excel oder Diagramm-Webparts erstellten Übersichten. 
  • Wiederverwendbarkeit von Dashboard-Elementen
    • Speicherung in Listen und Bibliotheken
    • Zugriff für alle Dashboard-Autoren
  •   Drillup und Drilldown der Daten
    • sehr hohe Interaktivität möglich 
    • Abhängig von der Konfiguration und der Daten
  • Verknüpfung von Dashboard-Elementen mit anderen Berichten
    • Filter-Funktionalität
  • Zeitintelligenz-Funktionalität
    •  Auswahl der Zeiträume

Im nächsten Post, der hoffentlich nicht wieder so lange auf sich warten lässt, werde ich mich dann mit dem Erstellen eines Dashboards befassen.

Viele Grüße und viel Spaß,
Patrick