Nach den vielen Artikeln zur kommenden SharePoint-Version wird es Zeit wieder einmal in die Gegenwart zurückzukehren. Diese Gegenwart lautet ein in die Jahre gekommenes Produkt (Office SharePoint Server 2007) auf einem nagelneuen (Windows Server 2008 R2) zu installieren. Wie nicht anders zu erwarten, erfolgt dies leider nicht ganz friktionsfrei, greift doch SharePoint ziemlich tief in die IIS-Konfiguration ein. Aber keine Angst: Die Herausforderungen sind ziemlich einfach zu bewältigen, wenn man weiß wie.
Schritt 1: Server vorbereiten
Wie gewohnt ist der Windows Server 2008 R2 nach der Installation ziemlich “nackt”. Nach dem obligatorischen ersten Schritten (Computername und Domäne festlegen, Updates einspielen usw.) müssen daher Rollen und Features installiert werden.
Rollen
Zu installieren ist selbstverständlich die Webserver-Rolle am besten mit folgenden Rollendiensten:
- Allgemeine HTTP-Features
- Statischer Inhalt
- Standarddokument
- Verzeichnissuche
- HTTP-Fehler
- HTTP-Umleitung
- Anwendungswentwicklung
- ASP.NET
- .NET-Erweiterbarkeit
- ISAPI-Erweiterungen
- ISAPI-Filter
- Integrität und Diagnose
- Sicherheit
- Standardauthentifizierung
- Windows-Authentifizierung
- Anforderungsfilterung
- Leistung
- Komprimierung statischer Inhalte
- Verwaltungsprogramme
- IIS-Verwaltungskonsole
- IIS-Verwaltungsskripts und –tools
- IIS 6-Verwaltungskompatibilität
- IIS 6 WMI-Metabsiskompatibilität (die anderen IIS 6-Features können auch aktiviert werden, sind aber nicht nötig)
Features
Zu installieren ist das Feature .NET Framework 3.5.1 (überraschenderweise zu finden unter .NET Framework 3.5.1 Features).
Schritt 2: Installation
Die Installation von Office SharePoint Server 2007 ohne Service Pack wird wegen Kompatibilitätsgründen unter Windows Server 2008 R2 geblockt. Deshalb muss das Setup von einer Installationsquelle mit integriertem Service Pack erfolgen. Und so erzeugen wir eine solche Quelle:
- Komplette Office SharePoint Server 2007 Installationsdateien auf Festplatte kopieren.
- Inhalt des Ordners x64\Updates löschen.
- Windows SharePoint Services 3.0 SP2 und Office Servers SP2 herunterladen.
Achtung: Der Download von Office Servers SP2 sollte nicht älter als der 29. Juli 2009 sein.
- In einer Eingabeaufforderung die Service Packs extrahieren. Dies geschieht mit folgenden Befehlszeilenschaltern:
[ServicePackDatei] /extract:[Installationsdateipfad]\x64\Updates
- Wichtig: Aus dem x64\Updates-Ordner die Datei wsssetup.dll löschen.
Nun haben wir eine Installationsquelle mit integriertem Service Pack 2. Von dieser kann nun problemlos Office SharePoint Server 2007 auf einem Windows Server 2008 R2 wie gewohnt installiert werden.
Eine ausführlichere Anleitung dieser Schritte findet sich auch im SharePoint Team Blog.
Exkurs: Kerberos-Authentifizierung
Kerberos-Authentifizierung ist bei SharePoint ja traditionell ein heißes Thema. Wenn man Kerberos-Authentifizierung verwenden will oder muss, musste man einen sogenannten SPN zum Konto hinzufügen, unter dem der Anwendungspool lief. Aufgrund der Fehleranfälligkeit und dem spröden Charme eines Befehlszeilenutilities, das nicht einmal die Suche nach bereits registrierten SPN zuließ, war das nicht jedermanns Sache.
Beim IIS 7, der schon in Windows Server 2008 integriert war, entfällt diese Herausforderung, solange man die Kernel-basierte Windows-Authentifizierung aktiviert lässt. In diesem Fall erfolgt die Kerberos-Authentifizierung immer gegen das Computerkonto. Davon unbeeinflusst bleibt natürlich die Kerberos-Authentifizierung evt. Backend-Dienste (z. B. SQL Server).
Lange Rede kurzer Sinn: Vergessen Sie einmal das Thema SPNs für ihre Webanwendungen. Dafür kommt eine neue Herausforderung auf uns zu…
DCOM 10017-Fehler in der Ereignisanzeige bei Kerberos-Authentifizierung
Immer noch ein lästiges Problem sind die zahlreichen DCOM 10017-Fehler im System-Protokoll, sobald Kerberos-Authentifizierung verwendet wird. Dieses Problem wurde schon vor längerer Zeit im Microsoft Knowledge Base-Artikel 920783 beschrieben. Eine Lösung findet sich an eben dieser Stelle. Nur: Sie funktioniert unter Windows Server 2008 R2 nicht, und zwar aus dem schlichten Grund, weil man sie nicht so einfach implementieren kann.
Wie Wictor Wilén in seinem Blog beschreibt, ist der Grund dafür, dass der Trusted Installer der Besitzer eines Registrierungsschlüssels ist, auf den dann nicht einmal der Administrator Schreibzugriff hat (“sekier i di” [© Christian Schindler] lässt grüßen!).
Die Lösung ist zum Glück nicht besonders schwierig. Regedit aufrufen, den Schlüssel
HKEY_CLASSES_ROOT\AppID\{61738644-F196-11D0-9953-00C04FD919C1}
suchen und auf altbekannte Weise den Besitz übernehmen und der Gruppe Administratoren Vollzugriff gewähren.
Anschließend kann man wie im Knowledge Base Artikel beschrieben mittels dcomcnfg.exe für die DCOM-Anwendung IIS WAMReg Admin Service die lokalen Aktivierungsberechtigungen konfigurieren.
Und da noch ein ganz persönlicher Tipp: Microsoft empfiehlt ja, jedem einzelnen Anwendungspoolkonto hier einzeln die lokale Aktivierungsberechtigung zu geben. Das ist ziemlich mühsam, weil man dann bei jeder neu erstellten Webanwendung wieder die Konfiguration einstellen muss, sofern man meiner (und Microsofts) Empfehlung folgt und jede Webanwendung unter einem eigenen Konto laufen lässt. Daher mein Tipp: Einfach der lokalen Gruppe WSS_WPG die lokalen Aktivierungsberechtigungen geben. In diese Gruppe fügt SharePoint nämlich alle Anwendungspoolkonten für SharePoint-Webanwendungen automatisch hinzu. Dieser Tipp ist auch auf Windows Server 2003 und 2008 anzuwenden.
So, und jetzt viel Spaß mit Windows Server 2008 R2!