SharePoint - Consulting-Team-Blog

28.08.2012

Bereitstellen von Office Web Apps in SharePoint 2013 (Preview)

Die Preview von SharePoint 2013 und vielen weiteren Produkten der Wave 15 sind seit kurzem verfügbar und es gibt viel Neues zu entdecken. Eine dieser Neuerungen sind die komplett überarbeiteten Office Web Apps, die nun als eigenständiges Server-Produkt installiert werden. In diesem Blogbeitrag zeige ich, wie man Office Web Apps bereitstellt und in SharePoint 2013 einbindet.

Installation von Office Web Apps

Als Umgebung für die Installation habe ich eine SharePoint 2013 Single Server Farm auf dem Server SRV-1, auf dem meine Webanwendung http://intranet.litware.com läuft. Zusätzlich gibt es den Server SRV-WAC, der unter der Url http://wac.litware.com die Office Web Apps bereitstellen soll.

Ein Überblick über diese kleinste mögliche Architektur:

Hier zeigt sich nun auch schon die wohl größte Änderung der Office Web Apps. Office Web Apps sind ein eigenes Server-Produkt und können nicht auf einem SharePoint Server installiert werden. Wer es dennoch probiert wird eine entsprechende Meldung auf den Bildschirm bekommen:

Also auf zur Installation auf meinem brandneuen Server SRV-WAC. Ohne weitere Vorbereitung wird mich auch hier von eine Fehlermeldung von der Installation der Office Web Apps abhalten:

Das sind sozusagen Systemvoraussetzungen, die erst erfüllt werden müssen, bevor die Office Web Apps 2013 installiert werden können. Leider gibt es an dieser Stelle keinen Prerequisites Installer, wie es ihn zum Beispiel für SharePoint gibt. Es müssen also alle Komponenten einzeln heruntergeladen und installiert werden. Zusätzlich zu den genannten Punkten müssen in meinem Windows 2008 R2 SP1 das Windows Update KB2592525 und einige Features installiert werden.

Hier die Links zu den benötigten Paketen:

.NET Framework 4.5 RC

Windows PowerShell 3.0

KB2592525

Die zusätzlichen Features können über die Windows PowerShell hinzugefügt werden:

“Add-WindowsFeature Web-Server, Web-WebServer, Web-Common-Http, Web-Static-Content, Web-App-Dev, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Includes, Web-Security, Web-Windows-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, Web-Mgmt-Console, Ink-Handwriting, IH-Ink-Support”

Mit dem Hinzufügen der benötigten Features sind nun alle Voraussetzungen für die Installation auf dem Server SRV-WAC erfüllt und mit dem Start der setup.exe aus dem Installationsordner der Office Web Apps kommt nach dem Begrüßungsbildschirm direkt die Lizenzvereinbarung.

Mit dem Akzeptieren der Lizenzvereinbarung geht es weiter zur Auswahl des Installationsverzeichnisses. Für produktive Umgebungen sollte hier ein Datenlaufwerk ausgewählt werden.

Nach der Auswahl des Installationsverzeichnisses und einem Klick auf “Install Now” kann man für eine recht kurze Zeit dem Fortschrittsbalken zuschauen.

Im Erfolgsfall gibt es nach wenigen Minuten nur noch folgendes Fenster zu sehen und damit sind die Office Web Apps auf diesem Server installiert.

Konfiguration der Office Web Apps

Mit Abschluss der Installation, kann nun die Konfiguration von Office Web Apps gestartet werden. Dazu wird die PowerShell auf unserem Office Web Apps Server benötigt.

“New-OfficeWebAppsFarm -InternalURL http://wac.litware.com -AllowHttp –EditingEnabled”

Mit diesem CmdLet erstellt man eine Office Web Apps Farm auf dem Server mit der angegebenen Url, ohne SSL-Verschlüsselung und mit der Möglichkeit, dass Dokumente bearbeitet werden können. Durch die Farm-Konfiguration bleibt die Möglichkeit, bei Bedarf weitere Server zur Farm hinzuzufügen. Auch die Parameter können den Bedürfnissen weiter angepasst werden, in dem beispielsweise auch eine externe Url mit SSL-Verschlüsselung erstellt wird oder die Bearbeitung deaktiviert wird, so dass diese Farm im lizenzfreien Lesemodus betrieben wird.

Zur Überprüfung der Farm kann nun mit http://wac.litware.com/hosting/discovery der Discovery-Dienst aufgerufen werden. Das sollte etwa so aussehen:

Zwei weitere CmdLets sind an dieser Stelle noch empfehlenswert:

New-OfficeWebAppsMachine - Ermöglicht auf weiteren Servern das Hinzufügen zur Farm

New-OfficeWebAppsHost – Legt Domänen fest, in der Server sein müssen, die den Office Web Apps Dienst nutzen dürfen. Im Standard dürfen Server jeder beliebigen Domäne angehören, sobald dieser Parameter gesetzt wird, erstellt man damit eine Art Whitelist.

Einbindung von Office Web Apps in SharePoint

Damit sind alle Schritte für eine funktionierende Office Web Apps Farm gemacht. Nun kann diese Farm in SharePoint 2013 eingebunden werden. Auch das geschieht wieder über CmdLets in der SharePoint PowerShell.

New-SPWOPIBinding -ServerName wac.litware.com –AllowHTTP

Set-SPWopiZone –zone “internal-http”

Das erste der beiden CmdLets erstellt eine Bindung an die Office Web Apps Farm. Dabei werden die Einstellungen von der Office Web Apps Farm, insbesondere die verfügbaren Dokumententypen, abgerufen. Anschließend wird noch die Zone festgelegt, so dass SharePoint bei der Konfiguration mit mehreren Urls auf der Office Web Apps Farm immer nur eine bestimmte Url anspricht bzw. an die Benutzer weiter gibt.

Nun sind alle Schritte getan, um Office Web Apps in SharePoint zu nutzen. So lassen sich nun verschiedene Dokumente direkt in einer Dokumenten Bibliothek erstellen.

Es gibt eine Vorschau in der Bibliothek…

…und auch die SharePoint 2013 Suche wird um eine Vorschaufunktion erweitert.

Das war’s mit Office Web Apps und SharePoint 2013 Preview und ich wünsche viel Spaß beim Nachbauen.

Bereitgestellt um 10:54 von René Dalkowski | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

16.03.2012

SharePoint 2010 Versionsnummern (Update)

Die ersten kummulativen Update Pakete für SharePoint 2010-Produkte sind veröffentlicht worden.

Nun beginnt also auch hier die Zeit, in der es nicht schaden kann, den Überblick über die entsprechenden Versionsnummern zu behalten.

Prüfen kann man die eigenen Versionnummern wie folgt (via Todd Klindt):

Farm
Central Administration > System Settings > Manage servers in this farm
(/_admin/FarmServers.aspx)
Komponenten
Central Administration > Upgrade and Migration > Check Product and patch installation status
(/_admin/PatchStatus.aspx)
Datenbanken
Central Administration > Upgrade and Migration > Review database status
(/_admin/DatabaseStatus.aspx)

