Troubleshoot Messaging Integration in SharePoint

Artikel
08/24/2016

Einblicke in SharePointProblembehandlung bei der Messagingintegration

Pav Cherny

Codedownload verfügbar unter: SharePoint2008_08.exe(416 KB)

Inhalt

Allgemeiner Ansatz zur Problembehebung
SharePoint-Messagingarchitektur
Ermitteln von Diagnoseinformationen
Ausgehende Nachrichtenübermittlung
Eingehende Nachrichtenübermittlung
Verzeichnisverwaltung

In einer gut entworfenen SharePoint-Umgebung müssen Benutzer für die Informationsbeschaffung nicht ihre Kommunikationsgewohnheiten oder Arbeitsroutinen ändern, um zusammenarbeiten zu können. Statt Websites, an denen gemeinsam gearbeitet wird, ständig manuell prüfen zu müssen, kann SharePoint Dokumente und andere Informationen, wie z. B. Warnungen und Erinnerungen, direkt an die Postfächer der Benutzer übermitteln.

Benutzer können sich auch an den Workflows beteiligen, indem Sie auf diese Nachrichten antworten oder neue Elemente als E-Mail-Nachrichten an Dokumentbibliotheken und Listen senden.

Die Integration von SharePoint® in eine sichere Messagingumgebung beinhaltet jedoch einige Herausforderungen, und Nicht-SharePoint-Komponenten haben die Möglichkeit, sich auf die SharePoint-basierte Zusammenarbeit auszuwirken. Die Herausforderung besteht darin, Hauptursachen für Probleme in der integrierten Umgebung effizient zu isolieren und zu eliminieren.

In diesem Artikel wird die SharePoint-Messagingintegration basierend auf einer bewährten Strategie zur Problembehandlung vorgestellt, die schnelle Ergebnisse liefert. Hierbei ist es wichtig, das Problem schnell zu finden und dann detaillierte und gezielte Schritte zur Problembehandlung durchzuführen.

In einer großen Organisation kann dieser phasenweise Ansatz bedeuten, dass das Problem nach einer anfänglichen Analyse an einen anderen Spezialisten übergeben wird. Dies ist insbesondere bei Problemen mit Nicht-SharePoint-Komponenten der Fall. In kleinen und mittleren Organisationen ist es jedoch nicht unüblich, dass ein IT-Administrator Probleme für alle verwendeten Systeme direkt beheben können muss. Dies macht einen strukturierten Ansatz noch wichtiger.

Um diesen Artikel praxisnah zu halten, wird eine Testumgebung mit Active Directory®, Exchange Server 2007 und WSS 3.0 verwendet. Eine Schritt-für-Schritt-Anleitung zur Erstellung der Testumgebung sowie Tools für die Problembehandlung, die in diesem Artikel vorgestellt werden, finden Sie im Begleitmaterial, das im Bereich mit den Codedownloads auf der TechNet Magazin-Website heruntergeladen werden kann.

Allgemeiner Ansatz zur Problembehebung

Die Fehlerbehebung für die SharePoint-Messagingintegration erfordert einen sehr strukturierten Ansatz, möglicherweise sogar strukturierter als in anderen Interoperabilitätsszenarios. Mehrere Faktoren erschweren dies.

In diesem Fall handelt es sich um komplexe Technologien, und bei Problemen mit Nachrichtenübertragung, Nachrichtformatkonvertierung, Sicherheitsaspekten und Verzeichnisverwaltung können einige SharePoint-Fehlermeldungen nicht klar zu verstehen sein. In Internetnewsgroups finden sich zahlreiche Diskussionsthreads, die alle keine Lösung bieten und Sie in die falsche Richtung leiten können, wie z. B. das Ausführen aller Webanwendungen unter der Anwendungspoolidentität für die SharePoint-Zentraladministration, um eine fehlerfreie Messagingintegration zu erreichen.

Es gibt jedoch auch positive Aspekte. SharePoint ist sehr flexibel. SharePoint bietet detaillierte Informationen zur Problembehebung, wenn der Benutzer weiß, wo er suchen muss. Mit einigen grundlegenden Skripts können Sie die Effizienz Ihrer Problembehandlung deutlich steigern.

