SharePoint 2013 installieren – Tipps für eine reibungslose Installation

SharePoint soll Einzug ins Unternehmen halten und wir haben die Aufgabe die Installation vorzunehmen. Das gibt uns Gelegenheit die SharePoint-Farm gleich von Anfang an so zu gestalten, dass wir eine sorgenfreie Zukunft haben. Leider gibt es auch mehr als eine Gelegenheit in Fallen zu laufen und uns das Leben in der Zukunft zu erschweren.

Wir wählen den sorgenfreien Weg.

 

Vorbereitung der Installation von SharePoint

Den SQL-Server gibt es schon, die VM für den SharePoint steht bereit, wir haben entsprechende AD-Accounts für den SharePoint und die Installationdateien haben wir uns schon bereitgelegt … und nun?

Da könnten wir schon die erste Falle haben: ist das SharePoint-Installationspaket englisch oder deutsch? Für den Fall, dass es sich um ein deutsches handelt, sollten wir dies zumindest stark überdenken und vielleicht doch lieber den SharePoint in Englisch nehmen und ein deutsches Language Pack dazu. Das liegt einfach daran, dass wir im Fall der Fälle wesentlich umfangreichere Informationen im Internet zu allen möglichen Dingen finden, wenn wir mit englischen Suchbegriffen arbeiten.

Deshalb: Lieber den englischen SharePoint mit deutschem Sprachpaket installieren.

Der eigentlichen SharePoint Installation geht die Installation der sog. Prerequisites voraus. Dies müssen wir nicht manuell machen, SharePoint bietet im Installer die entsprechende Möglichkeit dafür. Dabei werden u.a. Module nachinstalliert sowie die IIS-Rolle des Servers automatisch konfiguriert.

Achtung: Der Server muss dafür Internetzugang haben.

Nochmal Achtung: Mittendrin kann der Sever einen Neustart benötigen, den er beim Klick auf „Finish“ auch direkt durchführt, die Installation wird nach dem Restart fortgeführt.

 

Installieren von SharePoint 2013

Die eigentliche Installation des SharePoint kann losgehn und gleich am Anfang eine weitere Falle. Wir sollen uns entscheiden zwischen einer „Stand-alone“ und einer „Complete“ Installation. Besonders fies: Die Standardauswahl steht auf „Stand-alone“. Dieser Installationstyp macht so gut wie nie Sinn, nichtmal für eine Testumgebung, wie uns im Beschreibungstext der Installationstypen suggeriert wird.

Wir wählen auf jeden Fall die „Complete“ Installation.

Die Installation läuft, ohne dass wir dieser viel Beachtung schenken müssten. Doch die nächste Falle wartet schon auf uns. Nachdem der Installationswizard durchgelaufen ist, ist standardmäßig die Option im Anschluss den Konfigurationsassistenten zu starten aktiviert. Damit machen wir zwar nichts kaputt aber eine schöne Installation geht anders. Außerdem haben wir ja noch mindestens ein Language Pack, dass wir installieren wollen und vielleicht kommt ja noch das ein oder andere Service Pack oder CU dazu.

Wir installieren erstmal alle Language Packs, Service Packs und CUs und auch dabei laufen wir nicht in die Falle im Anschluss einer jeden Komponente den Konfigurationsassistenten zu starten.

Wir haben nun Alles installiert, SharePoint, Langauge Packs und so weiter. Zeit den Konfigurationswizard auszuführen? … NEIN!

Erstens: Wir mögen keine Wizards, wir gehen den Weg über die Powershell. Über den Wizard können wir nämlich den Namen der Datenbank für die Zentraladministration nicht beeinflussen. Die Datenbank bekommt als Namen eine zufällige GUID. Unsere SQL-Server Admins mögen so etwas nicht, zu Recht.

Zweitens: Wir müssen der SharePoint Farm einen SQL-Server geben. Genau da liegt eine weitere Falle. Wir könnten natürlich einfach den SQL-Servernamen nehmen und alles wär gut. Zumindest bis irgendwann ein neuer SQL-Server genutzt werden soll, oder eine andere Instanz. Dann stehen wir blöd da.

Wir richten zuerst ein SQL Alias auf dem SharePoint Server ein.

Dazu können wir entweder den SQL Configuration Manager verwenden, sofern dieser auf dem Server verfügbar ist, oder wir nehmen die entsprechenden Einstellungen über die „cliconfg.exe“ vor. Achtung: Von der „cliconfg.exe“ gibt es zwei, einmal in C:\Windows\system32 (32 Bit) und nochmal in C:\Windows\SysWOW64 (64 Bit). Wir hinterlegen unseren Alias in beiden. Analog würden wir im SQL Configuration Manager unseren Alias für 32 und 64 Bit eintragen.

Wenn sich nun der SQL-Server ändern sollte, passen wir einfach den SQL-Servernamen in unserem SQL-Alias an und alles ist gut.

 

Das Aufsetzen der SharePoint Farm

Der Weg ist geebnet für unsere SharePoint-Farm. Wir nutzen die Powershell dafür bzw. die SharePoint Management Shell. Achtung: Die SharePoint Shell starten wir als Admin. Nicht wundern, wenn uns die Shell mitteilt, dass die lokale Farm nicht erreichbar ist, das ist ok, es gibt ja noch keine.

Das cmdlet, dass wir nun brauchen heißt „New-SPConfigurationDatabase“. Wir könnten uns damit begnügen und die Powershell fragt die noch benötigten Parameter ab aber wir sind ein wenig höflicher und geben die Parameter gleich mit.

 

Achtung: Statt des DB-Servers geben wir den SQL-Alias an.

 

Nochmal Achtung: Als Farmaccount nehmen wir den eigens dafür eingerichteten AD-Account. Auf keinen Fall nehmen wir unseren oder irgendeinen anderen personalisierten Account.

New-SPConfigurationDatabase –DatabaseName “Our_SharePoint_ConfigDB” –DatabaseServer “<SQL Alias>” –AdministrationContentDatabaseName “Our_SharePoint_Admin_Content” –Passphrase (ConvertTo-SecureString “pass@word1” –AsPlaintext –Force) –FarmCredentials (Get-Credential)

 

Wir installieren die Hilfe-Dateien:

Install-SPHelpCollection –All

 

Wir aktivieren den Schutz für die SharePoint-Dateien und Registry Keys:

Initialize-SPResourceSecurity

 

Wir installieren die Dienste für die Farm:

Install-SPService

 

Gefolgt von den Features für die Farm:

Install-SPFeature –AllExistingFeatures

 

Wir erstellen die Zentraladministration, damit wird die Webanwendung mit der dafür im ersten Schritt definierten Datenbank verbunden (der Port kann durchaus anders gewählt werden, aber bitte keinen Standardport nehmen):

New-SPCentralAdministration -Port 1234  -WindowsAuthProvider "NTLM"

 

Last but not least installieren wir den Anwendungsinhalt:

Install-SPApplicationContent

 

Optional können wir nun noch den sog. „Loopback Check“ deaktivieren. Dieser Registry Key ist standardmäßig aktiviert und sorgt z.B. für Fehlermeldungen beim Aufruf von Webanwendungen vom Server aus, die auf den Server selbst verweisen.

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa

-Name "DisableLoopbackCheck" -value "1" -PropertyType dword

 

Herzlichen Grückwunsch, wir haben eine SharePoint Farm!

Nun können wir uns die Zentraladministration im Internet Explorer anschauen, wo dann direkt die nächsten Fallen lauern … im nächsten Blog.