Version	Updatepaket	Links
Version	Updatepaket	SharePoint Foundation	SharePoint Server	Project Server
14.0.6123.5002	Cumulative Update (CU) June 2012	KB2598373	KB2598354	KB2598355
14.0.6120.5006	Cumulative Update (CU) April 2012 Mark 2	KB2598321	KB2598151	KB2598152
14.0.6117.5002	Cumulative Update (CU) February 2012	KB2597132	KB2597150	KB2597152
14.0.6114.5000	Cumulative Update (CU) December 2011	KB2597058	KB2597014	KB2597015
14.0.6112.5000	Cumulative Update (CU) October 2011	KB2596508	KB2596505	KB2596506
14.0.6109.5002	Cumulative Update (CU) August 2011	KB2553048	KB2553049	KB2553050
14.0.6106.5002	Cumulative Update (CU) June 2011	KB2536601	KB2536599	KB2536600
14.0.6029.1000	Service Pack (SP) 1	Liste aller Pakete
14.0.5138.5001	Cumulative Update (CU) April 2011	KB2512804	KB2512800	KB2512801
14.0.5136.5002	Cumulative Update (CU) February 2011	KB2475880	KB2475878	KB2475879
14.0.5130.5002	Cumulative Update (CU) December 2010	KB2459125	KB2459257	KB2459258
14.0.5128.5000	Cumulative Update (CU) October 2010	KB2394323	KB2394320	KB2394322
14.0.5123.5000	Cumulative Update (CU) August 2010	KB2352346	KB2352342	KB2352345
14.0.5114.5003	Hotfix Packages June 2010	KB2028568	KB983497, KB2281364, KB2204024	KB2075990
14.0.4762.1000 14.0.4763.1000	Release to manufacturing (RTM)	SharePoint Foundation 2010 SharePoint Server 2010 Trial

Short-URL zu diesem Beitrag: http://bit.ly/sp2010builds

Bereitgestellt um 09:00 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

07.12.2011

Reporting über Daten in verknüpften SharePoint Listen

SharePoint Listen stellen eine einfache Möglichkeit dar, gemeinsam an tabellenartig darstellbaren Daten wie z.B. Projekten, Kunden oder dem Inventar, zu arbeiten. Über Microsoft Excel und Access lassen sich die Daten auch ganz vorzüglich auf dem Client auswerten.

Das Reporting über SharePoint Listendaten gestaltet sich jedoch unweit schwieriger, sobald Informationen aus anderen SharePoint Listen referenziert werden (Lookup-Werte/Nachschlagespalten).

Auswertung mit Excel

Bei der Auswertung von SharePoint Listen mit Hilfe von Microsoft Excel sind Pivot-Tabellen grundsätzlich ein hervorragendes Hilfsmittel. Als Datenquelle kann eine SharePoint-Liste dienen, mit deren Hilfe Daten und Auswertung on demand aktualisiert werden können.
Diese Methode ist bei Nachschlage-Feldern jedoch in zweierlei Hinsicht problematisch: Zum einen werden die Werte aus der “fremden” Liste im Format <Anzeigewert>;#<IDderNachschlageliste> angezeigt. Zum Anderen kann sich eine Pivot-Tabelle immer nur auch eine Datenquelle beziehen. Eine Auswertung über verknüpfte Daten gestaltet sich damit schwierig (z.B. mit Hilfe einer Mapping-Tabelle).

Auswertung mit Access

Auch Access kann die Daten aus einer SharePoint Liste beziehen und kann somit Auswertungen bereitstellen, die sich stets auf den aktuellsten Datenbestand beziehen.

Dabei bleiben die Daten und ihre Beziehungen erhalten, was den großen Vorteil birgt, das entsprechende Abfragen in SQL formuliert und ausgeführt werden können. Doch auch gibt es einen limitierenden Faktor: Wird die Ergebnismenge zu groß erreicht man schnell das Limit für die Anzahl an Nachschlagewerten und man erhält in der Folge überhaupt kein Ergebnis. Für einen größeren Datenbestand erscheint dieses Verfahren folglich ebenfalls ungeeignet.

Überführung der Daten in ein “Data Warehouse”

Für größere Datenbestände scheint es also überlegenswert, die Daten aus den SharePoint Listen in “echte” SQL Datenbanken zu überführen. Für diesen Ansatz lieferen die frei verfügbaren Microsoft SQL Server Community Samples: Integration Services das notwendige Werkzeug: SharePoint List Source and Destination. Diese Adapter ermöglichen es, SharePoint Listen in sog. SQL Server Integration Services (SSIS) “Data Flows” als Quelle und Ziel zu verwenden.

Damit ist es beispielsweise möglich, die Datenbeziehungen in Form von Tabellen, Primärschlüsseln und Relationen in einer SQL Server Datenbank zu definieren und regelmäßig mit Daten aus SharePoint zu befüllen (“Data Warehouse”). Die Ergebnismenge lässt sich dann mit Hilfe von Ansichten, gespeicherten Prozeduren, SQL Server Reports, SQL Server Analysis Services Datenquadern etc. etc. auswerten und visuell aufbereiten.

Bei dieser Variante hat stellt sich jedoch, analog zur Excel Methode, die Herausforderung, dass die einzelnen SharePoint Listen, Lookup-Werte als <Anzeigewert>;#<IDderNachschlageliste> zurückgeben. Zur Auflösung in “echte” IDs, die dann zur Defintion von Relationen verwendet werden können, kann dem SSIS Data Flow beispielsweise eine sog. “Derived Column Transformation” hinzugefügt werden, die zwischen SharePoint-Quelle und SQL Server-Ziel platziert wird und Transformationen vornimmet.

Beispielhaft sei die folgende Transformation genannt, die aus einem einzelnen Nachschlage-Wert die ID extrahiert:

(LEN(Kunde) == 0 ? NULL(DT_I4) : (DT_I4)(SUBSTRING([Kunde],1,(FINDSTRING([Kunde],";",1)) - 1)))

Diese Tranformation prüft, ob das Feld “Kunde” überhaupt einen Wert enthält. Für Nachschlage-Spalten handelt es sich bei den Werten um ein einfache Zeichenketten. Ist die Länge der Zeichenkette 0, soll eine SQL-NULL Information gespeichert werden. Anderfalls wird die Zeichenkette nach dem Trennzeichen “;” durchsucht und die entsprechende Teilzeichenkette, die die ID enthält, extrahiert und in Integer konvertiert. In der SQL Server Datenbank landet also nur die “echte” ID des Kunden.

Die SharePoint List Destination-Komponente scheint damit hervorragend geeignet, über einen Umweg detailierte Auswertungen über Informationen in verknüpften SharePoint Listen zu erstellen.

Bereitgestellt um 16:24 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

28.09.2011

SharePoint 2010 Inhaltsdatenbanken in PowerShell / Datenbankupgrades nach Patches

Verfügbare Cmdlets in PowerShell

Um die Inhaltsdatenbanken einer SharePoint-Farm mit Windows PowerShell abzufragen, stehen zwei unterschiedliche Cmdlets zur Verfügung:

Get-SPContentDatabase und
Get-SPDatabase

Nun könnte man davon ausgehen, dass der einzige Unterschied zwischen den beiden Varianten ist, dass die erstgenannte die Abfrage selbstständig auf Inhaltsdatenbanken beschränkt, während die andere alle Datenbanken zurückgibt. Nun, die Annahme, Get-SPDatabase lieferte alle Datenbanken stimmt immerhin. Leider liefert Get-SPContentDatabase nicht immer alle Inhaltsdatenbanken, wie im Folgenden ersichtlich werden soll. Darüber hinaus gibt es eine Reihe weiterer Parameter die sich unterscheiden, auf die in diesem Artikel aber nicht weiter eingegangen werden soll.