Als Erstes gilt es, das aufgetretene Problem zu verstehen. Es muss festgestellt werden, wo das Problem aufgetreten ist und welche Komponenten betroffen sind. Möglicherweise ist es auch hilfreich, das Problem in unterschiedlichen Systemkonfigurationen zu reproduzieren und die Windows®-Ereignisprotokolle und textbasierten Protokolldateien zu Rate zu ziehen. Dies kann aber schwierig sein, da einige Probleme nur sporadisch auftreten. Trotzdem gilt, je besser Sie ein Problem reproduzieren können, desto schneller können Sie die Hauptursache identifizieren und eliminieren. Wichtig ist auch, alle Konfigurationsänderungen und Reparaturen zu dokumentieren und sicherzustellen, dass diese für alle relevanten Systeme in der Umgebung (z. B. auf allen Front-End-Servern in einer Webfarm) durchgeführt wurden. Die Bedeutung dieses Schritts wird häufig übersehen.

SharePoint-Messagingarchitektur

Wenn Sie mit einem Problem bezüglich der Messagingintegration konfrontiert sind, ist es besser, sich eine Tasse Kaffee oder Tee zu holen und dann die SharePoint-Messagingintegrationsarchitektur zu überprüfen, bevor Sie sich mit der Problembehandlung beschäftigen. Wenn Sie dies nicht tun, kann es sein, dass Sie das falsche Problem oder die falsche Komponente reparieren. So bedeutet z. B. der Fehler „Zugriff verweigert“, der die Erstellung eines Kontaktobjekts in Active Directory verhindert, nicht unbedingt, dass die Zugriffsberechtigungen in Active Directory repariert werden müssen. Dies wird später an einem Beispiel verdeutlicht.

Es ist auf jeden Fall wichtig zu verstehen, welche Rolle die einzelnen Komponenten bei der Messagingintegration spielen und wie die einzelnen Komponenten miteinander interagieren. In Abbildung 1 sehen Sie die wichtigen Komponenten in einem SharePoint-Exchange-Konnektivitätsszenario. Diese Situation wird im Folgenden detailliert beschrieben.

Abbildung 1 SharePoint-Messagingintegrationsarchitektur (zum Vergrößern auf das Bild klicken)

Ermitteln von Diagnoseinformationen

Bei einem der wichtigsten Tools für die Problembehandlung handelt es sich um zuverlässige Diagnoseinformationen. Der Klassiker ist hierbei immer noch das Windows-Ereignisprotokoll. Sie können z. B. die Detailebene steuern, mit der SharePoint Einträge in Windows-Ereignisprotokollen auf Webservern erstellt. Dazu wird die SharePoint-Zentraladministration verwendet (klicken Sie auf der Seite „Vorgänge“ unter „Protokollierung und Berichterstellung“ auf „Diagnoseprotokollierung“). Sie können die minimalen kritischen Ereignisse festlegen, die in das Ereignisprotokoll und das Ablaufverfolgungsprotokoll aufgenommen werden sollen. Das Ablaufverfolgungsprotokoll (das sich standardmäßig unter %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs befindet) eignet sich besonders für die Suche nach untergeordneten Informationen. Das Protokoll erreicht aber schnell seine Kapazitätsgrenzen, und daher sollte dieses Feature nur selten verwendet werden.

Eine andere Möglichkeit, Diagnoseinformationen zu erhalten, ist die Aktivierung des Debuggens für die betroffene Webanwendung. Dies wird über das Konfigurieren der entsprechenden web.config-Datei erreicht und wird im Begleitmaterial im Dokument „Web Application Config.pdf“ beschrieben. SharePoint zeigt ausführliche Verfolgungsinformationen direkt in der Benutzeroberfläche an. Der Vorteil dieses Ansatzes liegt darin, dass die relevanten Fehlerinformationen angezeigt werden können, ohne dass zahlreiche Megabytes an Verfolgungsdaten durchsucht werden müssen. Ein Nachteil besteht darin, dass Sie die Systemkonfiguration Ihrer Webanwendung ändern müssen. Denken Sie daran, eine Sicherungskopie der ursprünglichen web.config-Datei zu erstellen und die ursprüngliche Konfiguration wiederherzustellen, wenn Sie die Problembehandlung beendet haben.

