Einblicke in SharePointEnterprise Project Management mit SharePoint

Pav Cherny

Codedownload verfügbar unter: ChernySharePoint2008_12.exe(959 KB)

Inhalt

Project Server-Architektur
SharePoint-Integration
Serverfarmbereitstellungen
Willkommen bei IIS 7
Sitzungsdatenbank-Berechtigungen
Berechtigungen für gemeinsame Dienste
Windows-Firewall
MOPS-Dienste und -Dienstkonten
Analysis Services-Integration
Schlussbemerkung

Welche SharePoint-Technologien sind die richtigen für Sie? Bei Ihren Bemühungen, die Antwort zu finden, sind Sie wahrscheinlich eine scheinbar endlose Liste von Kategorien durchgegangen (einschließlich Zusammenarbeit und Social Computing, Portale, Unternehmenssuche, Enterprise Content Management, Geschäftsprozesse und -formulare, Business Intelligence und Entwicklerplattformfunktionen) und haben die in Windows SharePoint Services (WSS) 3.0, Microsoft Office Search Server 2008 Express, Microsoft Office Forms Server 2007 und Microsoft Office SharePoint Server (MOSS) 2007 verfügbaren Features verglichen. Es gibt jedoch eine Technologie, die Sie möglicherweise nie in Betracht gezogen haben, weil sie von Microsoft nicht unter SharePoint-Produkten und -Technologien aufgeführt wird – Enterprise Project Management (EPM). Diese Technologie wird über Microsoft Office Project Server (MOPS) 2007 aktiviert.

MOPS 2007 ist jedoch eine SharePoint-Technologie, die auf WSS 3.0 aufbaut und diese Lösung auf eine mit MOSS 2007 vergleichbare Weise erweitert. MOPS 2007 ist die richtige Wahl, wenn Sie die Effizienz der Teamzusammenarbeit innerhalb von Abteilungen und abteilungsübergreifend durch eine Arbeits-, Ressourcen- und Budgetverwaltung erhöhen möchten, die über die in WSS 3.0 und MOSS 2007 enthaltenen einfachen Funktionen zur Aufgabenverwaltung hinausgeht. Mit MOPS können Sie Teamwebsites in Projektarbeitsbereiche verwandeln, die Teamzusammenarbeit innerhalb von Abteilungen und abteilungsübergreifend verwalten sowie ein stabiles EPM-Fundament für eine ganze Organisation aufbauen. Zuerst müssen Sie jedoch die mit der Bereitstellung verbundenen Herausforderungen meistern.

In diesem Artikel wird die Bereitstellung von MOPS 2007 in einer Windows Server 2008-Umgebung mit SQL Server 2005 SP2 und WSS 3.0 SP1 erläutert. Zunächst wird die MOPS-Architektur kurz vorgestellt, um zu zeigen, wie die Komponenten aus der Perspektive eines Systemarchitekten in WSS 3.0 integriert werden. Diese Informationen erleichtern Ihnen das Verständnis der anschließenden Beschreibung typischer Bereitstellungs- und Integrationsprobleme, mit denen Sie konfrontiert werden können. Hierzu gehören beispielsweise Probleme bei der Anwendungspoolkonfiguration, fehlende Zugriffsberechtigungen, Fehler beim Start des Warteschlangensystems und Probleme in Verbindung mit SQL Server 2005 Analysis Services.

Um die Bereitstellungs- und Problembehandlungsschritte zu veranschaulichen, wird eine einfache Testumgebung mit zwei WSS 3.0-Servern in einer Serverfarm, einem dedizierten Domänencontroller und einem separaten Computer mit SQL Server verwendet, die der Testumgebung ähnelt, die bisher für diese SharePoint-Rubrik verwendet wurde. Sie finden entsprechende Arbeitsblätter mit Schritt-für-Schritt-Anleitungen im Begleitmaterial zu diesem Artikel auf der TechNet Magazin-Website.

Project Server-Architektur

MOPS 2007 ist eine der fortschrittlichsten und komplexesten SharePoint-Anwendungen, die die Vorteile der WSS 3.0-Plattform für die zentralisierte Verwaltung, Websitebereitstellung, Authentifizierung und Sicherheit nutzt. Darüber hinaus bietet sie zusätzliche Komponenten wie 25 allgemeine und spezielle MOPS-Webparts und eine neue Sammlung von bis zu vier MOPS-Datenbanken pro PWA-Website (Project Web Access). Der Zugriff auf die einzelnen Komponenten erfolgt über einen Satz von 21 öffentlichen und internen MOPS-Webdiensten, die gemeinsam die Project Server-Schnittstelle (Project Server Interface, PSI) bilden (siehe Abbildung 1). Weitere Informationen zu MOPS-Webdiensten finden Sie auf MSDN.

Abbildung 1 Integration von SharePoint in MOPS 2007 (zum Vergrößern auf das Bild klicken)