Die Unterschiede

Zuerst einmal betrachten wir die Ausgabe von Get-SPContentDatabase ohne Parameter (im abgebildeten Screenshot wird noch Transformation in eine Tabellendarstellung ausgeführt, um eine angenehmere Darstellung zu erhalten):

Clipboard01

Von Get-SPDatabase ist bereits bekannt, dass alle Datenbanken zurückgegeben werden, deswegen sollen diese direkt auf Inhaltsdatenbanken beschränkt werden:

Get-SPDatabase | ? {$_.Type –like '*Content*' }

Es fällt auf, dass hier auch die Inhaltsdatenbank der Zentraladministration angezeigt wird.

Der gravierende Unterschied wird aber deutlich, wenn man eine Datenbank anlegt, die, nachdem z.B. eine einzige SiteCollection dort platziert wurde, für weitere Site Collections nicht verwendet werden soll:

Nun führt man wieder die beiden verschiedenen Cmdlets aus:

Get-SPContentDatabase

Get-SPDatabase | ? {$_.Type –like '*Content*' }

Hier also der gravierende Unterschied: Während Get-SPDatabase Inhaltsdatenbanken, die keine weiteren SiteCollections aufnehmen können anzeigt, werden diese bei Get-SPContentDatabase nicht angezeigt!

Anwendungsbeispiel

Kommen wir nun zu einem praktischen Anwendungsbeispiel: Alle zwei Monate veröffentlicht Microsoft kummulative Update-Pakete für die SharePoint Produkte. Oftmals beheben diese weit verbreitete Probleme, sodass ein Großteil unserer Kunden diese Pakete ebenso regelmäßig installiert.

Jede Update-Installation macht die Ausführung des SharePoint Configuration Wizards erforderlich, durch dessen Routinen unter anderem die Änderungen an den Strukturen (Schema) der Datenbanken vorgenommen werden.

Leider ist vermehrt zu beobachten, dass der Configuration Wizard regelmäßig während der Upgrades der Inhaltsdatenbanken mit einer Fehlermeldung abbricht. Deshalb ist es empfehlenswert die Inhaltsdatenbanken vor dem Ausführen der Upgrades durch den Configuration Wizard abzuhängen. Bei sehr vielen Datenbanken kann man da schon einmal den Überblick verlieren, welche Inhaltsdatebank zu welcher Web-Applikation gehört und ob diese Datenbank gestoppt war oder nicht.

Deshalb möchte ich einen Weg aufzeigen, wie man diese Informationen von PowerShell erzeugen, sichern und wieder einlesen kann.

Nun haben wir ja gelernt, dass wir Get-SPDatabase verwenden sollten, um auch gestoppte Datenbanken zu erfassen. Diese Ausgabe passen wir so an, dass zusätzlich sowohl die entsprechende Web-Applikation-URL als auch der Status der Datenbank ausgegeben werden. Hierfür kann unter anderem Select-Object verwendet werden. Anschließend werden die Ergebnisse noch ohne Typeninformation in das CSV-Format konvertiert und ins Dateisystem geschrieben. Anschließend werden alle diese Datenbanken von den Web-Applikationen abgehängt.

$dbs = Get-SPDatabase | ? { $_.Type -like '*Content*' }
$dbs | Select-Object -Property Name,@{Name='WebApplication';Expression = {$_.Webapplication.Url}},Status | ConvertTo-Csv -NoTypeInformation | Out-File MyDBs.csv
$dbs | Dismount-SPContentDatabase

Im Anschluß an die Fertigstellung dieses Kommandos kann dann der Configuration Wizard ausgeführt werden.

Ist dieser erfolgreich durchgelaufen, wird die vorher erzeugte *.csv-Datei wieder eingelesen und jede einzelne Datenbank wieder an die usprüngliche Web-Applikation angehängt.

$mydbs = Import-Csv .\MyDBs.csv
$mydbs | ForEach-Object { Mount-SPContentDatabase -Name $_.Name -WebApplication $_.WebApplication }

Leider wird dabei nicht der ursprüngliche Status wiederhergestellt. Diesen muss man entweder manuell über die Zentraladministration erneut setzen oder z.B. das oben genannte Skript um die folgende Logik innerhalb des ForEach-Object Anweisungsblocks erweitern (hier exemplarisch für die Datenbank mit dem Index 2):

$mydbs[2].Status = "Disabled"
$mydbs[2].Update()

Bereitgestellt um 13:21 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

08.04.2011

SharePoint Health Rules mit PowerShell konfigurieren

Ein neues Feature in SharePoint 2010 ist der Health-Analyzer, der anhand vordefinierter Regeln regelmäßig überprüft, ob eine SharePoint-Farm z.B. den Konfigurations- und Sicherheitsemfehlungen gerecht wird.

Wird eine Abweichung festgestellt, wird man von der Zentraladministration durch einen gelben (Warnung) oder roten (Fehler) Balken darauf hingewiesen; z.B. so:

Wie schon der berühmte SharePoint Joel können auch wir nur empfehlen, diese Meldungen entweder ernst zu nehmen und die Behebung der Ursachen anzugehen oder aber sich bewusst dafür zu entscheiden, von den Empfehlungen abzuweichen und die entsprechenden Regeln zu deaktivieren. In keinem Fall sollte man jedoch eine gewisse Gleichgültigkeit gegenüber dem Health Analyzer-Baken entwickeln.

Soweit nichts Neues. Nun kommt das February CU von SharePoint 2010 ins Spiel: Durch dieses kumulative Update-Paket werden drei neue SharePoint-PowerShell Cmdlets bereitgestellt, die es erlauben, das Health-Monitoring via PowerShell zu konfigurieren.

Beispielsweise kann sich nun sehr einfach alle Regeln auflisten lassen: Get-SPHealthAnalysisRule

Natürlich lassen sich diese Cmdlets auch verknüpfen um zum Beispiel in einer reinen Entwicklungs- oder Testumgebung alle Regeln außer Kraft zu setzen:
Get-SPHealthAnalysisRule | Disable-SPHealthAnalysisRule

Ebenso kann auch eine einzelne Regel deaktiviert werden, z.B. die Frühwarnung bei zur Neige gehender Festplattenkapazität:
Disable-SPHealthAnalysisRule –Identity '35dec4ee-0747-47f0-8220-76bf5463c667'

In Verbindung mit anderen PowerShell-Cmdlets kann man auch die gesamte Regelkonfiguration dokumentieren: Beispielsweise sortiert nach Kategorie als HTML-Report:
Get-SPHealthAnalysisRule | Sort-Object Category | ConvertTo-Html | Out-File 'RulesReport.html'

Insgesamt bieten diese Cmdlets also gute Möglichkeiten, das Health-Monitoring automatisiert zu konfigurieren und/oder zu dokumentieren.

Bereitgestellt um 16:38 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

05.10.2010

SharePoint 2010 Cummulative Update, User Profile Service und Event ID 3

Viele haben mit der Release-To-Manufacturing (RTM) Version von SharePoint 2010 ihre neue Infrastruktur aufgesetzt und die gewünschten Dienste bereitgestellt. Wie zum Bespiel die User Profile Service Application, mit der unter anderem Benutzerinformationen aus dem Active Directory nach SharePoint synchronisiert werden können.

Die Fehlermeldung

