21.3    SharePoint-Server-Installation

Nachdem Sie den SQL-Alias konfiguriert haben, starten Sie die eigentliche Installation von SharePoint 2016:

Abbildung 21.4    Start der SharePoint-2016-Installation

Zunächst muss der Product Key eingegeben werden. Hier ist es wichtig, dass Sie den Schlüssel für die Enterprise-Lizenz eingeben, da dieser von Project Server benötigt wird.

Abbildung 21.5    SharePoint-Server-2016-Installation: Product Key

Als Nächstes folgt die Lizenzvereinbarung.

Abbildung 21.6    SharePoint Server-2016-Installation: Lizenzbedingungen

Die einzige Option, bei der Sie tatsächlich etwas auswählen können bzw. müssen, ist der Dateispeicherort. Vorgeschlagen wird hier das Laufwerk C:. Wenn Sie mehr als eine Partition auf Ihrem Applikationsserver haben, sollten Sie hier gegebenenfalls eine andere Partition wählen. Die Verzeichnisse sollten aber auf allen Servern der Farm so existieren. Wenn Sie also den Index auf ein Laufwerk D: legen wollen, sollte es auf jedem Applikationsserver ein Laufwerk D: geben.

Abbildung 21.7    SharePoint-Server-2016-Installation: Dateispeicherort

Nach Durchlauf der Installation folgt die Aufforderung, den SharePoint-Konfigurations-Assistenten auszuführen.

Abbildung 21.8    SharePoint Server-2016-Installation: Abschluss

21.3.1    Konfigurations-Assistent

Da Sie die Ausführung des SharePoint-Konfigurations-Assistenten eben ausgewählt haben, startet dieser automatisch. Sollte dies nicht der Fall sein, findet er sich auch im Startmenü beziehungsweise der App-Liste.

Nach der Bestätigung der Lizenzbedingungen haben Sie zunächst die Wahl, ob Sie eine neue Farm erstellen oder einer vorhandenen Farm beitreten wollen. Falls die Farm aus mehreren Servern bestehen soll, würden Sie auf dem ersten Server die Farm installieren und dann auf den weiteren Servern der Farm beitreten.

Abbildung 21.9    Konfigurations-Assistent (1)

Abbildung 21.10    Konfigurations-Assistent (2)

Nun konfigurieren Sie die Verbindung zur neu zu erstellenden Konfigurationsdatenbank. Dies ist die zentrale Datenbank der Farm, in der die Konfigurationsinformationen (Server, Service-Konten etc.) gespeichert werden. Falls ein SQL-Alias verwendet wird, geben Sie diesen hier als Servernamen an. Als Benutzername geben Sie das Konto an, das Sie als Farmkonto verwenden wollen.

Abbildung 21.11    Konfigurations-Assistent (3)

Im nächsten Schritt wird eine sogenannte Passphrase für die Farm erstellt. Diese wird später benötigt, wenn weitere Server der Farm beitreten wollen. Die Passphrase kann später aber auch noch geändert werden.

Abbildung 21.12    Konfigurations-Assistent (4)

Nun erfolgt die Abfrage, welche Serverrolle für diesen Server gewählt werden soll (MinRole). Für unser System wählen wir hier Einzelserverfarm.

Abbildung 21.13    Konfigurations-Assistent (5)

Bei der Ausführung auf dem ersten Server wird die Webanwendung für die SharePoint-Zentraladministration erstellt. Der Port, unter dem sie später erreichbar ist, wird zufällig gewählt, kann aber auch geändert werden. Üblicherweise ruft man die Zentraladministration meist vom Server aus über das Startmenü (bzw. die Apps-Seite) auf, und der Port ist daher unerheblich. Wenn man die Seite aber auch von seinem Arbeitsplatz aus aufrufen können möchte, ist ein einfacher zu merkender Port zu empfehlen. Die vorgeschlagene NTLM-Authentifizierung können Sie beibehalten, wenn nicht erhöhte Sicherheitsanforderungen dagegensprechen.

Abbildung 21.14    Konfigurations-Assistent (6)

Die gewählten Einstellungen werden jetzt noch einmal zur Kontrolle angezeigt. Wenn nichts dagegenspricht, können Sie die Farm erstellen lassen.

Abbildung 21.15    Konfigurations-Assistent (7)

Das dauert nun einige Zeit. Sie können sich in Ruhe einen Kaffee holen und vermutlich auch austrinken. Nach einiger Zeit erhalten Sie vermutlich eine Erfolgsmeldung.