Die MOPS 2007-Architektur basiert auf verschiedenen Komponenten, die auf Clientarbeitsstationen, Anwendungsserver und Datenbankserver verteilt sind. Die wichtigsten dieser Komponenten werden in diesem Artikel beschrieben. Wenn Sie jedoch an allen technischen Einzelheiten interessiert sind, lesen Sie die Dokumentation Project Server Architecture (Project Server-Architektur) im Project 2007 SDK.

Beim Lesen der Informationen im SDK sollten Sie jedoch beachten, dass PWA-Webparts und Microsoft Office Project Professional 2007 nicht direkt auf die PSI-Webdienste zugreifen. Das SDK legt nahe, dass Clients PSI direkt aufrufen. Die meisten Anwendungen verwenden jedoch die PSI-Weiterleitung (PSI Forwarder) – eine Komponente von PWA-Websites, die indirekten Zugriff auf die PSI-Webdienste bietet. Nur serverbasierte Komponenten wie der Warteschlangendienst und der Ereignisdienst, die mit Berechtigungen auf Systemebene ausgeführt werden, führen direkte PSI-Aufrufe durch. Aus mehreren Gründen ist es wichtig, dass Sie in Problembehandlungssituationen an dieses kleine Detail denken:

• PWA-Websites definieren Datenbankkontext (jede PWA-Website verfügt über separate Entwurfs-, Veröffentlichungs-, Archiv- und Berichtsdatenbanken) und Benutzerberechtigungen. Normalen Benutzerkonten wird jedoch kein Zugriff auf die PSI-Webdienste gewährt.
• Die PSI-Weiterleitung unterstützt nicht den Identitätswechsel und greift mithilfe des Anwendungspoolkontos der PWA-Website im Namen der Benutzer auf die PSI-Webdienste zu.
• Bei PSI-Aufrufen werden nicht unbedingt lokale PSI-Webdienste verwendet, wenn die Farm mehrere Anwendungsserverinstanzen enthält.

SharePoint-Integration

Betrachten wir nun die konkrete Integration von MOPS in SharePoint etwas genauer. Aus der Perspektive eines SharePoint-Administrators ist MOPS eine freigegebene Webanwendung, die in der SharePoint 3.0-Zentraladministration als Farmdienst verwaltet wird. Dies ist für Administratoren, die mit Anbietern für gemeinsame Dienste (Shared Service Providers, SSPs) in MOSS 2007 vertraut sind, relativ einfach.

Wenn Sie jedoch ein WSS 3.0-Administrator und hinsichtlich der SSP-Verwaltung ein Neueinsteiger sind, sollten Sie das Arbeitsblatt „Deploying Project Server 2007“ (Bereitstellen von Project Server 2007) im Begleitmaterial zurate ziehen, in dem Sie Schritt-für-Schritt-Anleitungen zum Erstellen und Konfigurieren der gemeinsamen Dienste und PWA-Websites einer SharePoint-Farm finden. Nach der Installation und Konfiguration von MOPS können Sie die Systemimplementierung in IIS-Manager analysieren. Wie in Abbildung 2 dargestellt, sollten separate Websites für gemeinsame Dienste, SSP-Verwaltung und Websitesammlungen auf einem MOPS-Anwendungsserver angezeigt werden.

Abbildung 2 Zugriff auf Project Server 2007 über PWA und PSI-Weiterleitung (zum Vergrößern auf das Bild klicken)

Clients greifen über das virtuelle Verzeichnis „_vti_bin/PSI“ einer PWA-Website auf die PSI-Webdienste zu. Die PSI-Webdienste befinden sich jedoch nicht in diesem virtuellen Verzeichnis. Dem virtuellen Verzeichnis „_vti_bin/PSI“ ist der folgende physische Pfad zugeordnet: %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI. Sie werden feststellen, dass dieses Verzeichnis eine web.config-Datei enthält, die in einem <http­Handlers>-Abschnitt angibt, dass alle HTTP-Anforderungen für *.asmx-Dateien (d. h. ASP.NET-basierte Webdienste) an einen benutzerdefinierten HTTP-Handler übergeben werden sollen, der durch Microsoft.Office.Project.Server.PSIForwarderHandlerFactory instanziiert wird.

Dieser benutzerdefinierte HTTP-Handler ist die PSI-Weiterleitung. Die PSI-Weiterleitung stellt eine neue HTTP-Verbindung zu den konkreten PSI-Webdiensten her, leitet die HTTP-Anforderung des Clients weiter und gibt dann die Ergebnisse an den Client zurück.

Die PSI-Webdienste sind für die PSI-Weiterleitung über HTTP über das virtuelle PSI-Verzeichnis der Webanwendung für gemeinsame Dienste verfügbar, die auf der Website für Office Server-Webdienste gehostet wird. Diesem virtuellen Verzeichnis ist standardmäßig der physische Pfad „%PROGRAMFILES%\Microsoft Office Servers\12.0\WebServices\Shared\PSI“ zugeordnet, unter dem Sie die *.asmx-Dateien von MOPS 2007 finden.