Ebenso viele haben sich über die ersten Cummulative Update Pakete gefreut und diese installiert. Anschließend wird regelmäßig das Ereignis mit der Event ID 3 der Quelle Forefront Identity Manager im Ereignisprotokoll verzeichnet:

Microsoft.ResourceManagement.Workflow.Hosting.WorkflowManagerException: Forefront Identity Management Service does not support workflows of type 'Microsoft.ResourceManagement.Workflow.Activities.SequentialWorkflow, Microsoft.ResourceManagement, Version=4.0.2450.5

Die Ursache

Diese Fehlermeldung kommt daher, dass die Datenbankversion der User Profile Service Application Datenbank nicht zu den Versionen der durch das kummulative Update aktualisierten *.exe und *.dll-Dateien passt.

Die “Lösung”

Eine echte Lösung, die dazu führt, dass die Fehlermeldung nicht mehr erscheint ist, die User Profile Service Application zu löschen und neu zu erstellen. Dabei verliert man allerdings ALLE Daten, die der bestehenden Dienstapplikation zugeordnet sind (z.B. bestehende Benutzerprofile und Social Tag Daten).

Diejenigen, für die dieser Datenverlust und Aufwand nicht akzeptabel ist, werden sich über die offizielle Information von Microsoft (KB2432041) freuen, dass diese Fehlermeldung die Funktionalität der Synchronisierung nicht beeinträchtigt und gefahrlos ignoriert werden kann.

Bereitgestellt um 09:28 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

13.07.2010

Regelmäßiges SharePoint 2010 Farm-Backup mit PowerShell

Mit der Version 2010 von Micrsofoft SharePoint ist Windows PowerShell das Hauptverwaltungswerkzeug abseits der Zentraladministration. Und auch wenn die Backup-Funktionalitäten deutlich erweitert wurden, gibt es nach wie vor keinen built-in Mechanismus, um regelmäßig Backups zu erstellen. Microsoft empfiehlt, dieses Ansinnen mittels eines PowerShell Skripts umzusetzen.

Überblick

Folgende Dinge werden benötigt, um ein automatisiertes Backup mittels PowerShell einzurichten:

ein Benutzerkonto, dass nur für diesen Zweck verwendet wird. Dies ist zwar nicht zwingend erforderlich, jedoch sehr zu empfehlen.
eine Dateifreigabe, in der die Backup-Dateien gespeichert werden mit Zugriffsrechten (NTFS und Freigabe) für den ausführenden Benutzer, das Dienstkonto der SharePoint Zentraladministration und das Dienstkonto der SQL Server Datenbankengine.
ein PowerShell Skript, das ein Farm-Backup ausführt.
eine geplante Aufgabe (Scheduled Task) die den zeitgesteuerten Aufruf des Skripts übernimmt.

Benutzerkonto anlegen und erste Rechte vergeben

Das Benutzerkonto für die Ausführung des automatisierten Backups sollte als normaler Domänenbenutzer angelegt werden. Anschließend ist dieses Konto auf dem SharePoint-Server, der das Backup ausführen soll (in einer Farm sinnvollerweise ein Applikationsserver), der Gruppe der lokalen Administratoren hinzuzufügen.

Als nächstes ist das Benutzerkonto der Gruppe der SharePoint Farm-Administratoren hinzufügen. Dazu könn der entweder die Zentraladministration oder der folgende PowerShell-Befehl (in der SharePoint Management Shell) verwendet werden:

New-SPUser -UserAlias mydomain\mybackuser -Web https://myCA:12345 -Group 'Farm Administrators'

Zusätzlich benötigt der Benutzer noch das Recht, überhaupt Windows PowerShell zum administrieren der SharePoint Farm verwenden zu dürfen, sowie Zugriffsrechte auf die einzelnen Datenbanken. Diese Rechte vergeben die folgenden beiden Befehle:

Get-SPDatabase | Add-SPShellAdmin -UserName mydomain\mybackuser

Dateifreigabe anlegen

Für das Farm-Backup wird eine Dateifreigabe benötigt, in der die resultierenden Datei abgelegt werden können. Um die beste Performance zu erreichen, sollte die Dateifreigabe auf dem Datenbankserver angelegt werden. In unserem Beispiel Skript verwenden wir jedoch den Applikationsserver. Folgende Rechte müssen vergeben werden:

Lese- und Schreibberechtigungen für das Dienstkonto der SharePoint Zentraladministration (NTFS und Freigabe!)
Lese- und Schreibberechtigungen für das Dienstkonto, in dessen Kontext die entsprechende SQL Server Datenbankengine ausgeführt wird (NTFS und Freigabe!)
Lese- und Schreibberechtigungen für das das Backup-Skript ausführende Benutzerkonto (NTFS wenn Ausführungssystem und System das Freigabe hostet identisch, sonst NTFS und Freigabe. Sollen alte Backups gelöscht werden, dann auch Berechtigungen zum Löschen)

Backup PowerShell-Skript

Jetzt, da Berechtigungen und und andere Vorraussetzungen erfüllt sind, kann das eigentliche PowerShell Skript angegangen werden. Das folgende Skript lädt das benötigte Verwaltungsmodul, sofern es nicht bereits geladen ist, löscht alte Backups aus dem Zielverzeichnis und führt ein neuen Farm-Backup-Auftrag aus, der die maximale Anzahl an Threads verwendet (Standard: 3).

   001
002
003
004
005
 if ( (Get-PSSnapin -Name 'Microsoft.SharePoint.PowerShell' -ErrorAction SilentlyContinue) -eq $null) {
Add-PSSnapin -Name 'Microsoft.SharePoint.PowerShell' 
}
Remove-Item -Path 'D:\Backup\*' -Recurse
Backup-SPFarm -Directory '\\myappserver\Backup' -BackupMethod Full -BackupThreads 10 

Dieses Skript sollte als *.ps1 Datei im lokalen Dateisystem des Applikationsservers gespeichert werden, z.B. als C:\Program Files (x86)\Adminscripts\BackupSharePointFarm.ps1.

Die geplante Aufgabe

Im letzten Schritt ist nun noch die geplante Aufgabe anzulegen. Dabei sind folgende Punkte zu berücksichtigen:

Als ausführender Benutzer solte das eigens dafür erstellte Benutzerkonto konfiguriert werden.
Die Aufgabe ist so zu konfigurieren, dass sie unabhängig von der Benutzeranmeldung ausgeführt wird.
Ist die Benutzerkontensteuerung (User Account Control) aktiviert, ist das entsprechende Kontrollkästchen zu aktivieren, dass die Aufgabe mit erhöhten Rechten ausgeführt wird.
Als Aktion ist das Starten eines Programms zu konfigurieren und zwar
“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe”
Abschließend ist noch die folgende Zeichenkette von Argumente zu übergeben:
-ExecutionPolicy Bypass –File “C:\Program Files (x86)\Adminscripts\BackupSharePointFarm.ps1”

Die Intervalle können dabei selbstverständlich den eigenen Bedürfnissen angepasst werden. Sollen alte Backupstände nicht entfernt werden, kann im PowerShell-Skripte einfach die “Remove-Item”-Zeile entfernt oder auskommentiert werden.

Bereitgestellt um 16:18 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

21.05.2010

Migration: Zwei SharePoint Sites unter einer gemeinsamen URL ansprechen (Teil 2)

Hi Folks,