Damit haben Sie eine leere Farm erstellt. Wenn Sie dieses Fenster schließen, startet als Nächstes ein Internet-Explorer-Fenster, und es öffnet sich die SharePoint-Zentraladministration.

Abbildung 21.16    Konfigurations-Assistent (8)

21.3.2    Konfiguration der Farm über die Zentraladministration

Die Zentraladministration begrüßt Sie zunächst mit der Frage, ob Sie am Programm zur Verbesserung der Benutzerfreundlichkeit teilnehmen wollen.

Dann werden Sie gefragt, ob Sie die Farm manuell oder mithilfe eines Assistenten konfigurieren wollen. Wir machen uns das Leben zunächst einmal einfach und wählen den Assistenten.

Abbildung 21.17    Startbildschirm der SharePoint-Zentraladministration

Dann stellt sich die Frage, unter welchem Konto die Dienste der Farm laufen sollen und welche Dienste Sie wünschen. Als Benutzerkonto fügen Sie der SharePoint-Farm das Dienstkonto hinzu.

Abbildung 21.18    SharePoint-Zentraladministration: Farmkonfiguration (1)

Nun wählen Sie die Dienste aus, die Sie benötigen:

• App-Verwaltungsdienst: Wird benötigt, um SharePoint-Apps entweder aus dem App-Katalog oder manuell hinzufügen zu können.
• Benutzerprofildienst-Anwendung: Synchronisiert Benutzerinformationen aus dem Active Directory nach SharePoint und ist Voraussetzung für persönliche Websites (MySites).
• Business Data Connectivity-Dienst
• PerformancePoint Service-Anwendung: Reporting und Dashboard-Funktionalitäten
• Project Server-Dienstanwendung: Stellt den Project Server Webservice sowie Warteschlangen-, Ereignis- und Berechnungsdienst bereit.
• Sammlung von Verwendungs- und Integritätsdaten
• Secure Store Service: Single-Sign-On-Anwendung
  

  Abbildung 21.19    SharePoint-Zentraladministration: Farmkonfiguration (2)

  

  Abbildung 21.20    SharePoint-Zentraladministration: Farmkonfiguration (3)

• Statusdienst: temporäre Speicherung von Benutzersitzungs-Informationen
• Suchdienstanwendung: Indiziert Inhalte und stellt Suchergebnisse bereit.
• Verwalteter Metadatendienst: Dieser Dienst bietet Zugriff auf verwaltete Taxonomiehierarchien, Schlüsselwörter und die Infrastruktur von Communitytags sowie websitesammlungsübergreifende Inhaltstypveröffentlichung.
• Workflowdienstanwendung: Wird benötigt, damit Project Server Workflows verwenden kann.
  

  Abbildung 21.21    SharePoint-Zentraladministration: Farmkonfiguration (4)

Bei der Auswahl der auszuführenden Dienste können Sie die vorgeschlagenen Dienste (die sich auch nicht deaktivieren lassen) übernehmen.

• Ansprüche an den Windows-Tokendienst (Claims to Windows Token Service)
  

  Abbildung 21.22    SharePoint-Zentraladministration: Farmkonfiguration (5)

• SharePoint Foundation-Workflowtimerdienst
• Verteilter Cache

Abbildung 21.23    SharePoint-Zentraladministration: Farmkonfiguration (6)

Nach einem Klick auf Weiter ist es dann wieder Zeit für eine Pause …

Nach der Auswahl der Dienste für die Farm erfolgt die Frage nach der Erstellung der ersten Websitesammlung für die SharePoint-Webanwendung. Sie erhält einen Titel und eine Vorlage.

Abbildung 21.24    SharePoint-Zentraladministration: Farmkonfiguration (7)

Dann folgt eine Zusammenfassung der ausgewählten Konfiguration für die Dienste und die Webanwendung.

Abbildung 21.25    SharePoint-Zentraladministration: Farmkonfiguration (8)

Kurz darauf ist die SharePoint-Zentraladministration für die weiteren Konfigurationsarbeiten bereit.

Abbildung 21.26    SharePoint-Zentraladministration: Farmkonfiguration (9)

Auf einer zweiten Registerkarte geben wir die URL für unsere Website ein, hier »http://prjsrv1«. Es wird etwas dauern, aber nach ca. 30 bis 60 Sekunden sehen wir unsere SharePoint-Website.