Auf die Website für Office Server-Webdienste wird an späterer Stelle näher eingegangen. Fürs Erste besteht jedoch die wichtigste Erkenntnis, die aus Abbildung 2 gewonnen werden kann, darin, dass die PSI-Weiterleitung unter Verwendung der Identität des Webanwendungspool-Kontos der PWA-Website und nicht der Identität des Benutzers, der derzeit auf die PWA-Website zugreift, mit den PSI-Webdiensten kommuniziert.

Serverfarmbereitstellungen

Die PSI-Weiterleitung spielt auch eine wichtige Rolle bei Serverfarmbereitstellungen, bei denen separate Web-Front-End-Server und Anwendungsserver zur Erhöhung der Systemskalierbarkeit und -verfügbarkeit verwendet werden. Ein MOPS-Front-End-Server ist ein WSS 3.0-Server, der die PSI-Webdienste oder andere MOPS-Dienste (wie Warteschlangendienst und Ereignisdienst) nicht hostet, aber Clients Zugriff auf PWA-Websites ermöglicht, die die PSI-Weiterleitung umfassen (siehe Abbildung 3).

Abbildung 3 Eine mittelgroße MOPS 2007-Serverfarm (zum Vergrößern auf das Bild klicken)

Ein Anwendungsserver ist hingegen ein WSS 3.0-Server, auf dem der vollständige Satz von MOPS-Komponenten und -Diensten installiert ist. Anwendungsserver können PWA-Websites hosten, stellen aber in den meisten Fällen nur Back-End-Dienste für Front-End-Server bereit und führen den WSS-Webanwendungsdienst nicht aus. Sie wählen die Serverrolle bei der MOPS-Installation aus.

Abbildung 3 zeigt die Konfiguration für eine mittelgroße Serverfarm. Sie können in Abhängigkeit von den Anforderungen Ihrer Organisation zusätzliche Front-End-Server zur Erhöhung der Skalierbarkeit sowie zusätzliche Anwendungsserver für hohe Verfügbarkeit hinzufügen. Es ist nicht notwendig, einen Lastenausgleichscluster für MOPS-Anwendungsserver zu konfigurieren, da die PSI-Weiterleitung automatisch den Lastenausgleich für PSI-Anforderungen vornimmt, wenn mehrere MOPS-Anwendungsserver in der Serverfarm vorhanden sind. Ausführliche Informationen zu den MOPS-Bereitstellungsoptionen finden Sie unter Bereitstellung für Office Project Server 2007.

Willkommen bei IIS 7

Genug der Theorie! Betrachten wir nun einige reale Probleme, mit denen Sie bei der Bereitstellung von MOPS 2007 konfrontiert werden können. Eines meiner Lieblingsprobleme steht mit vom Host benannten Websitesammlungen für PWA-Websites in Verbindung. Bei diesem Szenario stellen Sie MOPS erfolgreich bereit, konfigurieren den SSP und stellen eine PWA-Website im Hostheadermodus durch Eingabe der vollständigen PWA-URL (z. B. „pwa“) bereit, nachdem Sie auf der Seite „Project Web Access-Site erstellen“ das Kontrollkästchen „Project Web Access-Pfad als Hostheader verwenden“ aktiviert haben. Wenn alle Ressourcen erfolgreich bereitgestellt wurden, versuchen Sie, die Website zu öffnen. Anstelle von PWA erreichen Sie jedoch die Standardbegrüßungsseite von IIS 7.

Dies geschieht, wenn die Standardwebsite keine mit SharePoint erweiterte Website ist und keine andere Website mit einer geeigneten Websitebindung für die PWA-URL vorhanden ist. Ohne eine explizite Websitebindung ordnet IIS die pwa-Anforderung der nicht erweiterten Standardwebsite zu. Daher wird die Begrüßungsseite angezeigt. Möglicherweise haben Sie erwartet, dass die SharePoint 3.0-Zentraladministration der SharePoint-Webanwendung, die Sie als Host für die PWA-Website ausgewählt haben, die erforderliche Bindung hinzufügt, aber das ist nicht der Fall.

Um dieses Problem zu beheben, müssen Sie die Standardwebsite mit SharePoint erweitern und diese Websitesammlung dann entsprechend der Beschreibung im Begleitarbeitsblatt „Troubleshooting IIS and PWA“ (Behandeln von Problemen mit IIS und PWA) zur Bereitstellung von PWA-Websites verwenden. Alternativ können Sie in IIS-Manager der für PWA ausgewählten Webanwendung die fehlende Websitebindung manuell hinzufügen. Vergessen Sie nicht, diesen Schritt auf allen WSS-Servern durchzuführen, die die PWA-Website hosten.

Sitzungsdatenbank-Berechtigungen

Wenn Sie sich für das Erweitern der Standardwebsite entscheiden, stellen Sie sicher, dass Sie ein Domänenkonto für den Anwendungspool verwenden (siehe Planen administrativer Konten und Planen von Dienstkonten (Office SharePoint Server)). Andernfalls treten nach der Bereitstellung von PWA-Websites Probleme aufgrund unzureichender Berechtigungen auf, die sich zumeist in einer wenig informativen SharePoint-Fehlermeldung wie der in Abbildung 4 manifestieren.