dies ist der zweite Teil der Blog-Artikel Serie zum Thema „Zwei SharePoint Sites unter einer gemeinsamen URL ansprechen“. In diesem Abschnitt werden nun die benötigten SharePoint- sowie Forefront TMG-Konfigurationsoptionen aufgezeigt, die benötigt werden, um einen Mischbetrieb eines SharePoint 2007 sowie 2010 unter einer gemeinsamen URL zu ermöglichen.

Die hier dargestellten Konfigurationsoptionen beziehen sich auf ein Szenario, in dem eine bestehende SharePoint 2007 Website um eine SharePoint 2010 Site-Collection (als Subsite) ergänzt werden soll. Die in diesem Blog-Artikel beschriebene Vorgehensweise kann jedoch auch als Grundlage (Herangehensweise, schaffen von virtuellen externen Pfaden) für einen beliebigen Mischbetrieb zweier SharePoint 2007 oder 2010 Websites verwendet werden.

Ach ja, für diejenigen Leser, die durch eine Suchmaschine direkt im zweiten Blog-Artikel gelandet sind und somit den ersten Teil verpasst haben: hier nochmal der Link zum ersten Teil, in dem die Hintergründe sowie Problemstellungen zur Thematik erklärt werden.

Teil 1: Hintergründe, Problemstellungen und Lösungsansätze zur Thematik

Teil 2: How-To: SharePoint 2007/2010 und TMG Konfigurationsoptionen

SharePoint AAM und DNS-Konfiguration

Um die beiden SharePoint Server über eine gemeinsame URL ansprechen zu können, müssen zunächst einmal die Anfragen zum bestehenden SharePoint Server auf den TMG umgelenkt werden. Hierzu müssen auf den SharePoint Servern entsprechende AAMs und in den DNS-Diensten die in der folgenden Abbildung dargestellten Einstellungen ausgewählt werden.

Abbildung: DNS, SharePoint AAM sowie SSL CNAME-Konfiguration

Durch die in der Abbildung dargestellte DNS und AAM-Konfiguration ist es möglich, beim Aufruf der URL https://portal.domain.de/* zum TMG Server geleitet zu werden. Dieser kann dann im Folgenden anhand der eingegebenen URL entscheiden, ob die Anfragen an den SharePoint 2010 (via FQDN portal2010.domain.de) oder SharePoint 2007 (via FQDN portal2007.domain.de) weitergeleitet werden. Ein entscheidender Punkt hierbei ist, dass der TMG entgegen der eindeutigen Namensauflösung beide SharePoint Server über den gemeinsamen AAM „portal.domain.de“ anspricht, in dem er innerhalb des http-Protokolls den originalen Hostheader des Clients weitergibt.

Für die SSL-Zugriffe zwischen den beteiligten Systemen und auch für die Client-Zugriffe verwende ich in dem Szenario jeweils ein und dasselbe SSL-Zertifikat. Als Ausgangspunkt sollte hierbei das Zertifikat verwendet werden, das bereits für die SharePoint 2007-basierte Website verwendet wird. In meinem Fall ist es ein Zertifikat mit dem Common Name CN=portal.domain.de. Die Verwendung von unterschiedlichen Namen innerhalb der Zertifikate ist ebenfalls möglich. Es sollte hierbei nur bedacht werden, dass der Client vom TMG Server ein passendes Zertifikat bekommt (übereinstimmend mit den DNS-Namen der Site) und dass der TMG von den jeweiligen SharePoint Servern ebenfalls ein passendes Zertifikat erhält (frei konfigurierbare Option innerhalb der jeweiligen TMG/ISA Regel).

Anmerkung: Die DNS-Umstellung und etwaigen AAM-Anpassungen können nach entsprechenden Tests der SharePoint 2007-Veröffentlichung durch den Forefront TMG im laufenden Betrieb erfolgen. Anzumerken ist auch, dass sich der Artikel im weiteren Verlauf ausschließlich auf den Zugriff über das BASIC Authentifizierung-Protokoll bezieht und hierbei ausschließlich auf die URL-Rewrite/Redirect-Thematik eingeht. Sollten Sie als Authentifizierungsprotokoll das NTLM- oder gar Kerberos-Protokoll für den Zugriff auf Ihren SharePoint Server verwenden wollen, sind zusätzliche Anpassungen innerhalb der Authentifizierungs-Methoden durchzuführen, die je nach SharePoint-Konfiguration wiederum abweichend sein können.

TMG-Konfiguration

Im TMG werden für das Szenario ein Web-Listener, eine Web-Veröffentlichungsregel für die bestehende SharePoint 2007 Website sowie zwei unterschiedliche Web-Veröffentlichungsregeln für die einzublendende SharePoint 2010 Website benötigt.

Abbildung: Benötigtes TMG-Regelwerk

Die drei Regeln werden beim Forefront TMG, genauso wie beim Vorgänger, von oben nach unten angewendet und haben in diesem Szenario die folgende Aufgaben:

Regel 1: Alles unterhalb von https://portal.domain.de/projects/site1/* zum SharePoint 2010 weiterleiten und hierbei /*.axd und /_layouts/*-Aufrufe im HTML Code mit der Link-Translation Server spezifisch codieren.

