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