Abbildung 4 Fehler beim Zugriff auf die SSP-Datenbank (zum Vergrößern auf das Bild klicken)

Um aussagekräftigere Informationen zu erhalten, sollten Sie die Ablaufverfolgungsprotokolle im Verzeichnis „%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\LOGS“ prüfen. Dies kann mühsam sein, wenn Ihre Farm mehrere Front-End-Webserver mit Lastenausgleich umfasst.

Zu Problembehandlungszwecken empfiehlt es sich, den DNS-Eintrag für den PWA-Hostnamen zu ändern und vorübergehend auf einen einzelnen Front-End-Server verweisen zu lassen. So wissen Sie, welcher Server die Clientanforderungen verarbeitet, und müssen nur die Ablaufverfolgungsprotokoll-Dateien dieses einen Servers prüfen.

Öffnen Sie die neueste Protokolldatei in Editor, und suchen Sie nach dem Eintrag „Cannot open database“ (Die Datenbank kann nicht geöffnet werden). Wenn Sie diesen finden, wissen Sie, dass das Problem durch unzureichende Datenbankberechtigungen verursacht wird. Das Ablaufverfolgungsprotokoll in Abbildung 4 zeigt beispielsweise, dass das Konto „LITWARE\WSS02$“ keinen Zugriff auf die Datenbank „SharedServices1_DB“ hat. Dies ist ein eindeutiges Anzeichen dafür, dass die PWA-Website mit einer Netzwerkdienstidentität ausgeführt wird.

LITWARE\WSS02$ ist das Computerkonto des Front-End-Webservers und SharedServices1_DB die Datenbank des Anbieters für gemeinsame Dienste. Die Front-End-Webserver verwenden diese Datenbank unter anderem zur Verwaltung von ASP.NET-Sitzungszustandsdaten in der Tabelle „ASPStateTempSessions“, aber LITWARE\WSS02$ hat keinen Zugriff auf diese Datenbank.

Beachten Sie, dass Sie die Datenbank des Anbieters für gemeinsame Dienste in Ihre wöchentlichen Datenbankwartungsaktivitäten einbeziehen müssen, um eine stabile Systemleistung zu gewährleisten. Sie sollten beispielsweise abgelaufene Sitzungszustandsdaten entsprechend der Beschreibung in Bereitstellen von Project Server 2007 in einer Serverfarmumgebung mit dem SQL-Befehl „TRUNCATE TABLE ASPStateTempSessions“ aus der Tabelle „ASPStateTempSessions“ entfernen.

Da mit dem Netzwerkdienst verbundene Konfigurationsprobleme verwirrend sein können, sollen diese im Folgenden näher betrachtet werden. Domänenkonten (z. B. LITWARE\SspConfigAdmin) funktionieren für Anwendungspools in Serverfarmen, weil sie auf allen Computern identisch sind. Im Gegensatz dazu ist auf jedem Computer ein anderes Netzwerkdienstkonto (NT-AUTORITÄT\NETZWERKDIENST) vorhanden. Auf einem Front-End-Server namens „wss02.litware.com“ wird das Konto NT-AUTORITÄT\NETZWERKDIENST in LITWARE\WSS02$ übersetzt. Auf einem Server mit dem Namen „sql01.litware.com“ bezieht sich das Konto NT-AUTORITÄT\NETZWERKDIENST jedoch stattdessen auf LITWARE\SQL01$. Darin liegt das Problem.

Wenn Sie die SQL Server-Berechtigungen für SharedServices1_DB in SQL Server Management Studio prüfen, werden Sie feststellen, dass das Konto NT-AUTORITÄT\NETZWERKDIENST über db_owner-Berechtigungen verfügt. Dadurch wird versucht, Anwendungspools, die das Netzwerkdienstkonto verwenden, Zugriff auf die Datenbank des Anbieters für gemeinsame Dienste zu gewähren. Bedenken Sie jedoch, dass dies nur bei einer Einzelserverinstallation funktioniert.

Sie können die Berechtigungszuweisungen korrigieren, indem Sie LITWARE\WSS02$ und allen anderen WSS-Serverkonten (etwa LITWARE\WSS01$ usw.) explizit db_owner-Berechtigungen für SharedServices1_DB erteilen. Es ist aber besser, stattdessen Domänenkonten für Anwendungspools zu verwenden, damit alle Front-End-Server dieselbe Identität verwenden, der SharePoint die erforderlichen Datenbankberechtigungen erteilt hat.

Berechtigungen für gemeinsame Dienste

Wenn der Anwendungspool Ihrer PWA-Website aus irgendeinem Grund das Netzwerkdienstkonto verwendet, werden Sie ebenfalls mit SSP-bezogenen Berechtigungsproblemen konfrontiert. Erinnern Sie sich, dass bereits erwähnt wurde, dass die PSI-Weiterleitung im Kontext des Anwendungspoolkontos der PWA-Website im Namen des Benutzers auf die PSI-Webdienste zugreift? Wenn dieses Konto nicht über Berechtigungen für den Zugriff auf die Website für Office Server-Webdienste verfügt, sind Sie mit der üblichen SharePoint-Fehlermeldung wieder da, wo Sie angefangen haben. Dieses Mal enthält das Ablaufverfolgungsprotokoll auf dem Front-End-Server den Eintrag „The request failed with HTTP status 401: Unauthorized“ (Fehler bei der Anforderung mit HTTP-Status 401: Nicht autorisiert), wie in Abbildung 5 dargestellt.