Abbildung 21.27    SharePoint-Teamsite

Sie haben nun zwar eine SharePoint-Website erstellt, aber von Project Server ist noch nichts zu erkennen. Starten Sie daher die SharePoint-Zentraladministration, und navigieren Sie zu Anwendungsverwaltung • Dienstanwendungen verwalten. Hier finden Sie die Project-Server-Dienstanwendung. Wenn Sie auf diese klicken, erhalten Sie eine Übersicht über die zu verwaltenden Project Web Apps.

Abbildung 21.28    Project-Server-Dienstanwendung verwalten

Nun ist diese Liste leer, und wie Sie sehen, kann man hier auch keine erzeugen. Project Server wurde im Vergleich zur Vorversion 2013 zwar technisch weiter in SharePoint integriert, aber dafür wurde »zum Ausgleich« das Erstellen von neuen Project Web Apps in die SharePoint Management Shell verbannt. Allerdings macht man das ja auch nicht so häufig, sodass man damit sicher leben kann.

Öffnen wir also eine SharePoint Management Shell mit administrativen Rechten.

Hier haben wir jetzt zwei Möglichkeiten. Entweder erstellen wir eine neue Websitesammlung mit Project Web App, oder wir aktivieren das Feature in einer bestehenden Websitesammlung.

Beide Varianten stellen wir hier vor. An dieser Stelle aber der Hinweis, dass die zweite Variante zum Zeitpunkt der Veröffentlichung dieses Buches nicht sauber funktioniert, sondern ein Problem aufweist. Wir empfehlen daher, die erste Variante zu verwenden.

Im ersten Fall verwenden wir den Befehl new-spsite:

new-spsite -url http://prjsrv/websites/pwa1 -template pwa#0 -owneralias airbi\farmadmin -secondaryowneralias airbi\administrator

Das genügt aber noch nicht. Im zweiten Schritt müssen wir für diese Websitesammlung noch das Project Web App Feature aktivieren:

Enable-SPFeature pwasite -url http://prjsrv/websites/pwa1

Wenn wir das allerdings versuchen, schlägt das fehl. An dieser Stelle schlägt nämlich die Lizenzprüfung zu. Bisher haben wir nur einen Lizenzschlüssel für SharePoint Server eingegeben. Damit stehen auch durchaus einige Elemente zur Verfügung, die nach Project Server aussehen. Wenn man aber wirklich damit arbeiten will, braucht man einen entsprechenden Lizenzschlüssel. Wir aktivieren also die entsprechende Lizenz mittels:

Enable-ProjectServerLicense –Key Lizenzschlüssel

Nun können wir auch erfolgreich das PWA-Feature aktivieren.

Abbildung 21.29    Erstellen einer neuen Websitesammlung mit PWA

Und wir finden nach Aufruf der URL auch eine Project-Web-App-Website vor:

Abbildung 21.30    Project-Web-App-Website