Sie können den SMTP-Dienst so konfigurieren, dass dieser detaillierte Verarbeitungsinformationen in das SMTP-Protokoll einträgt (aktivieren Sie im IIS-Manager das Kontrollkästchen „Protokollierung aktivieren“ auf der Registerkarte „Allgemein“). Stellen Sie sicher, dass Sie das Modul für ODBC-Protokollierung mit dem SMTP-Dienst-Feature entsprechend der Beschreibung im Begleitmaterial im Dokument „SharePoint Messaging Integration.pdf“ installieren, auch wenn Sie nicht vorhaben, ODBC-Protokollierung zu verwenden. Andernfalls erstellt der SMTP-Dienst das Protokoll nicht. Das SMTP-Protokoll ist standardmäßig unter %SystemRoot%\System32\LogFiles\SmtpSvc1 gespeichert. Hierbei handelt es sich um eine Textdatei, mit der Sie die SMTP-Kommunikation detailliert analysieren und außerdem bestimmen können, ob eine Nachricht vom SharePoint-Server gesendet wurde.

Auf dem Hub-Transport-Server, der mit dem SMTP-Dienst kommuniziert, können Sie auch die Protokollierung über die Konfiguration „Sendeconnector“ bzw. „Empfangsconnector“ aktivieren (weitere Informationen finden Sie im Dokument „SharePoint Messaging Integration.pdf“). Sie können auch verschiedene andere Tools verwenden, um den Pfad von Nachrichten in der Exchange Server 2007-Umgebung über Hub-Transport-Server und Postfachserver zu verfolgen. Zu diesen Tools gehören Nachrichtenverfolgung, Warteschlangenanzeige, und Pipelineablaufverfolgung. Detaillierte Informationen zur Problembehandlung bei Problemen mit der Nachrichtenübermittlung in Exchange Server 2007 finden Sie unter „Probleme mit dem Transport und der E-Mail-Nachrichtenübermittlung“ unter go.microsoft.com/fwlink/?LinkID=120145.

Auf Active Directory-Domänencontrollern können Sie ausführliche Informationen zur Problembehandlung durch Aktivieren der Diagnoseprotokollierung für den Verzeichniszugriff und andere Kategorien erfassen. Hierfür werden die entsprechenden Registrierungseinträge unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics festgelegt. Der Wert „0x0“ für eine Kategorie bedeutet, dass lediglich kritische Ereignisse protokolliert werden, während der Wert „0x5“ für alle Ereignisse steht, einschließlich Informationen zum Debuggen. Verwenden einer höheren Protokollierungsebene als 0x3 kann zu einem Leistungsabfall des Servers führen und das Windows-Ereignisprotokoll schnell füllen. Während des normalen Betriebs sollten alle Werte auf 0x0 gesetzt werden.

Das Erfassen detaillierter Diagnoseinformationen auf SharePoint-, Exchange- und Active Directory-Servern in einer Problemsituation kann dabei helfen, den Fehler schnell und zuverlässig zu ermitteln. Zusätzliche Tools zur Problembehandlung, wie z. B. TCP/IP-Tools (Ping, Tracert, Telnet usw.) und Network Monitor können ebenfalls hilfreich sein, da der Großteil der Kommunikation zwischen diesen Systemen über das Computernetzwerk ausgeführt wird. Microsoft® Network Monitor 3.1 steht unter go.microsoft.com/fwlink/?LinkId=120143 zur Verfügung.

Ausgehende Nachrichtenübermittlung

Ressourcen

Mit Ereignisprotokollen, Ablaufverfolgungsprotokollen, SMTP-Protokollen, Nachrichtenverfolgungsprotokollen und Netzwerkablaufverfolgungen kann die Problembehandlung für SharePoint-Messagingintegration nun beginnen. Zunächst zum leichten Teil, der ausgehenden Nachrichtenübermittlung. SharePoint unterstützt ausgehende Nachrichtenübermittlung in verschiedenen Konfigurationen und erfordert keinen lokalen SMTP-Dienst auf den Webservern. Bei einem vollständigen Messagingintegrationsszenario wird jedoch empfohlen, den lokalen SMTP-Dienst zu verwenden. Abbildung 2 zeigt die Hauptkomponenten des Szenarios.

Abbildung 2 Ausgehende Nachrichtenübermittlung (zum Vergrößern auf das Bild klicken)