Abbildung 5 Fehler bei der Anforderung mit HTTP-Status 401: Nicht autorisiert (zum Vergrößern auf das Bild klicken)

Beachten Sie, dass sich diese Fehlermeldung nicht auf Benutzerberechtigungen in PWA bezieht. Auf einer PWA-Website gewährte SharePoint-Berechtigungen bestimmen, welche Benutzer auf das virtuelle Unterverzeichnis „_vti_bin/PSI“ dieser Website zugreifen können. Diese Benutzer erhalten jedoch keine Zugriffsberechtigungen für die Webanwendung für gemeinsame Dienste oder die PSI-Webdienste auf dem Anwendungsserver.

Selbst wenn Sie ein PWA-Websitesammlungsadministrator sind, tritt bei MOPS dennoch ein Fehler auf, wenn das Anwendungspoolkonto der PWA-Website keinen Zugriff auf die PSI-Webdienste hat. Dies ist insbesondere der Fall, wenn Sie die Empfehlung ignorieren, Domänenkonten für Anwendungspools in einer Serverfarm zu verwenden, und stattdessen das Netzwerkdienstkonto verwenden.

Um die SSP-Zugriffsberechtigungen auf dem Anwendungsserver zu überprüfen, prüfen Sie die Datei „web.config“ im Stammverzeichnis der Website für Office Server-Webdienste“ (standardmäßig %PROGRAMFILES%\Microsoft Office Servers\12.0\WebServices\Root). Sie bemerken möglicherweise im <authorization>-Abschnitt den Eintrag NT-AUTORITÄT\NETZWERKDIENST, der Anwendungspools autorisieren soll, die das Netzwerkdienstkonto verwenden. Wiederum wird der Zweck jedoch nicht erfüllt, da der Eintrag nur auf den lokalen Computer verweist, der nicht der Front-End-Server ist.

Die beste Strategie besteht darin, die Anwendungspoolkonfiguration zu ändern und ein Domänenkonto zu verwenden. Wenn Sie jedoch auf der Verwendung des Netzwerkdienstkontos bestehen, müssen Sie die Front-End-Serverkonten explizit autorisieren.

Bearbeiten Sie die Datei „web.config“ auf dem Anwendungsserver nicht direkt, da SharePoint Ihre Änderungen überschreibt. Erteilen Sie stattdessen entsprechend der Beschreibung im Arbeitsblatt „Testing Shared Service Provider Access Permissions“ (Testen von Berechtigungen für den Anbieter für gemeinsame Dienste) die fehlenden Berechtigungen mithilfe der SharePoint 3.0-Zentraladministration. Überprüfen Sie zudem die Konfiguration mithilfe einer einfachen ASP.NET-Anwendung wie SSPCheck (im Begleitmaterial enthalten), die eine direkte HTTP-Verbindung zu den PSI-Webdiensten herstellt. Um zuverlässige Ergebnisse zu erhalten, sollten Sie jedoch sicherstellen, dass Sie die ASP.NET-Testanwendung unter dem Anwendungspool der PWA-Website ausführen.

Windows-Firewall

Jetzt stehen die Chancen gut, dass Sie PWA öffnen können – sofern Sie nicht versuchen, über einen Front-End-Webserver auf PWA zuzugreifen, und die Windows-Firewall auf dem MOPS-Anwendungsserver nicht die TCP-Ports 56737 und 56738 blockiert. Dies sind die Standardports, die der Website für Office Server-Webdienste für die HTTP- und HTTPS-Kommunikation zugewiesen sind.

SharePoint öffnet diese Ports auf dem MOPS-Anwendungsserver nicht automatisch, wenn die Website für Office Server-Webdienste erstellt wird. Wenn die Windows-Firewall auf dem Anwendungsserver aktiviert ist, müssen Sie manuell eine Firewallregel erstellen, um den Datenverkehr zu diesen Ports zu ermöglichen, damit Front-End-Server auf die PSI-Webdienste zugreifen können. Wenn eine Firewall diese Ports blockiert, erhalten Sie die in Abbildung 6 gezeigte Fehlermeldung, und das Ablaufverfolgungsprotokoll auf dem Front-End-Server enthält den Eintrag „connected host has failed to respond“ (verbundener Host hat nicht geantwortet).

Abbildung 6 Von Project Web Access kann keine Verbindung mit Project Server hergestellt werden (zum Vergrößern auf das Bild klicken)

MOPS-Dienste und -Dienstkonten