Nun kann man in der Version 2016 auch Project Web App in einer bestehenden Websitesammlung aktivieren. Das wollen wir nun ausprobieren. Oben haben wir ja schon mithilfe des Assistenten in der Zentraladministration eine SharePoint-Websitesammlung als sogenannte Root Website erstellt (URL: http://prjsrv). An der Stelle findet sich im Moment eine reine SharePoint-Teamsite, die keine Project-Features kennt. Das ändern wir durch Aktivieren des entsprechenden Features für die Websitesammlung:

Abbildung 21.31    Aktivieren des PWASite-Features in bestehender Websitesammlung

Nun rufen wir diese Website auf und reiben uns verwundert die Augen. Da ist wohl etwas aktiviert worden – wir finden tatsächlich PWA-Einstellungen im SharePoint-Menü. Aber ansonsten sieht das nicht sehr nach Project Web App aus.

Das liegt daran, dass diese Website ja schon existierte und bei der Erstellung der Website nicht die entsprechende Vorlage für Project Server ausgewählt wurde. Dadurch fehlen nun die entsprechenden Elemente in der Website. Die Lösung dieses Problems besteht darin, dass in der Websitesammlung eine neue Unterwebsite mit der richtigen Vorlage erzeugt wird.

Abbildung 21.32    Websitesammlung mit PWASite-Feature

Abbildung 21.33    Erstellen einer neuen PWA-Website in einer vorhandenen Websitesammlung

Und tatsächlich erhalten wir so eine neue PWA-Website /pwa, welche sich in der Websitesammlung / befindet.

Abbildung 21.34    PWA-Website in bestehender Websitesammlung

Oben hatten wir erwähnt, dass diese Methode aktuell ein Problem aufweist. Vermutlich wird dieses zu einem späteren Zeitpunkt gelöst. In der RTM-Version werden Sie aber eine Fehlermeldung erhalten, wenn Sie auf den Link Berichte im Schnellstartmenü von Project Server klicken. Der Fehler kommt, weil kein ProjectBiCenter (eine automatisch erstellte Subsite für das Berichtswesen in Project Server) gefunden wird. Gemäß den aktuell vorliegenden Dokumentationen soll man den Befehl upgrade-SPProjectWebInstance ausführen. Dieser Teil der Dokumentationen stammt aber noch aus Vorabversionen, und der Befehl ist in der RTM-Version nicht verfügbar. Es gibt einen alternativen Befehl repair-spprojectwebinstance, der auch noch nicht vollständig dokumentiert ist. Er scheint aber derzeit (Stand Juli 2016) auch noch kein Mittel zur Lösung dieses Problems zu sein.

In der SharePoint-Zentraladministration finden wir nun unsere beiden Project Web Apps vor:

Abbildung 21.35    Project Web Apps in der Zentraladministration

21.3.3    Das Project-Server-Datenbankmodell

Die Datenhaltung von Project Server hat sich in der Version 2016 erneut geändert. Aus einem Satz von je 4 Datenbanken je Project-Server-2007-/2010-Instanz wurde in der Version 2013 eine gemeinsame Datenbank.

In der Version 2016 wurde auch die Datenbank »eingespart«. Die Project-Server-Inhalte sind in die entsprechende SharePoint-Inhaltsdatenbank integriert worden. In dieser finden sich jetzt die SharePoint-Inhalte in Tabellen des Schemas dbo, die Project-Server-Inhalte in Schemas prjdraft, prjpub, prjrep und prjver.

 

In einer SharePoint-Inhaltsdatenbank können sich mehrere Websitesammlungen und damit auch mehrere Project Web Apps befinden.

Allerdings ist dies nicht empfohlen, und spätestens wenn Sie auf die Inhalte der Project-Server-Tabellen zu Berichtszwecken zugreifen wollen, werden mehrere Web Apps in einer Inhaltsdatenbank von Microsoft nicht unterstützt. Und ein entsprechendes Berichtswesen würde auch schwierig werden, da sich z.B. die Projekte mehrerer Instanzen dann in einer Tabelle befinden und die Zuordnung zur PWA-Site über deren ID erfolgen muss. Hie sehen Sie die beiden Enterprise-Global der oben erstellten Project Web Apps.

Abbildung 21.36    Projekte mehrerer Project Web Apps in einer Inhaltsdatenbank

Also sollten Sie unbedingt sicherstellen, dass sich Ihre Websitesammlungen mit Project Web App in isolierten Inhaltsdatenbanken befinden.

Wenn das Kind bereits in den Brunnen gefallen ist und Sie diese Trennung bei der Erstellung der Websitesammlung nicht berücksichtigt haben, können Sie eine neue Inhaltsdatenbank erstellen und eine Websitesammlung dann in diese neue Datenbank verschieben.

Abbildung 21.37    Erstellen einer neuen Inhaltsdatenbank und Verschieben einer Websitesammlung

21.3.4    Bereitstellung einer Infrastruktur für Apps

Ein wesentliches Feature ist die Erweiterbarkeit des Systems durch Apps. Diese können, wie von Windows oder Smartphones bekannt, aus einem Store bezogen und installiert werden.

Leider funktioniert das für SharePoint nicht ganz so einfach, wie von diesen Plattformen her eventuell bekannt. Eine App fügt man über das Systemmenü hinzu.

Abbildung 21.38    App hinzufügen (1)

Wenn das Ihre Anwender versuchen, werden sie mit einer Fehlermeldung empfangen – und stehen dann vermutlich bei Ihnen auf der Matte …

Aktiviert werden Apps über die Zentraladministration. Dort gibt es in der Navigation einen eigenen Menüpunkt für Apps.

Abbildung 21.39    App hinzufügen (2)

Abbildung 21.40    App-Verwaltung

Eine App verfügt über eine individuelle URL, die aus einem Präfix, der ID der App und einem wählbaren Domänennamen besteht. Präfix und Domäne werden in App-URLs konfigurieren definiert.

Hier bekommen wir leider gleich die nächste Fehlermeldung. Um Apps nutzen zu können, benötigen Sie nicht nur die App-Dienstanwendung, sondern auch den Abonnementeinstellungsdienst.

Abbildung 21.41    App-URLs konfigurieren (1)

Den Abonnementeinstellungsdienst kann man über die grafische Oberfläche nicht aktivieren. Das geht nur über PowerShell. Starten Sie die SharePoint Management Shell mit Adminrechten, und geben Sie folgende Befehle ein.

$account = Get-SPManagedAccount "airbi\services"
$appPoolSubSvc = New-SPServiceApplicationPool -Name AbonnementsdienstAppPool 
  ‐Account $account
$appSubSvc = New-SPSubscriptionSettingsServiceApplication   
  -ApplicationPool $appPoolSubSvc -Name Abonnementeinstellungsdienst  
  -DatabaseName SettingsServiceDB
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy  
  -ServiceApplication $appSubSvc

Listing 21.1    Abonnementeinstellungsdienst

Abbildung 21.42    Erstellen des Abonnementeinstellungsdienstes

Jetzt können Sie einen neuen Versuch unternehmen, die App-URLs zu konfigurieren. Die Meldung bezüglich des Abonnementeinstellungsdienstes ist wie erhofft verschwunden.

Apps benötigen eine eigene DNS-Domäne. Dabei kann es sich entweder um eine eigenständige DNS-Domäne (z.B. airbi-apps.local) oder um eine Unterdomäne handeln. Wir entscheiden uns für die Unterdomäne und wählen apps.airbi.local.

Abbildung 21.43    App-URLs konfigurieren (2)

Diese Domäne muss nun allerdings auch im DNS konfiguriert werden. Wir erstellen dazu eine Subdomain mit Namen »apps« und darin einen Alias (CNAME)-Eintrag. Als Aliasnamen geben Sie * an und als Zielhost den vollqualifizierten Namen Ihres SharePoint Servers. Damit landen DNS-Anfragen nach app-irgendeinetolleguid. apps.ppm.local auf Ihrem SharePoint Server.

Abbildung 21.44    Einrichten der App-Domäne im DNS

Nun benötigen Sie noch eine Website für den App-Katalog. Hier werden die im System verfügbaren Apps verwaltet. Dazu wählen Sie in der SharePoint-Zentraladministration Apps • App-Katalog verwalten und erstellen eine neue App-Katalogwebsite.

Abbildung 21.45    App-Katalog verwalten

Geben Sie der Site einen kreativen Titel sowie eine URL. Dann definieren Sie den künftigen Administrator des App-Katalogs und die zum Zugriff Berechtigten.

Abbildung 21.46    App-Katalogwebsite erstellen

Wenn Sie jetzt erneut versuchen, eine App unserer PWA-Site hinzuzufügen, erhalten Sie Zugriff auf den Store. Achtung: Verwenden Sie nicht das Systemkonto zum Zugriff auf den Store! Das Systemkonto kann keine Apps erwerben.

Wenn Sie jetzt eine App auswählen (wir wählen hier exemplarisch SOLVIN TrackTimesheet Go), erhalten Sie nähere Informationen zur App. Mit Hinzufügen wählen Sie die App zum Kauf aus (auch wenn sie kostenlos ist …).

Abbildung 21.47    SharePoint Store

Abbildung 21.48    App aus Store hinzufügen (1)

Abbildung 21.49    App aus Store hinzufügen (2)

Wenn der Erwerb erfolgreich war, erhalten Sie eine Bestätigung und können die App gleich der PWA-Site oder der Site hinzufügen, von der aus Sie auf den App-Katalog zugegriffen haben.

Abbildung 21.50    App aus Store hinzufügen (3)

Wenn Sie das tun, werden Sie gefragt, ob Sie der App vertrauen wollen. Dabei erhalten Sie detaillierte Informationen darüber, auf welche Informationen die App Zugriff benötigt.

Abbildung 21.51    App aus Store hinzufügen (4)

Anschließend wird die App in den Websiteinhalten angezeigt. Es kann etwas dauern, bis Sie auf die App tatsächlich zugreifen können.

Abbildung 21.52    App aus Store hinzufügen (5)

Dann können Sie die App starten. Achten Sie auf die URL in der Adressleiste des Browsers. Hier finden Sie das von Ihnen definierte App-Präfix sowie den Domänennamen wieder.

Sie können Einfluss darauf nehmen, wer welche Apps hinzufügt und verwendet. Nähere Informationen finden Sie unter http://technet.microsoft.com/de-de/library/fp161234.aspx. Dieser Artikel bezieht sich noch auf die Version SharePoint 2013; eine aktualisierte Version ist zum Zeitpunkt der Drucklegung noch nicht verfügbar. Hier hat sich aber von 2013 zu 2016 nichts Wesentliches verändert.

21.3.5    Bereitstellung der Workflow-Infrastruktur

Workflows wurden in der Version Project Server 2010 eingeführt. Hier gab es nur die Möglichkeit, Workflows mit Visual Studio oder mit Drittanbieter-Tools zu entwickeln (Nintex Workflow für Project Server, UMT Project Essentials).

In der Version Project Server 2013 wurden die Workflows deutlich weiterentwickelt. Project Server verwendet seitdem die SharePoint-Workflow-Infrastruktur. Diese hat sich ebenfalls geändert, da sie »cloudfähig« gemacht werden musste. Dazu wurde der Workflow Manager entwickelt, um Workflows und andere Dienste zu hosten, die über längere Zeiträume hinweg ausgeführt werden. Der Workflow Manager bedient sich wie SharePoint einer Infrastruktur, die über mehrere Server hinweg in einer Farm installiert werden kann. Im Normalfall gestaltet sich die Installation aber sehr unproblematisch, und wir installieren die Umgebung einfach mit auf einem Server unserer SharePoint-Farm.

Zunächst laden Sie dazu die Software von der Microsoft-Website unter der URL www.microsoft.com/de-de/download/details.aspx?id=35375 herunter. Hier wählen Sie WorkflowManager.exe.

Das Paket ist angeblich nur wenige MB groß. Das täuscht allerdings, da eine Reihe von Komponenten später nachgeladen wird.

Abbildung 21.53    Workflow-Manager-Installation (1)

Bestätigen Sie die Voraussetzungen und die Lizenzbedingungen.

Abbildung 21.54    Workflow-Manager-Installation (2)

Anschließend werden die benötigten Komponenten heruntergeladen und ohne weitere Nachfragen installiert.

Zum Abschluss werden Sie dazu aufgefordert, einen Konfigurations-Assistenten auszuführen.

Abbildung 21.55    Workflow-Manager-Installation (3)

Der Einfachheit halber beschränken wir uns hier auf die Installation mit Standardeinstellungen, den ersten Punkt aus der Auswahl.

Geben Sie den Datenbankserver für die Workflow-Umgebung an. Hier wird es sich meist um denselben Datenbankserver handeln, den Sie auch für die SharePoint- und Project-Server-Datenbanken verwendet haben, und verwenden Sie hier auch wieder den SQL-Alias, sofern Sie einen definiert haben. Als Dienstkonto können Sie das Benutzerkonto verwenden, das Sie auch für die SharePoint-Dienste genutzt haben.

In produktiven Umgebungen sollten Sie hier unbedingt HTTPS verwenden, für unser Testsystem verzichten wir darauf und aktivieren daher die Option Allow Workflow management over HTTP on this computer.

Abbildung 21.56    Workflow-Manager-Konfiguration (1)

Auf der nächsten Seite werden die Konfigurationsinformationen zusammengefasst dargestellt. Wenn Sie hier keinen Fehler feststellen, bestätigen Sie das Fenster.

Nach einigen Minuten sollte die Konfiguration abgeschlossen sein, und der Workflow Manager kann verwendet werden.

Abbildung 21.57    Workflow-Manager-Konfiguration (2)

Abbildung 21.58    Workflow-Manager-Konfiguration (3)

Jetzt sollten Sie den Workflow Manager noch aktualisieren. Das ist leider etwas kompliziert.

Zunächst starten Sie den Server bitte einmal neu, da sonst das Aktualisieren vermutlich fehlschlagen wird.

Dann starten Sie den Web Platform Installer und suchen dort nach Service Bus 1.0 Cumulative Update 1. Sollte es ein neueres Cumulative Update geben, nehmen Sie dieses. Das fügen Sie mit Add hinzu und wählen Install.

Abbildung 21.59    Update Service Bus (1)

Akzeptieren Sie die Lizenzbestimmungen.

Abbildung 21.60    Update Service Bus (2)

Das Update ist dann hoffentlich erfolgreich:

Abbildung 21.61    Update Service Bus (3)

In einem zweiten Schritt müssen Sie jetzt noch den Workflow Manager selbst aktualisieren. Dabei kann es passieren, dass selbst nach Neustart des Web Platform Installers die Aktualisierung fehlschlägt mit dem Hinweis, Sie müssten erst Service Bus aktualisieren – was Sie ja gerade gemacht haben. Im Zweifel starten Sie also noch mal neu.

Dann suchen Sie im Web Platform Installer nach dem Workflow Manager 1.0 Cumulative Update 3 (oder einem neueren Cumulative Update) und aktualisieren dieses auf demselben Weg wie eben.

Abbildung 21.62    Update Workflow Manager

Achtung

Das System startet dabei automatisch ohne jede Nachfrage neu!

 

Nun bleibt noch die Verbindung zwischen der Project-Server-Webanwendung und dem Workflow Manager herzustellen. Das geschieht über PowerShell:

Als Site nehmen Sie eine beliebige Websitesammlung Ihrer Farm. Den Parameter AllowOauthHttp sollten Sie nur in Testumgebungen verwenden. Produktiv ist hier https die bessere Wahl.

Register-SPWorkflowService -SPSite "http://prjsrv" -WorkflowHostUri 
  "http://prjsrv:12291" –AllowOauthHttp

Abbildung 21.63    Registrieren des WorkflowService

Die erfolgreiche Konfiguration der Verbindung zwischen SharePoint und der Workflow-Manager-Farm können Sie wie folgt überprüfen:

Abbildung 21.64    Test der Workflow-Manager-Installation

Starten Sie SharePoint Designer 2013 (es gibt keine 2016-Version davon, Sie können aber die 2013-Version auch für SharePoint 2016 verwenden). Wenn Sie dieses Programm noch nicht installiert haben, erhalten Sie es unter www.microsoft.com/downloads.

Verbinden Sie sich mit Ihrer PWA-Website. Wählen Sie in der Navigation Workflows und dann im Menüband Site Workflow. Wenn Ihre Installation erfolgreich war, können Sie unter Platform Type sowohl SharePoint 2010 Workflow als auch SharePoint 2013 Workflow auswählen.

21.3.6    OLAP-Cube

Ein OLAP-Cube ist ein Datawarehouse, das regelmäßig (in der Regel nachts) aktualisiert wird und performante Analysen der Project-Server-Daten mittels Excel-Pivot-Tabellen-Technik ermöglicht. Weitere Informationen dazu finden Sie in Kapitel 17, »Berichtswesen«, und Abschnitt 20.3.8, »OLAP-Datenbankverwaltung".

Um ihn bereitstellen zu können, müssen technische Voraussetzungen erfüllt werden:

• Wir benötigen eine SQL-Analysis-Services-Instanz (auf dem gleichen oder einem anderen Datenbankserver).
• Auf dem Applikationsserver (dem Server, der den Project-Server-Warteschlangendienst ausführt) müssen aus dem SQL Server Feature Pack (www.microsoft.com/de-DE/download/details.aspx?id=44272) die Microsoft SQL Server 2008 R2 Analysis Management Objects installiert werden (SQLSERVER2008_ASAMO10.msi).
• Der Benutzer des Project-Server-Warteschlangendienstes benötigt Adminrechte in der genutzten SQL Server-Analysis-Services-Instanz.
• Der Benutzer des SQL Server-Analysis-Services-Dienstes benötigt Leserechte an den Project-Server-Inhalten – also db_datareader-Rechte an der entsprechenden Inhaltsdatenbank.
• Falls die Analysis Services nicht mit auf einem Server der SharePoint-Farm installiert sind und Sie einen SQL-Alias verwenden, müssen Sie den SQL-Alias auch auf diesem Server konfigurieren. Das liegt daran, dass die Analysis Services von Project Server die Information erhalten, von wo sie die Daten für den Cube bekommen. Und da Project Server nur den SQL-Alias und nicht den realen Namen der SQL Server-Instanz kennt, muss auch der Analysis-Services-Dienst diesen Namen auflösen können.

Wenn diese Voraussetzungen gegeben sind, können Sie über die Verwaltung der Project Web App in der SharePoint-Zentraladministration den Cube konfigurieren und erfolgreich erstellen.

Abbildung 21.65    Erstellung eines OLAP-Cubes