Dieses Messagingszenario verfügt über vier Phasen: SharePoint übermittelt die Nachricht an den SMTP-Dienst, der SMTP-Dienst verarbeitet die Nachricht, der Hub-Transport-Server empfängt die Nachricht, und Exchange Server 2007 übermittelt die Nachricht an das endgültige Ziel.

Wenn SharePoint die Nachricht nicht an den SMTP-Dienst übermitteln kann, wird in der Regel in der Benutzeroberfläche eine Fehlermeldung angezeigt, z. B. dass eine E-Mail-Benachrichtigung nicht gesendet werden konnte. Die Ursache hierfür ist möglicherweise, dass der SMTP-Dienst nicht ausgeführt wird. Es kann auch sein, dass im SMTP-Protokoll angegeben wird, dass der SMTP-Dienst den Übertragungsversuch mit Fehlercode 550 abgelehnt hat (Angeforderte Aktion wurde nicht ausgeführt: Postfach nicht verfügbar). Dies gibt an, dass es sich bei dem Problem um einen Fehler des SMTP-Diensts handelt.

Sie können ein einfaches Skript verwenden, um sicherzustellen, dass es sich bei dem Fehler nicht um ein SharePoint-Problem handelt (siehe SMTP.vbs im Begleitmaterial), mit dem eine Testnachricht über SMTP mit den gleichen Sender- und Empfängerinformationen gesendet wird. Wenn es sich bei dem Fehler um ein SMTP-Dienstproblem handelt, schlägt das Skript fehl. Das Skript kann Ihnen wertvolle Anhaltspunkte zur Hauptursache des Problems bieten, die SharePoint selbst bei aktiviertem Debuggen nicht erkennt (siehe Abbildung 3).

Abbildung 3 Nachrichten können nicht weitergeleitet werden (zum Vergrößern auf das Bild klicken)

Durch Gewähren der Webserver-Weiterleitungsberechtigung in der SMTP-Dienstkonfiguration sowie Neustarten des SMTP-Diensts kann das SharePoint-Nachrichtenübermittlungsproblem gelöst werden. Die Nachricht kann jetzt an den SMTP-Dienst übermittelt werden, und die nächste wichtige Frage ist, ob der SMTP-Dienst die Nachricht an den Hub-Transport-Server übermitteln kann.

Wenn die Nachricht im Warteschlangenordner bleibt, kann der SMTP-Dienst den Hub-Transport-Server nicht kontaktieren. Dies liegt daran, dass der Microsoft Exchange Transport-Dienst nicht ausgeführt wird oder dass ein Problem mit der Netzwerkkommunikation oder -konfiguration vorliegt. Mithilfe des Telnet-Clients können Sie schnell überprüfen, ob Sie eine Verbindung zum Zielport eines Empfangsconnectors herstellen können, der für die interne Kommunikation konfiguriert ist.

Hierbei handelt es sich nicht unbedingt um den TCP-Port 25. Wenn der SMTP-Dienst diesen Port verwendet, können Sie die Nachrichten an den standardmäßigen Empfangsconnector für Hub-Transport-Server übermitteln, der für das Blockieren anonymer Nachrichtenübermittlungen konfiguriert ist. In diesem Fall wird im Drop-Ordner eine Nachrichtendatei angezeigt. (Der Dienst „Windows SharePoint Services-Timer“ muss angehalten werden. Andernfalls wird die Nachricht nach einigen Sekunden ausgeblendet.) Bei der Nachrichtendatei handelt es sich um eine Benachrichtigung über den Zustellungsstatus, die angibt, dass die Nachricht zurückgewiesen wurde: „Diagnosecode: smtp;530 5.7.1 Client wurde nicht authentifiziert.“

Um dieses Problem zu lösen, sollten Sie einen dedizierten Empfangsconnector für die SharePoint-Server erstellen. Da es sich bei den SharePoint-Servern um interne Systeme handelt, sollten Sie die Authentifizierungsoption „Extern gesichert“ wählen. Somit müssen dem Konto ANONYMOUS-ANMELDUNG keine erweiterten Rechte zugewiesen werden. Ziehen Sie auch in Betracht, IPSec zu verwenden, um die Kommunikation zwischen den SharePoint-Servern und dem Hub-Transport-Server zu schützen.

Wenn Nachrichten den SMTP-Warteschlangenordner verlassen und die SMTP-Protokolle auf dem SharePoint-Server und dem Hub-Transport-Server anmeldet (überprüfen Sie den Ordner „%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive“) eine erfolgreiche Nachrichtenübermittlung anzeigen, können Sie die Übermittlung als erfolgreich betrachten, vorausgesetzt, Exchange Server 2007 kann die Nachricht an das Ziel weiterleiten. Verwenden Sie, wie bereits erwähnt, Tools für die Problembehandlung bei der Nachrichtenübermittlung, die in Exchange Server 2007 enthalten sind, um Probleme zu untersuchen, wenn Nachrichten nicht an den beabsichtigten Exchange-Empfänger übermittelt werden können. Beachten Sie, dass falsche Empfängerinformationen, Spamfilter und Einschränkungen der Nachrichtengröße eine endgültige Zustellung verhindern können.

Eingehende Nachrichtenübermittlung

In der entgegengesetzten Richtung ist die Nachrichtenübermittlung etwas komplexer, da potenzielle Probleme diffiziler sind. So wird z. B. in der SharePoint-Produktdokumentation empfohlen, MX-Datensätze in DNS für SharePoint-E-Mail-Domänen zu konfigurieren. Dies kann zu einer falschen Weiterleitung von Nachrichten in einer Exchange-Organisation führen.

Exchange Server 2007 verwendet für die Nachrichtenübermittlung Sendeconnectoren mit zugeordneten Adressräumen. Hierbei können SharePoint-Nachrichten möglicherweise für die Übermittlung an Edge-Transport-Server über das Internet geleitet werden, obwohl es sich bei Ihren SharePoint-Servern um interne Server handelt. Verwenden Sie für die interne Nachrichtenübermittlung stattdessen Sendeconnectoren mit detaillierten Adressräumen, und geben Sie die SharePoint-Server an, die den SMTP-Dienst als intelligenten Host in der Connectorkonfiguration ausführen (Informationen finden Sie im Dokument „SharePoint Messaging Integration.pdf“ im Begleitmaterial). Das Einrichten einer klar definierten Routingtopologie mit dedizierten Bridgeheadservern hilft bei der zuverlässigen Nachrichtenübermittlung von Exchange nach SharePoint.

Um zu überprüfen, ob Nachrichten bei Ihrem SharePoint-Server ankommen, stoppen Sie den Dienst „Windows SharePoint Services-Timer“. Nachrichten stapeln sich im Drop-Ordner, da der Timer-Dienst die Nachrichten verarbeitet und Dateianhänge in Dokumentbibliotheken ablegt, die den E-Mail-Adressen der Empfänger zugeordnet sind. Dies wird in Abbildung 4 gezeigt. Wenn die Nachrichten nicht im Drop-Ordner ankommen, verwenden Sie die Warteschlangenanzeige auf Ihrem Hub-Transport-Server, um zu überprüfen, ob Exchange die Nachrichten korrekt weiterleitet. Untersuchen Sie dann Netzwerkkommunikationsprobleme, die möglicherweise eine Kommunikation zwischen dem Hub-Transport-Server und dem SMTP-Dienst auf dem SharePoint-Server verhindern.

Abbildung 4 Eingehende Nachrichtenübermittlung (zum Vergrößern auf das Bild klicken)

Wenn Sie den Timer-Dienst neu starten, sollten die Nachrichtenelemente nicht mehr im Drop-Ordner angezeigt werden. Wenn die Nachrichtenanlagen nicht als Dokumente in den Zielbibliotheken abgelegt werden, obwohl SharePoint eine erfolgreiche Nachrichtverarbeitung im Windows-Ereignisprotokoll anzeigt, bedeutet dies, dass Exchange die Nachrichten im Exchange-RTF-Format gesendet hat. Schalten Sie zum Untersuchen dieses Problems den Timer-Dienst erneut aus, senden Sie eine weitere Nachricht mit einer Anlage vom Outlook®-Client, und öffnen Sie die Nachricht im Editor, nachdem sie im Drop-Ordner eingetroffen ist. Suchen Sie die Zeichenfolge „winmail.dat“. Wenn diese Zeile vorhanden ist, sendet Exchange Server die Nachrichten im falschen Format.

Für SharePoint müssen Nachrichtenanlagen im Format MIME oder UUENCODE codiert sein. SharePoint zeigt keine winmail.dat-Verarbeitungsfehler im Windows-Ereignisprotokoll an (siehe Abbildung 5). Die Dateianlagen werden einfach nicht in der Dokumentbibliothek angezeigt. Verwenden Sie Editor als Tool für die Problembehandlung, und beheben Sie das Problem durch Konfigurieren einer Remotedomänendefinition in der Exchange-Verwaltungskonsole für die SharePoint-E-Mail-Domäne. Wählen Sie auf der Registerkarte „Format der Originalnachricht, die als Anlage an den Journalbericht gesendet wurde“ unter „Exchange-Rich-Text-Format“ die Option „Nie verwenden“ aus.

Abbildung 5 Winmail.dat-Nachrichtenverarbeitung (zum Vergrößern auf das Bild klicken)

Verzeichnisverwaltung

Ein hilfreiches Timer-Dienstereignis ist Ereignis 6873, das einen Fehler während der Verarbeitung einer eingehenden E-Mail-Datei aufgrund eines unbekannten Alias angibt. Dies tritt auf, wenn ein Exchange-Benutzer beim Senden von Nachrichten eine falsche SharePoint-E-Mail-Adresse angibt, z. B. eine nicht vorhandene Dokumentbibliothek.

Sie können dieses Problem durch Konfigurieren des Verzeichnisverwaltungsdiensts in den Einstellungen für eingehende E-Mail-Nachrichten in der SharePoint-Zentraladministration beheben, um Empfängerobjekte für E-Mail-aktivierte Dokumentbibliotheken in Active Directory zu erstellen. Exchange-Benutzer können diese Empfängerobjekte dann einfach mit den richtigen Adressinformationen aus dem Adressbuch auswählen.

Seien Sie sich jedoch bewusst, dass dies zu zahlreichen weiteren potenziellen Problemen führen kann. Der Verzeichnisverwaltungsdienst schlägt in einer sicheren Systemkonfiguration basierend auf dem Prinzip der geringsten Rechte fehl, da dieses Feature erhöhte Berechtigungsanforderungen auf dem Webserver aufweist. Darüber hinaus wird die Situation in der Produktdokumentation (z. B. technet.microsoft.com/library/cc262947.aspx) ein wenig übertrieben, wenn empfohlen wird, dem Anwendungspoolkonto der Zentraladministration das Recht „Erstellt, entfernt und verwaltet Benutzerkonten“ in der Organisationseinheit zu erteilen, die Sie für die SharePoint-Empfängerobjekte in Active Directory angegeben haben.

Der Verzeichnisverwaltungsdienst erstellt Kontakt- und Gruppenobjekte, und das Anwendungspoolkonto der Zentraladministration erfordert daher vollständige Kontrolle über Kontakt- und Gruppenobjekte in dieser Organisationseinheit, benötigt aber keine Administrationsberechtigungen für die Benutzerkonten. Wenn Sie den Verzeichnisverwaltungsdienst wie beschrieben in einer Webfarm einrichten und versuchen, eine Dokumentbibliothek für E-Mail zu aktivieren, ist es wahrscheinlich, dass der Fehler „Zugriff verweigert“ auftritt.

Die Fehlerinformationen geben Probleme mit Active Directory-Berechtigungen an, und SharePoint-Administratoren gewähren allen Benutzern schnell die volle Kontrolle für die SharePoint-Organisationseinheit. Dies führt jedoch nicht nur zu einer Verringerung der Active Directory-Sicherheit, sondern behebt auch nicht das Problem.

Eine strukturierte Problembehandlung erfordert, dass das Problem zunächst gefunden wird und dann zielgerichtete Konfigurationsänderungen vorgenommen werden. Wenn Sie diesem Ansatz folgen und das Windows-Ereignisprotokoll auf dem Domänencontroller prüfen und möglicherweise die Netzwerkkommunikation mithilfe von Network Monitor verfolgen, finden Sie möglicherweise heraus, dass SharePoint nicht auf Active Directory zugreift, wenn dieses Problem auftritt. Es ist daher unwahrscheinlich, dass Konfigurationsänderungen in Active Directory das Problem beheben. Das Problem wird auf dem SharePoint-Server verursacht.

Leider ist es außergewöhnlich schwierig, nützliche Informationen zu diesem Berechtigungsproblem zu erhalten. SharePoint zeichnet keine zusätzlichen Informationen im Windows-Ereignisprotokoll auf. Wenn Sie jedoch SharePoint-Debuggen aktivieren, können Sie die Aufrufliste anzeigen (siehe Abbildung 6), die anzeigt, dass der Verzeichnisverwaltungsdienst die CreateContact-Methode eines SharePoint-Webdiensts verwendet. SharePoint SDK teilt Ihnen mit, dass es sich hierbei um den E-Mail-Integrationswebdienst handelt (<WSS-Server>:<Admin-Port>/_Vti_bin/SharepointEmailWS.asmx).

Abbildung 6 Debugausgabe

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

Werfen wir einen Blick auf SharepointEmailWS.asmx in einem Webbrowser, um die Liste unterstützter Vorgänge anzuzeigen. Sie können die CreateContact-Methode anzeigen, und durch Klicken auf den Link „CreateContact“ werden die SOAP-Nachrichten angezeigt, die an diesen Webdienst gesendet werden müssen, wenn Sie einen Kontakt in Active Directory erstellen möchten. Dies ist nützlich, da Sie nun ein skriptbasiertes Tool für die Problembehandlung erstellen können (siehe SharepointEmailWS.vbs im Begleitmaterial), das außerhalb der SharePoint-Benutzeroberfläche eingesetzt wird und somit das Festlegen unterschiedlicher Benutzerkonten während der Testläufe erleichtert. Abbildung 7 zeigt die zurückgegebenen Informationen, wenn Sie dieses Skript unter dem Anwendungspoolkonto der Zentraladministration (links) und unter dem SharePoint-Administratorkonto (rechts) ausführen.

Abbildung 7 Zwei verschiedene „Zugriff verweigert“-Fehler (zum Vergrößern auf das Bild klicken)

Die Fehlermeldungen sind verschieden! Beide Nachrichten geben an, dass der Zugriff verweigert wurde, aber der Fehler auf der linken Seite gibt an, dass ein Verarbeitungsfehler vorliegt, der Fehler auf der rechten Seite jedoch nicht. Was also ist der Unterschied zwischen Anwendungspoolkonten und SharePoint-Administratorkonten?

Beim SharePoint-Administrator handelt es sich um einen lokalen Administrator auf dem SharePoint-Server, während Anwendungspoolkonten dies nicht sind. Durch Hinzufügen der Anwendungspoolkonten Ihrer Webanwendung zur lokalen Administratorgruppe sowie durch Neustarten des Webservers wird das Problem behoben. Dies sind allerdings nicht wirklich gute Nachrichten. Meiner Ansicht nach ist das Ausführen von Anwendungspoolkonten mit Administratorrechten auf Produktionswebservern nicht akzeptabel.

Warum benötigt ein Anwendungspoolkonto diese erhöhten Berechtigungen? Auch hier kann das Skript eine Antwort liefern. Wenn Sie allen Benutzern auf Ihrem Webserver zu Testzwecken lokale Administratorrechte erteilen, können Anwendungspoolkonten den E-Mail-Integrationswebdienst verwenden, während der Zugriff weiterhin für alle anderen Konten, einschließlich SharePoint-Administratorkonten, verweigert wird. Dies bedeutet, dass der E-Mail-Integrationswebdienst die Anwendungspoolkonfiguration als Basis für Entscheidungen zur Zugriffssteuerung verwendet.

Die Anwendungspoolkonfiguration ist ein Bestandteil der IIS-Metabasis (oder der Datei „applicationHost.config“ in IIS 7.0), und der Zugriff auf die Metabasis ist standardmäßig auf lokale Administratoren beschränkt. Es ist jedoch möglich, Nichtadministatorkonten Zugriff auf die Metabasis zu erteilen. Hierfür wird der Metabase Explorer verwendet, der mit den IIS 6.0 Resource Kit-Tools geliefert wird. In IIS 7.0 ist es sogar noch einfacher, vollen Zugriff auf die Datei „applicationHost.config“ zu gewähren. Führen Sie hierfür einfach folgende Befehle aus:

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

Wie bereits erwähnt, benötigt der Anwendungspool in der Zentraladministration volle Kontrolle über Kontakt- und Gruppenobjekte in der Zielorganisationseinheit, um Kontaktobjekte in Active Directory erstellen zu können. Die Poolkonten der Webanwendung erfordern vollen Zugriff auf die Metabasis auf den SharePoint-Servern in der Webfarm. Wenn dies gegeben ist, können mithilfe der SharePoint-Benutzeroberfläche Kontaktobjekte erstellt werden.

Das ist aber noch nicht alles. Die Erstellung von Empfängerobjekten in Active Directory ist lediglich ein Teil der Verzeichnisintegration. Bei dem anderen Teil handelt es sich um die Generierung von mit Exchange verknüpften Empfängerattributen sowie um die Aktualisierung der serverbasierten Adressbücher. Wenn Sie z. B. die globale Adressliste auf dem Exchange-Server mithilfe des entsprechenden Exchange-Verwaltungsshell-Befehls (Update-GlobalAddressList "Default Global Address List") aktualisieren, werden neu erstellte Empfängerobjekte für SharePoint-Dokumentbibliotheken im Outlook-Adressbuch angezeigt. Das Senden von Nachrichten an diese Empfänger führt aber zu Unzustellbarkeitsberichten, da es sich um fehlerhafte Adressinformationen handelt (siehe Abbildung 8).

Abbildung 8 Unzustellbare Nachricht an eine Dokumentbibliothek (zum Vergrößern auf das Bild klicken)

Das Akronym IMCEAEX steht für „Internet Mail Connector Encapsulated Address for Exchange“. Es gibt eine gekapselte Nicht-Exchange-Empfängeradresse in einem Format an, das vom alten Exchange Internet Mail Connector verarbeitet werden kann. Heutzutage wird aber mit Exchange Server 2007 und systemeigenen SMTP-basierten Sendeconnectoren gearbeitet.

Der Punkt ist, dass der SharePoint-E-Mail-Integrationswebdienst nicht die Adressattribute schreibt, die von Exchange Server 2007 für die Nachrichtenübermittlung benötigt werden. Es werden lediglich Vorname, Nachname, Anzeigename und Zieladresse angegeben (und optional das msExchRequireAuthToSendTo-Attribut). E-Mail-Spitznamen, Legacy-Exchange-DN oder Proxyadresse werden nicht festgelegt, und das Empfängerobjekt wird keiner Exchange-Empfängerrichtlinie zugeordnet.

Verwenden Sie zum Beheben des Problems das Cmdlet „Get-Mailbox“ in der Exchange-Verwaltungsshell, um alle Empfängerobjekte mit einer Zieladresse abzurufen, die auf die SharePoint-E-Mail-Domäne zeigt. Leiten Sie die Ausgabe zum Cmdlet „Set-MailContact“, um Exchange-Empfängerrichtlinien wie folgt zu aktivieren:

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

Alternativ können Sie auch die Exchange-Verwaltungskonsole verwenden und das Kontrollkästchen „E-Mail-Adressen automatisch basierend auf der E-Mail-Adressenrichtlinie aktualisieren“ in den Kontaktobjekteigenschaften aktivieren.

WSS 3.0 und MOSS 2007 unterstützen standardmäßig eine volle Messagingintegration, um das Übermitteln von E-Mail-basierten Warnungen und Benachrichtigungen, Workflows und Dokumenteinreichungen zu aktivieren. Obwohl es sich bei der korrekten Konfiguration des Systems nicht um eine einfache Aufgabe handelt, kann Messagingintegration die Arbeitsproduktivität steigern. Es muss v. a. sichergestellt werden, dass die eingehende und ausgehende Nachrichtenübermittlung fehlerfrei funktioniert. Es sollte auch sichergestellt werden, dass die Verzeichnisintegration funktioniert.

SharePoint-Fehlermeldungen sind nicht immer intuitiv oder informativ. In diesem Artikel werden jedoch Möglichkeiten aufgezeigt, Integrationsprobleme zu untersuchen, Hauptursachen zu erkennen und sie zuverlässig zu beseitigen, ohne die Sicherheit auf den SharePoint-Servern gefährden zu müssen.

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.

Zusätzliche Ressourcen