Nachdem Sie die Probleme mit der Kommunikation zwischen Front-End und Back-End gelöst haben, sollten Sie auf Project Web Access zugreifen können. Herzlichen Glückwunsch! Nun ist es an der Zeit, sich auf ein schwierigeres MOPS-spezifisches Problem zu konzentrieren. Atmen Sie tief durch, und öffnen Sie dann das Anwendungsereignisprotokoll auf Ihrem MOPS-Anwendungsserver. Erschrecken Sie nicht, wenn unzählige Fehlermeldungen mit dem Hinweis „Das Warteschlangensystem konnte nicht gestartet werden“ angezeigt werden (siehe Abbildung 7). Möglicherweise stellen Sie auch fest, dass die MOPS-Dienste eine CPU-Auslastung von beinahe 100 % verursachen.

Abbildung 7 Das Warteschlangensystem konnte nicht gestartet werden (zum Vergrößern auf das Bild klicken)

Das Warteschlangensystem ist das Rückgrat der MOPS-Anwendungsinfrastruktur für die Verarbeitung von Einfüge- und Aktualisierungsanforderungen für die MOPS-Datenbank, die Ausführung von Cleanup- und Wartungsaufträgen und die Aktualisierung der Berichtsdatenbank für die Verwendung bei Datenanalyseaufgaben. Dies wird im Artikel Warteschlangensystem von Microsoft Office Project Server 2007 ausführlich erläutert. Laut diesem Artikel basiert das Warteschlangensystem auf einem Windows-Dienst, der in der Assembly „Microsoft.Office.Project.Server.Queuing.exe“ implementiert und für den Zugriff auf die Konfigurationsdatenbank der Farm mit der Identität des Kontos des Konfigurationsverwaltungs- und Timerdiensts von SharePoint ausgeführt wird.

Beim Start ruft der Windows-Dienst die Liste aller SSPs aus der Konfigurationsdatenbank ab, einschließlich der entsprechenden SSP-Administratorkonten und ihrer verschlüsselten Kennwörter, und startet dann für jeden SSP, der PWA-Websites zugeordnet ist, einen zusätzlichen Microsoft.Office.Project.Server.Queuing.exe-Prozess im Kontext des entsprechenden SSP-Administratorkontos. Mit anderen Worten: Microsoft.Office.Project.Server.Queuing.exe startet mehrere Instanzen seiner selbst unter verschiedenen Konten, sodass die Gesamtanzahl der auf einem MOPS-Anwendungsserver ausgeführten Microsoft.Office.Project.Server.Queuing.exe-Prozesse der Anzahl der SSPs plus 1 entspricht.

Die zusätzlichen Prozessinstanzen sind die Warteschlangen-Arbeitsprozesse. Jeder einzelne Warteschlangen-Arbeitsprozess bestimmt seinen eigenen Satz von PWA-Websites von seinem zugeordneten SSP, startet separate Abrufthreads für jede der PWA-Websites und beginnt mit der Verarbeitung der Aufträge, die für die entsprechenden PWA-Websitedatenbanken in die Warteschlange gestellt wurden. Dies ist die Funktionsweise des Warteschlangensystems, und Sie können es in Windows Task-Manager überprüfen.

Auf einem MOPS-Anwendungsserver in einer Farm mit einem SSP, der PWA-Websites zugeordnet ist, werden zwei Microsoft.Office.Project.Server.Queuing.exe-Prozesse angezeigt, von denen einer als das Konfigurationsverwaltungskonto und der andere als das SSP-Administratorkonto ausgeführt wird. In der Testumgebung sind diese Konten „WssConfigAdmin“ und „SspConfigAdmin“ (siehe Abbildung 8).

Abbildung 8 Die prozessübergreifende Kommunikation schlägt fehl, weil der Zugriff verweigert wird (zum Vergrößern auf das Bild klicken)

Warum wird das Warteschlangensystem also nicht gestartet? Der Fehlereintrag im Anwendungsereignisprotokoll bietet hierzu keine ausreichenden Informationen. Sie können jedoch weitere Details erhalten, indem Sie in der SharePoint 3.0-Zentraladministration auf der Registerkarte „Vorgänge“ unter „Diagnoseprotokollierung“ im Feld „Unwichtigstes, im Ablaufverfolgungsprotokoll aufzuzeichnendes Ereignis“ für alle Kategorien vorübergehend „Ausführlich“ einstellen.

Abbildung 8 zeigt ein daraus resultierendes Ablaufverfolgungsprotokoll. Wenn Sie dieses näher betrachten, werden Sie feststellen, dass ProjectQueueService (der allgemeine Windows-Dienst) einen QueueExecService-Prozess (einen Warteschlangen-Arbeitsprozess) startet, aber der QueueExecService-Prozess fehlschlägt, weil der Zugriff verweigert wird. Da QueueExecService fehlschlägt, versucht ProjectQueueService, den Prozess neu zu starten, aber dieser schlägt genau aus dem gleichen Grund erneut fehl. So geht es immer weiter, wobei immer mehr CPU-Zyklen beansprucht und die Ereignis- und Ablaufverfolgungsprotokolle mit Tausenden von Fehlern gefüllt werden. Der gesamte Vorgang endet in einer Endlosschleife.