Regel 2: Alle serverspezifisch codierten /*.axd und /_layout/*-Aufrufe mit der Path-Redirection entsprechend decodieren und zum SharePoint 2010 weiterleiten. Hierbei werden ebenfalls weiterführende /*.axd und /_layouts/*-Aufrufe mit der Link-Translation codiert.

Regel 3: Alles unterhalb von https://portal.domain.de/*, was nicht bereits von Regel 1 und Regel 2 abgearbeitet wird, an den SharePoint Server 2007 weiterleiten.

Regel 1: SharePoint 2010 Veröffentlichung – /projects/site1/*-Verzeichnis

Die erste Web-Veröffentlichungsregel, die für das SharePoint-Szenario benötigt wird, veröffentlich die einzelne SharePoint 2010 Site Collection, die in die bestehende SharePoint 2007 Website eingeblendet werden soll. Im Folgenden werden die benötigten Konfigurationsoptionen aufgezeigt.

Anmerkung: Unbedingt drauf achten, dass die für die Publizierung der SharePoint 2010 Website benötigten Regeln nicht mit dem TMG-Assistenten für SharePoint Websites erstellt wurden. Der Assistent deaktiviert die für das Szenario benötigten Link-Translation-Funktionalitäten, so dass im Folgenden die Veröffentlichungen nicht ordnungsgemäß funktionieren würden. Anstelle dessen sollte der Assistent für herkömmliche SSL-Websites verwendet werden. Im Folgenden werden die einzelnen Konfigurationsoptionen dargestellt, die für das Szenario benötigt werden.

TMG-Konfiguration: Konfiguration des Web-Listeners

Im TMG wurde ein HTTPS-Listener angelegt, der den HTTPS-Endpunkt des Clients darstellt. In unserem Beispiel haben wir den HTTPS-Listener mit einem *.domain.de-Wildcard-Zertifikat versehen und die Anmeldemethode auf BASIC gesetzt. BASIC bietet eine einfache Methode, ein Single-Sign-On zwischen den Websites zu etablieren. In diesem Fall melden sich die Benutzer einmal am TMG an und dieser kann dann die übermittelten Anmeldedaten an die jeweiligen SharePoint Server weiterleiten.

Abbildung: TMG „Listener“-Konfiguration

TMG-Konfiguration: Konfiguration der URL und Path-Einstellungen

Der TMG wertet bei den einzelnen http-Anfragen den aufgerufenen HTTP-HOSTHEADER aus. Aus diesem Grund wurde in den Regelwerken jeweils der FQDN der Website auf portal.domain.de festgelegt.

Abbildung: TMG „Public Name“-Konfiguration

Die erste Regel veröffentlicht ausschließlich die gesamte Site-Collection /projects/site1/* und leitet den Pfad ohne Änderungen weiter. Es ist an dieser Stelle wichtig, dass an der URL-Struktur der Site Collection selbst keine Path-Redirects vorgenommen werden, da in diesem Fall elementare Funktionen der SharePoint Website nicht mehr funktionieren würden.

Abbildung: TMG „Paths“-Konfiguration

TMG-Konfiguration: Konfiguration des Zielservers

Auf dem „To“-Reiter wird unter „This portal rule applies to this published site:“ der FQDN portal.domain.de angegeben, um mit dem SSL-Zertifikat des SharePoint 2010 Servers übereinzustimmen. Und unter „Computer name or IP address” wird der FQDN portal2010.domain.de angegeben, um via DNS die Anfragen zum SharePoint 2010 Server zu leiten. Als weitere Option wurde das Häkchen unter „Forward the original host header instead of the acctual one” gesetzt.

Abbildung: TMG „To“-Konfiguration

TMG-Konfiguration: Konfiguration der Link Translation

Innerhalb der Site-Collection /projects/site1/* muss die Link-Translation aktiviert und konfiguriert werden, da diese ASPX-Dateien bzw. HTML Code enthält, in dem /*.axd und /_layouts/*-Ressourcen referenziert werden. Durch die Aktivierung und Konfiguration ist es möglich, die Pfad-Angaben zu diesen Ressourcen entsprechend zu codieren.

Abbildung: TMG „Link Translation“-Konfiguration

Die für das Publishing-Szenario benötigten Link-Translation-Regeln werden unten in der Grafik dargestellt. Wichtig ist hierbei, dass das Hochkomma (“) am Anfang der jeweiligen Werte unbedingt beachtet wird, da andernfalls die Link-Translation ebenfalls URLs codieren würde, die als Ziel eine Ressource innerhalb der Site-Collection hat. Bei Missachtung dieses Hochkommas würde zum Beispiel die legitime Pfadangabe /projects/site1/_layouts/* fälschlicherweise nach /projects/site1/www01root/_layouts/* ebenfalls übersetzt werden.

Abbildung: TMG „Locally Defined Mappings“-Konfiguration

Um die Link-Translation auf alle Elemente der SharePoint Website anwenden zu können, müssen im TMG noch Anpassungen an den Globalen Link-Translation-Einstellungen vorgenommen werden.

Abbildung: Angabe weiterer vom SharePoint Server verwendeten MIME-Types

In den Globalen-Link Translation-Einstellungen müssen die Inhaltstypen application/json und application/x-javascript angegeben werden, da für unser Szenario ebenfalls Links innerhalb dieser Inhalte ersetzt werden sollen.

TMG: SharePoint 2010-Veröffentlichung – /*.axd und /_layouts/*-Verzeichnisse

Die zweite Web-Veröffentlichungsregel, die für das SharePoint-Szenario benötigt wird, veröffentlich die codierten /*.axd- und /_layouts/*-Ressourcen des SharePoint 2010 Root Webs und stellt somit das Gegenstück zur Link-TranslationRegel der ersten Regel dar. Im Folgenden werden die benötigten Konfigurationsoptionen aufgezeigt.

Anmerkung: Auch bei dieser Regel sollte unbedingt drauf geachtet werden, dass die verwendeten Regeln nicht mit dem TMG-Assistenten für SharePoint Websites erstellt wurden. Als Hilfestellung können Sie die bereits erstellte erste Regel an dieser Stelle kopieren und als Grundlage für die Konfiguration der zweiten Regel verwenden.

TMG-Konfiguration: Web-Listener-Einstellungen

Für die zweite Regel wird der gleiche Web-Listener verwendet, der auch bei der ersten Regel zum Einsatz gekommen ist. Eine Rekonfiguration ist hierbei nicht notwendig, da alle drei Regeln eine identische Web-Listener-Konfiguration verwenden.

Abbildung: TMG „Listener“-Konfiguration

TMG-Konfiguration: Konfiguration der URL und Path-Einstellungen

Die zweite Regel reagiert ebenfalls ausschließlich auf den FQDN portal.domain.de.

Abbildung: TMG „Public Name“-Konfiguration

Auf dem Path-Reiter müssen die entsprechenden Gegenstücke zur Link-Translation konfiguriert werden. Die folgende Abbildung zeigt die benötigten internen sowie externen Pfade der Path-Regeln. Auch an dieser Stelle es ist wichtig, die genaue Schreibweise einzuhalten und hierbei insbesondere auf die Wildcard Characters (*) zu achten.

Abbildung: TMG „Paths“-Konfiguration

Wenn Sie versucht haben, die Schreibweise der oben dargestellten Abbildungen einzuhalten, erscheint eine Fehlermeldung, die in etwa besagt, dass eine Path-Regel, die sich im external Path auf ein einzelnes File (e.g. /ww01root/WebResource.axd) bezieht, nicht auf ein internes File (e.g. /WebResource.axd) gemappt werden kann und hierbei Wildcards (*) am Ende des Internal Path vergeben werden dürfen. Nun ja, es scheint hier eine gewisse Engstirnigkeit in der UI des TMG (als auch ISA Server 2004/6) vorzuliegen, was die Verwendung von Wildcards angeht.

Abbildung: Fehlermeldung durch zu restriktive UI Sanity Checks.

Fest steht jedenfalls, dass diese Wildcard unbedingt benötigt wird, um auch den Query-String, der am Ende der /WebResource.axd-Anfrage übergeben wird (e.g. / WebResource.axd?d=n0XTXF8j0sf...TXF8j0sf), zum SharePoint Server durchzureichen, und dass die TMG Web Proxy Engine (sowie auch ISA Server 2004/6) durchaus in der Lage ist, solche Regeln zu verarbeiten. Wo auch immer nun das Problem in der UI genau liegt; wir müssen zunächst einmal die Warnmeldung umgehen, indem wir als Erstes die Wildcards (*) innerhalb der Internal Path-Angabe entfernen. Im späteren Verlauf werden dann diese Wildcards über eine direkte Editierung der TMG-Regeldatenbanken hineingefügt.

TMG-Konfiguration: Konfiguration des Zielservers

Auf dem „To“-Reiter wird ebenfalls unter „This portal rule applies to this published site:“ der FQDN portal.domain.de angegeben, damit dieser mit dem SSL-Zertifikat des SharePoint 2010 Servers übereinstimmt. Und unter „Computer name or IP address” wird der FQDN portal2010.domain.de eingetragen, um via DNS die Anfragen zum SharePoint 2010 Server zu leiten. Als weitere Option wurde wiederum das Häkchen unter „Forward the original host header instead of the acctual one” gesetzt.

Abbildung: TMG „To“-Konfiguration

TMG-Konfiguration: Konfiguration der Link Translation

Auch innerhalb der /*.axd und /_layouts/*-Verzeichnisse muss die Link-Translation aktiviert und konfiguriert werden, da diese weiterführende JavaScript bzw. HTML Code enthält, in dem /*.axd- und /_layouts/*-Ressourcen referenziert werden.

Abbildung: TMG-„Link Translation“-Konfiguration

Für die zweite Regel werden die identischen Link-Translation-Regeln verwendet, die auch schon in der ersten Regel zu Anwendung kommen. Wiederum wichtig ist hierbei, dass das Hochkomma (“) am Anfang der jeweiligen Werte unbedingt beachtet wird, da andernfalls die Link-Translation ebenfalls URLs codieren würde, die als Ziel eine Ressource innerhalb der Site-Collection hat.

Abbildung: TMG „Locally Definied Mappings“-Konfiguration

TMG-Konfiguration: Manuelle Anpassungen der Regel über XML-Ex-/Importe

Nachdem die Regel ohne Warnmeldungen vervollständig wurde, geht es im Folgenden darum, die zwingend notwendigen Wildcards innerhalb der Path-Regeln anzulegen. Um dieses zu erreichen, werden zunächst einmal die Webveröffentlichungs-Regeln in XML-Form exportiert, anschließend mit einem Texteditor an den entsprechenden Stellen manipuliert und anschließend wieder importiert.

Abbildung: TMG-Regel-Ex-/Import

Nach dem Regel-Export kann die XML-Datei nach dem Schlagwort „.axd“ durchsucht werden, um die entsprechenden Regelabschnitte zeitnah auszufinden. Anschließend müssen die im unteren Screenshot blau markierten Werte mit einer Wildcard (*) ergänzt werden.

Abbildung: Manuelle Anpassungen der Regelwerke

Nach dem die Werte editiert wurden, kann die angepasste XML-Konfigurationsdatei anschließend wieder in die bestehende TMG-Regel importiert werden.

TMG: SharePoint 2007-Veröffentlichung – Root Web incl. aller Site Collections

Die Konfiguration der SharePoint 2007-Veröffentlichungsregeln ist an dieser Stelle nicht mehr weiter spannend, da im Grunde genommen diese Regel nichts mit der Link-Translation oder Path-Redirection der vorherigen Regeln zu tun hat. Die Aufgabe dieser Regel ist es lediglich, alle nicht definierten Anfragen zum bestehenden SharePoint 2007 Server zu leiten und von dort aus aufzurufen.

TMG-Konfiguration: Konfiguration des Web-Listeners

Auch für die dritte Regel wird der gleiche Web-Listener verwendet, der schon bei der ersten und zweiten Regel zum Einsatz gekommen ist. Eine Rekonfiguration ist hierbei wiederum nicht notwendig, da alle drei Regeln eine identische Web-Listene- Konfiguration verwenden.

Abbildung: TMG-„Listener“-Konfiguration

TMG-Konfiguration: Konfiguration der URL- und Path-Einstellungen

Die dritte Regel reagiert ebenfalls ausschließlich auf den FQDN portal.domain.de.

Abbildung: TMG-„Public Name“-Konfiguration

Auf dem Path-Reiter werden das gesamte Root-Web sowie alle Subsites mit der Angabe von /* veröffentlicht.

Abbildung: TMG-„Paths“-Konfiguration

TMG-Konfiguration: Konfiguration des Zielservers

Auf dem „To“-Reiter wird unter „This portal rule applies to this published site:“ der FQDN portal.domain.de angegeben, damit dieser mit dem SSL-Zertifikat des SharePoint 2007 Servers übereinstimmt. Unter „Computer name or IP address” wird der FQDN portal2007.domain.de verwendet, um via DNS die Anfragen zum SharePoint 2007 Server zu leiten. Als weitere Option wurde wiederum das Häkchen unter „Forward the original host header instead of the acctual one” gesetzt.

Abbildung: TMG-„To“-Konfiguration

TMG-Konfiguration: Konfiguration der Link Translation

Eine Link-Translation muss bei der SharePoint 2007-Regel nicht zum Einsatz kommen.

Abbildung: TMG-„Link Translation“-Konfiguration

Schlusswort

Soweit von mir zum Thema „Zwei SharePoint Sites unter einer gemeinsamen URL ansprechen“. Ich hoffe die in diesem Blog-Artikel enthaltenen Informationen haben Ihnen gefallen und Sie können dieses Wissen irgendwann einmal im eigenen Unternehmen einsetzen. Falls Sie Hilfe bei der Planung oder Implementation benötigen, können Sie sich wie gewohnt an mich oder andere ITaCS‘ler wenden.

Es grüßt der Kai

Bereitgestellt um 10:15 von Kai Wilke | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

10.05.2010

Migration: Zwei SharePoint Sites unter einer gemeinsamen URL ansprechen (Teil 1)

Hi Folks,

in dieser Blog-Artikel Serie möchte ich eine äußerst interessante Forefront TMG bzw. ISA Server-Konfiguration beschreiben, an der ich die letzten Tage gearbeitet habe. Und zwar wurde mir von unseren SharePoint Entwicklern eine Anfrage zugetragen, wie und vor allem ob man zwei unabhängige SharePoint Websites, die sich auf zwei unabhängigen Servern befinden, unter einer gemeinsamen URL zusammenfassen und ansprechen kann.

Da dieser Artikel etwas länger geworden ist, als geplant, habe ich mich entschieden, diesen Blog-Artikel in zwei Teile aufzuteilen. Der erste Teil beschreibt den Aufbau und die Problemstellungen, die mit dieser Konfiguration bewältigt werden müssen, der zweite Teil beschreibt die eigentlichen SharePoint 2007/2010 sowie Forefront TMG Konfigurationsoptionen.

Teil 1: Hintergründe, Problemstellungen und Lösungsansätze zur Thematik

Teil 2: How-To: SharePoint 2007/2010 und TMG Konfigurationsoptionen

Hintergrund

Bei der Anfrage unserer Entwickler ging es zum einen um ein spezielles Kundenprojekt bei dem es vorteilhaft wäre, zwei bestehende SharePoint Websites unter einer gemeinsamen URL zu konsolidieren, ohne hierbei Anpassungen an den bestehenden Sites vornehmen zu müssen. Und zum anderen erhofften sich unsere SharePoint-Entwickler eine unkomplizierte und universell einsetzbare Methode, um eine fließende Migration unterschiedlicher SharePoint Site-Collections von einem Server auf den anderen vornehmen zu können, ohne hierbei zwei unterschiedliche URLs an die User kommunizieren zu müssen. Die Methode sollte idealerweise auch geeignet sein, um einen Mischbetrieb eines SharePoint 2007 sowie 2010 unter einer gemeinsamen URL zu ermöglichen.

Abbildung: URL Routing zwischen zwei unterschiedlichen SharePoint Sites

Im ersten Moment wollte ich meinen Kollegen sofort mit einem klaren „Nein, geht nicht.“ antworten, da ich schon in vergangenen Projekten auf Limitationen beim partiellen publizieren und URL-Rewrite/-Reroute von SharePoint Sites gestoßen bin, die im direkten Zusammenhang mit dieser Anfrage standen. Aber dann packte mich der Forscherinstinkt und ich habe meinen Kollegen zugesagt, die Machbarkeit doch noch einmal zu prüfen.

Problembeschreibung

Eine SharePoint Site Collection beinhaltet nicht nur Webinhalte unterhalb ihrer eigenen Base-URL (e.g. /projects/site1/*), sondern auch viele statische (e.g. CSS, HTML und JavaScripts im /_layouts/*-Verzeichnis) sowie dynamische Webinhalte (e.g. /*.axd AJAX Handler) unterhalb des SharePoint Root-Webs. Wenn man nun zwei unterschiedlich konfigurierte SharePoint-Installationen, oder gar unterschiedliche Versionen des SharePoint Servers unter einer gemeinsamen URL zusammenfassen möchte, dann müsste man erst einmal die Entscheidung treffen, welches /_layouts/*-Verzeichnis und welche /*.axd AJAX Handler verwendet werden sollten, da die externen URLs nur einmalig zu einem bestimmten internen Server weitergeleitet werden können.

Abbildung: Probleme bei doppelten SharePoint /_layouts/* Sub-Webs

Bei einer Zusammenfassung zweier SharePoint Server innerhalb einer SharePoint Webfarm sollte es „theoretisch“ nur geringe Probleme geben, da es hierbei in Grunde genommen egal wäre, über welche SharePoint Site die AJAX Ressourcen abgerufen werden. Bei der Verwendung von gänzlich unterschiedlichen Webfarmen oder gar von unterschiedlichen SharePoint Versionen würde diese Vorgehensweise jedoch nicht mehr funktionieren, da die /*.axd AJAX Handler oder das /_layouts/*-Verzeichnis gänzlich andere Informationen beinhalten und somit die Website im besten Fall etwas komisch aussehen würde oder im schlimmsten Fall aufgrund der unterschiedlichen JavaScript Inhalte überhaupt nicht mehr bzw. nur noch teilweise funktionieren würde.

Bild: Fehlerhafte SharePoint Website durch fehlerhaftes Routing des /_layouts/*-Verzeichnisses

Lösungsansatz

Ich habe mir für dieses Problem einen Lösungsansatz überlegt, der es mir ermöglicht, die in der Problemstellung beschriebenen AJAX und /_layouts/*-Anfragen eindeutig pro Server abzuändern, so dass es möglich ist, zwei unabhängige AJAX Handler und /_layouts/*-Verzeichnisse über eine URL anzusprechen. Der Ansatz, den ich mir überlegt habe, sieht vor, dass ich die benötigten Anpassungen nicht auf den SharePoint Servern selbst durchführe, sondern ausschließlich mit Hilfe der ISA/TMG „Link-Translation“ und „Path-Redirection“ Features den HTTP-Datenstrom auf dem Hin- und Rückweg zwischen dem Client und dem ISA Server abändere bzw. umlenke.

Mein Workaround sieht vor, dass die URLs Aufrufe zu den SharePoint 2010 /*.axd AJAX Handlern und dem /_layouts/*-Verzeichnis zunächst einmal mit Hilfe der ISA/TMG „Link-Translation“ serverspezifisch im Quelltext codiert werden (e.g. das /_layouts/*-Verzeichnis des Servers WW01 wird durch /ww01root/_layouts/* ersetzt) bevor sie zum Client gesendet werden.

Abbildung: Codierung von unterschiedlichen /_layouts/*-Verzeichnissen mit der ISA/TMG Link-Translation

Auf dem Rückweg vom Client wird die eingebaute Codierung mit Hilfe der „Path-Rules“ wiederum ausgewertet und anhand der Codierungsinformationen die Anfragen zu den entsprechenden SharePoint Servern via „Path-Redirection“ weitergeleitet (e.g. der externe Path /ww01root/_layouts/* wird zum Server WW01 nach /_layouts/* umgeleitet).

Abbildung: Auswertung der Codierung und anschließenden Path-Redirection zum Zielserver

Mein Lösungsansatz sah hierbei vor, die HTML Link-Translation und HTTP Path-Redirects ausschließlich auf die Inhalte und Anfragen des SharePoint 2010 anzuwenden und diesen somit quasi in eine bestehende SharePoint 2007-Installation einzublenden, ohne eine einzige Anpassung an dem bestehenden Content vornehmen zu müssen (eine Cross-Verlinkung der beiden Sites mal außen vorgelassen).

Nach mehrstündigem Debuggen der SharePoint-Funktionalitäten mittels Fiddler2, TMG Logs und manueller HTML/CSS/JavaScript Source Code-Analyse habe ich es letztendlich geschafft, ein TMG-Regelwerk aufzustellen, das es mir ermöglicht, eine SharePoint 2010 Site Collection innerhalb einer bestehenden SharePoint 2007 Website unter Verwendung der gleichen URL quasi einzublenden. Die meisten Kopfschmerzen hat mir hierbei der neue SharePoint 2010 Kalender und die neue Ribbon-Leiste bereitet, welche vollständig auf AJAX, JSON und JavaScript basiert und darüber hinaus URLs in HTML-Codierter Form beinhaltetet. Ein weiteres Problem, das mir beim Erstellen des Regelwerks begegnet ist, war, dass die ISA/TMG GUI zunächst einmal an ihre Grenzen gestoßen ist und man die benötigten Regeln ausschließlich über eine manuelle Anpassung der Konfigurationsdaten via XLM oder ADSI Edit erzeugen konnte – doch dazu später mehr.

Letztendlich bin ich sehr zuversichtlich, dass ich jegliche SharePoint-Funktionalität (incl. Outlook Integration, Webdav und Singel-Sign-On zwischen den einzelnen Sites) zum Laufen bekommen habe.

Abbildung: Fehlerfreie SharePoint Websites durch selektives Routing der /_layouts/*-Verzeichnisse

Im zweiten Teil dieser Blog-Artikel-Serie werde ich die benötigten SharePoint- sowie ISA/TMG-Konfigurationsoptionen aufzeigen, die benötigt werden, um eine einzelne SharePoint 2010 Site Collection innerhalb einer bestehenden SharePoint 2007 Website einzublenden.

Es grüßt der Kai

Bereitgestellt um 12:46 von Kai Wilke | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

23.10.2009

Neue ITaCS SharePoint Post Installation Tool (PIT) Version 0.6 veröffentlicht

Gut ein Jahr nach der Veröffentlichung der Version 0.5 des ITaCS SharePoint Post Installation Tools (PIT) freuen wir uns, die Verfügbarkeit der neuen Version bekannt zu geben.

Das ITaCS SharePoint Post Install Tool ist eine Windows Anwendung, die die häufigsten Konfigurationsänderungen und Fehlerbehebungen, die im Rahmen einer Microsoft Office SharePoint Server 2007 oder Windows SharePoint Services 3.0 Bereitstellung anfallen, automatisiert.

Neben einer komplett überarbeiteten Benutzeroberfläche zeichnet diese Version vor allem die Unterstützung des neuen Server Betriebssystems Windows Server 2008 R2 und die automatische Registrierung von IFiltern für die Office Server Suche aus.

Die Version 0.6 kann ab sofort kostenfrei heruntergeladen werden: http://pit.codeplex.com

Highlights der Version:

Unterstützung von Windows Server 2008 R2
überarbeitete Benutzeroberfläche
Konfiguration der Office Server Suche
- Registrieren von IFiltern
- Hinzufügen von Dateitypen
- Ändern des Download-Limits des Search-Crawlers
Erteilen von DCOM Berechtigungen
Vordefinition von Site-Collection Quotas
LoopbackCheck deaktivieren
Komprimierung für Logdatei-Ordner

Bereitgestellt um 11:21 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

1 - 10