Leider verrät selbst das ausführlichste Ablaufverfolgungsprotokoll nicht die genaue Ursache des Fehlers „Access is denied“ (Zugriff verweigert). Aber verzweifeln Sie nicht – durch das Ausschlussverfahren können Sie die zugrunde liegende Ursache schnell ermitteln.

Wenn Sie das SSP-Administratorkonto in der SharePoint 3.0-Zentraladministration ändern und das Konfigurationsverwaltungskonto (WssConfigAdmin) angeben, wird das Warteschlangensystem gestartet. Es funktioniert auch umgekehrt: Wenn Sie einfach das SSP-Administratorkonto (SspConfigAdmin) unverändert lassen und es als Dienstkonto für den Windows-Dienst verwenden, wird das Warteschlangensystem ebenfalls gestartet.

Daraus folgt, dass sowohl das Konfigurationsverwaltungskonto als auch das SSP-Administratorkonto über alle erforderlichen Berechtigungen verfügen. Das Problem liegt einfach darin, dass das Warteschlangensystem nicht gestartet wird, wenn ProjectQueueService und QueueExecService unterschiedliche Konten verwenden.

Dies ist ein eindeutiges Anzeichen für ein Problem aufgrund unzureichender Berechtigungen zwischen separaten Prozessen, die auf dem lokalen Computer miteinander interagieren möchten. Der ProjectQueueService-Prozess und der QueueExecService-Prozess müssen einander überwachen, um ein konsistentes Dienstverhalten sicherzustellen. (Beachten Sie die ProcessWatcher-Einträge im Ablaufverfolgungsprotokoll in Abbildung 8.) Wenn Sie beispielsweise den Windows-Dienst „ProjectQueueService“ herunterfahren, müssen alle QueueExecService-Arbeitsprozesse ebenfalls heruntergefahren werden.

Es ist der Versuch, auf einen Prozess zuzugreifen, der in einem anderen Sicherheitskontext ausgeführt wird, der zu dem Fehler führt. Für den Zugriff auf einen Prozess in einem anderen Sicherheitskontext sind erhöhte Rechte erforderlich. Obwohl die Dienstkonten möglicherweise über diese Rechte verfügen, verweigert Windows Server 2008 dennoch den Zugriff, da standardmäßig die Benutzerkontensteuerung (User Account Control, UAC) aktiviert ist, was dazu führt, dass Prozesse mit Standardrechten ausgeführt werden.

Sobald Sie UAC deaktivieren, können ProjectQueueService- und QueueExecService-Prozesse mit erhöhten Rechten ausgeführt werden, und das Warteschlangensystem wird gestartet. Sie können wählen, ob Sie das Konfigurationsverwaltungskonto als Administratorkonto für alle SSPs verwenden (wodurch alle Warteschlangenprozesse mit demselben Konto ausgeführt werden) oder ob Sie die Sicherheit auf Ihren MOPS-Anwendungsservern durch Deaktivieren von UAC schwächen möchten.

SharePoint-Ressourcen

Website zu SharePoint-Produkten und -Technologien
microsoft.com/sharepoint

Windows SharePoint Services-TechCenter
technet.microsoft.com/windowsserver/sharepoint

Windows SharePoint Services-Entwicklercenter
msdn.microsoft.com/sharepoint

Allgemeine Referenz zu Microsoft Office Project 2007
msdn.microsoft.com/library/bb258902

Teamblog zu Microsoft SharePoint-Produkten und -Technologien
blogs.msdn.com/sharepoint

Planen administrativer Konten und Planen von Dienstkonten (Office SharePoint Server)
technet.microsoft.com/library/cc263445

Analysis Services-Integration

Abschließend soll in diesem Artikel auf ein Problem in Verbindung mit SQL Server 2005 Analysis Services eingegangen werden, das wahrscheinlich auftritt, wenn Sie die Anweisungen in Anforderungen für die Verwendung von SQL Server 2005 Analysis Services mit dem Project Server 2007-Dienst zum Erstellen von Cubes befolgen. Wenn Sie dem Pfad folgen, um das Analysis Services-Repository wie dokumentiert durch Erstellen einer SQL Server 2005-Datenbank zu erstellen, erhalten Sie die in Abbildung 9 gezeigte Fehlermeldung, wenn Sie versuchen, den Cube in PWA zu erstellen.

Abbildung 9 Cubeerstellungsfehler aufgrund einer falschen Analysis Services-Konfiguration (zum Vergrößern auf das Bild klicken)

Wichtig ist, dass MOPS 2007 für SQL Server 2000 Analysis Services vorgesehen ist. SQL Server 2005 Analysis Services erfordert für die Abwärtskompatibilität zusätzliche Konfigurationsschritte. Bei der SQL Server 2000-Version werden Repositoryinformationen zur Cubeerstellung in einer Microsoft Jet-Datenbank gespeichert, und obwohl es möglich ist, eine Jet-Datenbank für die Arbeit mit SQL Server 2005 zu migrieren, ist dies bei einer neuen MOPS-Bereitstellung nicht notwendig.

In dem oben genannten TechNet-Artikel wird erklärt, wie Sie SQL Server 2005 so konfigurieren, dass unabhängig davon, ob die Jet-Datenbank tatsächlich vorhanden ist, deren Funktionalität emuliert wird. Allerdings wird in dem Artikel nicht erwähnt, dass MOPS nach wie vor Repositorysperrinformationen in der .dso-Dateifreigabe auf dem Datenbankserver prüft – unabhängig davon, ob Analysis Services für die Verwendung einer Jet-Datenbank (die alte Methode) oder einer vorkonfigurierten SQL Server 2005-Datenbank (die bevorzugte Methode) konfiguriert ist.

Wenn diese Dateifreigabe nicht existiert und dem SSP-Administratorkonto kein Vollzugriff auf diese Dateifreigabe gewährt wird, schlägt die Cubeerstellung mit dem in Abbildung 9 gezeigten Fehler aufgrund unzureichender Berechtigungen fehl. Damit SQL Server 2005 Analysis Services in Verbindung mit dem MOPS-Dienst zum Erstellen von Cubes ordnungsgemäß funktioniert, folgen Sie den im Begleitarbeitsblatt „Configuring Cubes“ (Konfigurieren von Cubes) beschriebenen Schritten.

Schlussbemerkung

Die Bereitstellung von MOPS 2007 ist mit einigen Schwierigkeiten verbunden. Die Architektur ist komplex, und eine erfolgreiche Bereitstellung umfasst zahlreiche Schritte, die von der ordnungsgemäßen Planung von Serverfarmkonfigurationen, der Installation von Binärdateien und der Ausführung des Konfigurations-Assistenten für SharePoint-Produkte und -Technologien auf Anwendungsservern und Front-End-Webservern über die Bereitstellung von Anwendungspools, gemeinsamen Diensten, SSP-Verwaltungswebsites und PWA-Websites in der SharePoint 3.0-Zentraladministration bis hin zur Konfiguration von Analysis Services in SQL Server Management Studio reichen.

Zu den Herausforderungen bei der Bereitstellung tragen zudem in Konflikt stehende Sicherheitsfeatures von Windows Server 2008 wie Windows-Firewall und UAC, Schwachstellen in den SharePoint-Verwaltungstools und Auslassungen in der MOPS-Bereitstellungsdokumentation bei. Sie können sich nicht darauf verlassen, dass Sie von der SharePoint 3.0-Zentraladministration gewarnt werden, wenn Ihre Anwendungspools das Netzwerkdienstkonto in einer Serverfarm verwenden, oder dass alle erforderlichen Konfigurationsänderungen (wie IIS-Websitebindungen und Windows-Firewallregeln) automatisch angewendet werden oder dass der Betriebsstatus bereitgestellter PWA-Websites geprüft wird.

Sie sollten auch nicht erwarten, dass alles sofort funktioniert. Um eine erfolgreiche Bereitstellung zu gewährleisten, stellen Sie sicher, dass Sie die MOPS-Architektur und -Abhängigkeiten vollständig verstehen, nicht von den Produktempfehlungen abweichen und die MOPS-Konfiguration und -Funktionalität durch Erstellen von Testprojektplänen und -ressourcen gründlich überprüfen.

Trotz dieser Herausforderungen bietet MOPS auch die Stärken von SharePoint als Unternehmensplattform. Da MOPS auf SharePoint und Webdiensttechnologien basiert, wird auf Clientarbeitsstationen keine direkte Datenbankkonnektivität mehr benötigt. Durch das Warteschlangensystem erhöht MOPS die Nachhaltigkeit während der Spitzenzeiten (aus unerklärlichem Grund wollen alle Programmmanager ihre Projektpläne am Montagmorgen aktualisieren), und durch zusätzliche MOSS-Technologien ist es möglich, MOPS in weitere Branchenanwendungen zu integrieren.

Da ich in der Vergangenheit Geschäftslösungen für Project Server 2003 entwickelt habe, halte ich die mit der Bereitstellung von MOPS 2007 verbundenen Probleme für unbedeutend im Vergleich zu den Skalierbarkeitsproblemen in der Vergangenheit, den früheren Problemen mit der ODBC-Konnektivität über langsame Netzwerkverbindungen und den Schwierigkeiten bei der Erstellung von Datenbankabfragen mit so vielen JOIN-Anweisungen, dass ich Excel verwenden musste, um den Überblick über alle Unterabfragen zu behalten. MOPS 2007 ist ein bedeutender Meilenstein in der EPM-Entwicklung und lohnt den Bereitstellungsaufwand.

Pav Cherny ist IT-Experte und Autor und ist auf Microsoft-Technologien für Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine Veröffentlichungen enthalten Whitepaper, Produkthandbücher sowie Bücher mit dem Schwerpunkt IT-Vorgänge und Systemverwaltung. Pav Cherny ist Präsident der Biblioso Corporation. Dieses Unternehmen ist auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert.